Two Days Ago, Rank Math Closed About a Dozen Security...  🔗 **Source:** [Two Days Ago, Rank Math Closed About a Dozen Security...](https://twitter.com/SybreWaaijer/status/2093382158349951136/?rw_tt_thread=True) > [!note]+ Document Notes > title: "Rank Math 1.0.277 mints an admin Application Password for group.one (Sybre Waaijer thread)" > author: Sybre Waaijer > source: https://twitter.com/SybreWaaijer/status/2093382158349951136/ > published: 2026-08-28 > type: literature > tags: [wordpress-security, application-passwords, ai-agents, supply-chain-security, plugin-ecosystem, consent, credential-transfer, rank-math] > > > [!info] Deep read — processed 2026-08-30 > > Sybre Waaijer (@SybreWaaijer), X thread, 2026-08-28, 369 words. Founder of The SEO > > Framework — a direct Rank Math competitor — which he discloses in the thread. > > **Independently verified** against wordpress.org, Search Engine Journal, group.one, and > > coverage of the July 2026 WPForms precedent. Most claims check out; one central claim does > > not yet have independent confirmation. See Methodology for the split. > <!-- deep-read:sections start --> ## 📝 Summary Rank Math 1.0.277 (2026-08-26) shipped roughly a dozen security fixes and, in the same release, a **Support Agent** feature. Waaijer's claim is about the mechanism behind that feature: when an administrator on a site connected to a free rankmath.com account opens **Help & Support**, the plugin creates a WordPress **Application Password** for that administrator and transmits it to group.one's servers, where an AI agent can act on the site. The file named: `vendor/groupone/wap-client/includes/class-app-password-manager.php`. His three sharpest points: 1. **Application Passwords have no capability scoping.** A WordPress Application Password carries the full capabilities of the user it belongs to. There is no way to mint a limited one. So a "support agent" credential is necessarily an administrator credential. 2. **It persists.** The password appears as `WAP – Rank Math Support Agent`, does not expire, is not revoked when you close the Help & Support tab, and the Support Agent cannot be turned off. 3. **The aggregation risk, not the vendor, is the threat.** *"Will they do this? Probably not. But their servers are now a hot target: they are collecting administrator passwords from a plugin on over 4 million sites."* **Remediation:** WP Admin → Users → Profile → Application Passwords → revoke anything beginning with `WAP –`. ## 📖 Main Content ### What verification confirmed | Claim | Status | |---|---| | 1.0.277 exists, released 2026-08-26 | **Confirmed** (wordpress.org changelog) | | ~4 million active installs | **Confirmed** — wordpress.org lists 4+ million | | group.one owns Rank Math *and* WP Rocket | **Confirmed** — also Imagify, BackWPup, Adminimize, Search & Replace | | Release added a "Support Agent" feature | **Confirmed in the changelog itself** | | Application Passwords carry full user capabilities, unscoped | **Confirmed** — this is WordPress core behavior | | Waaijer's prior finding of this class was real | **Confirmed** — SEJ installed and tested WPForms and verified it | | Password minted and sent *before* consent | **Not independently verified** | | Rank Math / group.one response | **None found as of 2026-08-30** | ### The changelog is the most damning artifact, and it isn't in the thread Rank Math's own 1.0.277 changelog reads, in part: - *"Added a Support Agent feature for answering support questions directly from the plugin"* - *"Enabled AI assistants to configure Rank Math settings via MCP"* - *"Enhanced plugin security"* **The feature is disclosed. The mechanism is not.** Nothing in that changelog says an administrator-scoped credential is created on your site and transmitted to the vendor. A site owner reading it learns they got better support tooling; they do not learn they may have issued a non-expiring admin credential to a third party. That gap — between a disclosed *feature* and an undisclosed *capability transfer* — is the actual issue, and it is sharper than the word "backdoor," which Waaijer floats and then declines to apply (*"Last time, I classified something like this as a backdoor. This time, you may decide."*). ### Why "it's a legitimate WordPress feature" doesn't answer the objection The defense circulating in coverage is that Application Passwords are WordPress core functionality with documented developer guidance. That's true and non-responsive. Nobody disputes the API is legitimate. The dispute is over **consent and duration**. And the core-platform fact Waaijer identifies is what makes it serious: **Application Passwords cannot be scoped.** There is no "read-only support" variant. WordPress offers exactly one granularity — everything the user can do. So any vendor building an AI agent on this API is structurally forced to take administrator access or take nothing, and the user interface for that choice is a support button. That is a platform gap as much as a vendor decision, and it is the most transferable finding here. ### The escalation path is real but is not the argument Waaijer walks it: with admin-equivalent API access you can install and activate any wordpress.org plugin, so install a snippets plugin — he names *WPCode – Insert Headers and Footers* — and write PHP into its settings. That is remote code execution. He notes group.one cannot log into wp-admin in a browser, *"but they do not need to."* He then explicitly declines to allege intent. His argument is that a vendor accumulating non-expiring admin credentials across a subset of 4M+ installs becomes a high-value single target, and *"a hacker who gets that pile can hijack every site that already minted one."* **That framing is the correct one and it is stronger than an accusation would have been**, because it doesn't require anyone at group.one to be acting badly. It only requires them to be breached. ### The WPForms precedent, which raises his credibility and sharpens the comparison Waaijer's *"last time"* refers to **WPForms Lite 2.0.0**, released 2026-07-14, where he identified code in `wpforms-lite/src/SetupWizard/Bridge.php` sending an administrator's browser to WPForms infrastructure with a temporary login token. Two things matter about that precedent: - **Search Engine Journal independently installed and tested the plugin and confirmed his findings.** This is a researcher whose claims in this exact class have verified out before, which is the right way to weigh his disclosed competitive interest — not to dismiss it, and not to ignore it. - **On the two dimensions that matter, Rank Math's implementation is worse.** WPForms' token was temporary, roughly an hour; Rank Math's Application Password persists until manually revoked. WPForms' AI write access is off by default; Rank Math's Support Agent cannot be turned off. WPForms also shipped follow-up releases adding a notice making the external transfer explicit. Two incidents six weeks apart, both in major commercially-owned plugins, both adding AI-agent features that move site credentials off-site. That is a pattern with two data points — worth naming, not yet worth generalizing. ### Where the thread overreaches slightly The closing line — *"I'm the founder of The SEO Framework plugin, a competing plugin to Rank Math, but without CVEs"* — does two things at once. The disclosure is correct and necessary. The appended *"but without CVEs"* is a competitive claim inside a safety disclosure, and it weakens the neutrality the rest of the thread earns. The technical content stands on its own and did not need it. ## 🗒️ Notes - 1.0.277.1 followed on 2026-08-27, one day later, fixing *"the Help & Support AI Assistant incorrectly showing an HTTPS-required notice"* — so the feature was being actively patched immediately after release. - The same 1.0.277 release also *"Enabled AI assistants to configure Rank Math settings via MCP"* — a second, separate agent-access surface in the same version that the thread doesn't discuss. - The release genuinely did close roughly a dozen security issues, which is why the framing matters: the security work and the credential feature shipped together. - Rank Math also has a separate, unrelated CVE in circulation (CVE-2025-12714, auth bypass) — don't conflate them. - group.one's WordPress portfolio: Rank Math, WP Rocket, Imagify, BackWPup, Adminimize, Search & Replace. Rank Math was acquired in 2023 at ~2M installs; it is 4M+ now. - Waaijer's remediation is checkable by any admin in under a minute and costs nothing if the feature was never triggered — an unusually low-risk action item. - The condition is narrow: it requires the site to be connected to a rankmath.com account **and** an admin to have opened Help & Support. Most of the 4M installs presumably have not done both. ## 📚 References - Thread: https://twitter.com/SybreWaaijer/status/2093382158349951136/ - Rank Math on wordpress.org (version, changelog, install count): https://wordpress.org/plugins/seo-by-rank-math/ - Search Engine Journal coverage: https://www.searchenginejournal.com/rank-math-wordpress-plugin-accused-of-secretly-taking-admin-access/587554/ - group.one acquisition announcement: https://www.group.one/en/news/group-one-extends-wordpress-ecosystem-with-seo-optimisation-plugin-rank-math - WPForms precedent coverage: https://www.ultimatewb.com/blog/13384/wpforms-and-rank-math-did-these-wordpress-plugins-create-a-backdoor-with-admin-access/ - Named file: `vendor/groupone/wap-client/includes/class-app-password-manager.php` - WordPress core Application Passwords documentation (capability model) ## 🗣️ Paraphrase Rank Math's latest update fixed about a dozen security bugs and added an AI support agent. To make the agent work, the plugin creates a WordPress Application Password for the logged-in administrator and sends it to the servers of group.one, which owns Rank Math. WordPress has no way to make such a password limited — it carries every permission the admin has — so the support agent holds full admin rights. It never expires, closing the support tab doesn't cancel it, and there's no off switch. The person who found it isn't claiming group.one will misuse it; he's pointing out that a company now holding admin keys to some portion of four million sites is a very attractive target. Check WP Admin → Users → Profile → Application Passwords and revoke anything starting with "WAP –". ## 📰 Newsletter Rank Math 1.0.277 shipped on August 26 with about a dozen security fixes and a new AI "Support Agent." Sybre Waaijer's finding concerns how that agent is powered: open Help & Support on a site linked to a rankmath.com account, and the plugin mints a WordPress Application Password for you and sends it to group.one. The part that makes this more than a preference disagreement is a WordPress core limitation. **Application Passwords cannot be scoped.** There is no read-only variant — a password carries every capability its owner has. So any vendor building an AI agent on that API must take full administrator access or none, and here the interface for that decision is a support button. That's a platform gap as much as a vendor choice, and it will keep producing this outcome as more plugins ship agents. Compare the changelog to the behavior. It says a Support Agent feature was added. It does not say a non-expiring administrator credential is created on your site and transmitted off it. The feature was disclosed; the capability transfer wasn't. Waaijer is careful about the threat model, and it's the right call — he explicitly doesn't allege group.one will misuse anything. His point is aggregation: a company accumulating non-expiring admin credentials across some share of four million installs is now a very valuable target, and a breach there hijacks every site that minted one. Two caveats worth carrying. He's the founder of a competing SEO plugin and says so — though "but without CVEs" is a competitive jab that the technical content didn't need. And the sharpest specific claim, that the credential is sent before the consent box appears, has not been independently verified yet; Search Engine Journal covered the allegation but reported no code testing this time. They *did* independently confirm his very similar WPForms finding in July, which is the reason to take this seriously rather than discount it. Sixty seconds of prevention: WP Admin → Users → Profile → Application Passwords, revoke anything starting with `WAP –`. ## ✅ Action Items - [ ] Check every client site running Rank Math: Users → Profile → Application Passwords, revoke anything beginning `WAP –`. Narrow condition (connected account + Help & Support opened), zero-cost check. - [ ] Read `class-app-password-manager.php` directly to settle the ordering question — is the password created and transmitted before the Terms & Conditions box renders? This is the one claim that needs first-hand reproduction. - [ ] Watch for a group.one/Rank Math statement; none existed as of 2026-08-30 and its content (or absence) is the story's next beat. - [ ] Audit for the second surface in the same release: MCP-based AI assistant configuration access, which nobody is discussing. - [ ] Add "does this plugin mint credentials for an off-site service?" to plugin evaluation criteria — it isn't on standard checklists. - [ ] Raise the scoping gap upstream: WordPress core has no delegated-capability credential, and every AI-agent plugin will hit this. ## 🧪 Hypotheses 1. **The Application Password scoping gap will produce more incidents of this exact shape.** Two in six weeks. As agent features proliferate, vendors face a binary — full admin or nothing — and will keep choosing full admin. Falsifiable: watch for a third. 2. **Vendor response will be a consent-flow change, not a capability change**, because the capability can't be narrowed with current core primitives. Predicts a disclosure notice and an off switch, with the credential itself unchanged. WPForms followed this path. 3. **Aggregated credential stores at plugin vendors will become a named attack target.** Waaijer's core argument. Requires no misconduct by the vendor. 4. **Plugin directory review does not have a category for this.** Nothing here is malicious code; it's a documented core API used as designed. Predicts review passes it cleanly, which is the ecosystem-level finding. 5. **The competitive-disclosure pattern will degrade trust in the findings even when they're accurate.** Waaijer has now been right once and is unrebutted twice; the "but without CVEs" framing gives the accused an easy dismissal. ## 📊 Methodology A 369-word X thread by a named developer with a named file path and a specific reproduction condition — unusually falsifiable for the format, and to his credit the claim is stated so that anyone can check it on their own site in a minute. **I verified independently before analyzing**, per the standing rule on extraordinary claims, and the results split cleanly: **Verified:** version and release date (2026-08-26), 4+ million active installs, group.one's ownership of both Rank Math and WP Rocket, the Support Agent's presence in Rank Math's own changelog, and the core fact that Application Passwords carry unscoped full user capabilities. **Verified about the source:** his July 2026 WPForms finding, structurally the same claim, was **independently confirmed by Search Engine Journal, which installed and tested the plugin.** A researcher with a disclosed competitive interest and a verified track record in the same claim-class should be weighted accordingly — not discounted, not accepted uncritically. **Not verified:** the consent-ordering claim — *"the transfer starts before the box even appears."* This is the thread's most serious specific allegation and it requires reading the code or instrumenting a live install. SEJ reported the allegation without testing this time. **I am not treating it as established.** **Not found:** any response from Rank Math or group.one as of 2026-08-30. Absence of a statement two days after publication is a fact, not an admission. **Declared conflict:** Waaijer discloses being The SEO Framework's founder. The disclosure is appropriately placed; the appended competitive claim is not, and it is the one place the thread trades credibility for a jab. **What no source has done:** independent code review of `class-app-password-manager.php`. Everything in circulation traces to one researcher's reading. ## ❓ Questions - What is the actual execution order in `class-app-password-manager.php` — is the credential created and transmitted before consent is obtained, or does the box gate it? - What does group.one do with the credential server-side? Storage, encryption at rest, retention, access controls, deletion on account disconnect? - Is there any server-side scoping — does their agent restrict itself to Rank Math settings despite holding unrestricted capability? - Does disconnecting the rankmath.com account revoke the password, or does it persist as Waaijer implies? - How many of the 4M+ installs meet both conditions? Without that, exposure is unbounded in either direction. - What is the MCP surface added in the same release, and does it carry the same properties? - Did wordpress.org plugin review see this, and does it have any policy that applies? - Has any independent researcher read the file? ## 🔮 Future Research - Read the file. Everything downstream of that is inference until someone does. - Survey the top plugins for credential-minting behavior — grep for `WP_Application_Passwords::create_new_application_password` across the corpus. This is mechanically checkable and would size the pattern. - Track whether wordpress.org guidelines add a category for off-site credential transfer. - Follow whether core develops scoped or expiring Application Passwords; that is the upstream fix and this incident is the argument for it. - Compare vendor responses across WPForms and Rank Math on the same dimensions: consent, expiry, off switch, disclosure. - Examine whether the aggregated-credential threat model has precedent outside WordPress — managed-service providers holding customer admin credentials at scale. ## 💡 Implications **For practitioners, right now:** a one-minute check on every Rank Math site. The conditions are narrow but the credential is persistent, which means the exposure doesn't decay on its own. **The structural finding is the scoping gap.** WordPress Application Passwords have exactly one privilege level: everything the user has. As plugins ship AI agents, every vendor hits the same wall and resolves it the same way. This will recur until core provides a scoped or expiring delegated credential, and no amount of vendor good behavior fixes it — the primitive is wrong. **For plugin review:** nothing here is malicious. It is a documented core API, used as designed, disclosed as a feature in the changelog. Standard review has no category for "legitimately mints an admin credential and ships it to the vendor." That is the same ecosystem-shaped hole visible in the plugin-flaw material from this week — the project's security attention is on core while the consequential surface is what site owners install. **On the threat model:** Waaijer's aggregation argument is the durable part precisely because it survives the vendor being entirely trustworthy. Concentrating credentials creates risk as a property of the concentration, independent of the concentrator's intent. **On disclosure ethics:** the right handling of a competitor's finding is to weight it by track record and verify the specifics, not to discount it for the conflict or ignore the conflict. His WPForms finding was confirmed by a third party. That is the evidence that should move you, and it's why the unverified ordering claim deserves a code read rather than a dismissal. ## 🧠 Learning Styles Assessment Unusually well-constructed for a social-media thread. It opens with the stakes (4 million sites), names the exact file, describes the trigger condition precisely enough to reproduce, walks the escalation path with a concrete example, states the threat model explicitly, and closes with a click-path remediation any administrator can follow. Sequential and applied learners are served well. The escalation walkthrough — Application Password to plugin install to snippets plugin to PHP execution — is the strongest teaching move, converting an abstract "admin access" into a specific chain a reader can evaluate. That's the difference between alarm and explanation. Weak on evidence display: no code excerpt, no screenshot of the minted password, no network capture. The thread references an image but the captured text carries none of it, so a reader has only the author's description of code they cannot see. For a claim this specific, one screenshot of the Application Passwords screen showing `WAP – Rank Math Support Agent` would do more than any paragraph. Reference-quality remediation, poor for anyone wanting to independently assess before acting. ## 📊 Accessibility Assessment Plain language throughout, with technical terms explained as they arrive — "Application Passwords have no capability scopes; that password gives administrator powers" defines the concept and its consequence in one sentence, which is genuinely good technical writing for a mixed audience. The remediation is the most accessible element: an exact click path, a specific string to look for, and no judgment required. A non-technical site owner can act on it without understanding the rest. Defanged domains (`group[.]one`, `rankmath[.]com`, `WordPress[.]org`) are a security-writing convention that reads awkwardly to general audiences and, here, serves no purpose — these are legitimate companies, not malware hosts. It imports a threat-intel register the content doesn't warrant. Thread format means no headings and no anchors, so the remediation can't be linked to directly. The one image is undescribed in the captured text, so anything it shows is unavailable to screen-reader users and to anyone reading a text mirror. ## 🌍 DEIB Assessment The exposure distributes by capacity to notice, which is the recurring shape of WordPress security burden. Acting on this requires knowing the disclosure exists, understanding what an Application Password is, and knowing where the profile screen lives. Agencies and managed hosts will handle it centrally within a day. The long tail — small businesses, nonprofits, congregations, volunteer-run sites, the people who installed an SEO plugin because a tutorial said to — will never hear about it, and they are also the least likely to have opened a connected support panel and the least able to assess it if they did. There's a second asymmetry in *who gets heard*. This surfaced because a plugin author with an audience read a competitor's code and had a platform to publish on. Nothing in the ecosystem's formal machinery caught it — not plugin review, not a vulnerability database, not the vendor's own disclosure. Ecosystem safety depending on whether a well-followed developer happens to look is a fragile and unevenly distributed protection. And the consent gap lands hardest on people least equipped to evaluate it. An experienced developer reading "Support Agent" in a changelog might think to ask how the agent authenticates. The audience Rank Math markets to explicitly — people who want SEO made approachable — will not, and that is not a failure on their part. ## ✅ Logical Validity **The verified core is sound.** Application Passwords carry unscoped full user capabilities (core behavior), a Support Agent feature shipped in 1.0.277 (vendor's own changelog), and group.one owns Rank Math (company announcement). From those, the conclusion that a triggered Support Agent means a third party holds administrator-equivalent access follows necessarily. **The escalation argument is valid and appropriately hedged.** Admin-equivalent API access permits plugin installation; a snippets plugin permits PHP execution; therefore RCE is reachable. Waaijer immediately adds *"Will they do this? Probably not,"* which is the correct epistemic move — he establishes capability without asserting intent. **The aggregation argument is the strongest thing in the thread** because it requires no bad actor. Concentration of credentials creates a target as a structural property. Nothing about group.one's character is load-bearing. **Where it is not established:** - **The consent-ordering claim** — *"the transfer starts before the box even appears"* — is the most serious specific allegation and rests entirely on his unshown reading of the code. No independent verification exists. This is the claim that would distinguish a poorly designed consent flow from no consent flow, and it is unresolved. - **"You cannot turn the Support Agent off"** is stated flatly with no description of what was tested. A missing UI toggle and an unremovable capability are different findings. - **"Backdoor" is raised and withdrawn** — *"Last time, I classified something like this as a backdoor. This time, you may decide."* Invoking the frame while declining to defend it transfers the connotation without the burden of the claim. Rhetorically effective; not an argument. - **"But without CVEs"** is a competitive assertion in a safety disclosure and is not evidence of anything about Rank Math's conduct here. **On weighting the conflict of interest:** disclosure doesn't neutralize it, but a verified track record partially does. His WPForms claim of the same class was independently reproduced by a third party. The rational position is to treat the confirmed facts as confirmed, treat the unverified ordering claim as unverified, and read the file. ## 🛡️ DARVO Analysis **No DARVO in the thread.** Waaijer is the accuser, not a party defending against accusation. There is no denial, no reversal of victim and offender, and he claims no injury to himself. Worth naming so this is a considered negative rather than a skipped section: the thread contains one element adjacent to a rhetorical shift, and it runs the *opposite* direction from DARVO. The *"you may decide"* construction on the word backdoor invites the reader to reach a conclusion the author declines to state, which is an evasion of burden rather than a reversal of roles. **As of 2026-08-30, no response from Rank Math or group.one exists**, so there is nothing from the accused party to analyze. Two things worth watching if one appears, since this is the standard shape of vendor replies to security disclosures: (a) whether the response addresses the mechanism or attacks the messenger's competitive interest — the latter would be the reversal move, converting a technical finding into a question about the finder's motives, and Waaijer's *"but without CVEs"* line has handed them the opening; and (b) whether "Application Passwords are a legitimate WordPress feature" is offered as a rebuttal, which would be a denial that answers a question nobody asked. Record what actually appears rather than assuming either. ## 🎯 Conclusion The verified facts are enough on their own. Rank Math 1.0.277, released 2026-08-26 to 4+ million installs, added a Support Agent. WordPress Application Passwords cannot be scoped — they carry every capability their owner has. Therefore a triggered Support Agent means group.one holds administrator-equivalent access to that site, and it does not expire. The changelog is the sharpest document in the story and it isn't in the thread. It announces a support feature. It does not mention that a non-expiring administrator credential is created on your site and sent to the vendor. The feature was disclosed; the capability transfer was not. The structural finding outlives this incident: **core offers exactly one privilege level for delegated credentials, so every plugin shipping an AI agent must take full admin or nothing.** Two of these have surfaced in six weeks — WPForms in July, Rank Math now — and Rank Math's is worse on both dimensions that matter, since WPForms' token lasted about an hour and its write access defaulted off. This recurs until core ships a scoped or expiring credential. Hold two caveats. Waaijer competes with Rank Math and says so, though "but without CVEs" is a jab his technical content didn't need. And his most serious specific claim — that the credential is transmitted before the consent box appears — has no independent confirmation; SEJ covered the allegation without testing it, having independently reproduced his WPForms finding in July. That track record is the reason to read the file rather than dismiss the claim. Meanwhile the action is free and takes a minute: Users → Profile → Application Passwords, revoke anything starting with `WAP –`. --- ## Refactor Appendix **Note type:** Literature note. Short source, heavy independent verification, and it carries a platform-level finding that generalizes past the incident. **Permanent note candidates:** ### A credential that cannot be scoped forces every delegation to be total > [!quote] "WordPress Application Passwords have no capability scopes; that password gives administrator powers." When the platform offers one privilege level, a vendor needing limited access must take unlimited access or none. The resulting over-grant is a property of the primitive, not of the vendor's intent, and no amount of good behavior fixes it. <!-- atomicity: 1 idea ✓ --> ### Disclosing a feature is not disclosing the capability it transfers > [!quote] Changelog: "Added a Support Agent feature for answering support questions directly from the plugin." The changelog is accurate and the user still doesn't learn that a non-expiring administrator credential is created and sent off-site. Consent tracks what the user understands they granted, not what the release notes technically said. <!-- atomicity: 1 idea ✓ --> ### Aggregating credentials creates risk independent of the aggregator's intent > [!quote] "Will they do this? Probably not. But their servers are now a hot target… A hacker who gets that pile can hijack every site that already minted one." The strongest form of the argument requires no misconduct — only a breach. Concentration is itself the hazard, which is why "we're trustworthy" is not a response to it. <!-- atomicity: 1 idea ✓ --> ### Persistence, not permission, determines a credential's real exposure > [!quote] "Closing the Help & Support tab does not revoke it. This Application Password does not expire." WPForms' comparable token lasted roughly an hour; this one lasts until manually revoked. Identical grants with different lifetimes are different risks, so expiry belongs in the evaluation next to scope. <!-- atomicity: 1 idea ✓ --> ### Raising a frame and declining to defend it transfers the connotation without the burden > [!quote] "Last time, I classified something like this as a backdoor. This time, you may decide." The reader supplies the accusation the author won't make. Same structure as "there is a word for this" — effective, and a reliable signal that the argument for the label was not attempted. <!-- atomicity: 1 idea ✓ --> ### A disclosed conflict is weighted by track record, not cancelled by disclosure > [!quote] "I'm the founder of The SEO Framework plugin, a competing plugin to Rank Math, but without CVEs." His structurally identical WPForms finding was independently reproduced by a third party, which is the evidence that should move you. Disclosure alone neither neutralizes the interest nor discredits the finding; prior verification is what discriminates. <!-- atomicity: 1 idea ✓ --> **Links to existing vault notes** *(the vault is permission-locked at time of writing — these were verified earlier in the session; re-run the checker after restoring access)*: - [[Five Critical WordPress Plugin and Theme Flaws Enable Site Takeover or RCE]] — extends; same week, same structural point that the consequential surface is what site owners install rather than core - [[The Core Security Initiative]] — contrasts; a core-scoped security program with no category for a plugin legitimately minting admin credentials for a vendor's AI service - [[Exfiltration Needs Three Capabilities Together Not Any One of Them]] — applies-in; the RCE path here is a composition — unscoped credential, plugin-install capability, a snippets plugin that executes settings — and breaking any link breaks the chain - [[A Data Source Needs a Declared Trust Rank Before an Agent May Act on It]] — extends; the inverse problem, an agent granted unbounded authority over a site with no declared scope - [[A Single Discretionary Update Channel Is a Security Dependency]] — evidence-for; a vendor-controlled agent channel with admin rights is the same dependency in a new form **Template Library:** Short-source / heavy-verification variant. Methodology splits verified from unverified explicitly and records that the source's prior claim in this class was independently reproduced. Logical Validity isolates the one central claim lacking confirmation. DARVO recorded as a considered negative with the vendor-response patterns to watch for, since no response yet exists. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/Two Days Ago, Rank Math Closed About a Dozen Security....md|Two Days Ago, Rank Math Closed About a Dozen Security... by Sybre Waaijer]] ## Highlights - The transfer starts before the box even appears ([View Highlight](https://read.readwise.io/read/01m19tnmymcdxr2zt2g9d0p7g8)) - Note: NOT INDEPENDENTLY VERIFIED. This is the thread's most serious specific claim — it's what distinguishes a poor consent flow from no consent flow — and it rests entirely on Waaijer's unshown reading of class-app-password-manager.php. SEJ covered the allegation without testing it. Read the file before repeating this one. - Tags: unverified-claim, consent - WordPress Application Passwords have no capability scopes ([View Highlight](https://read.readwise.io/read/01m19tnj91qna6k685hja0h4d6)) - Note: VERIFIED — this is WordPress core behavior, and it's the structural finding that outlives the incident. Core offers exactly one privilege level for a delegated credential: everything the user has. So any vendor building an AI agent on this API must take full admin or nothing. The over-grant is a property of the primitive, not of the vendor's intent, and it will keep recurring until core ships a scoped or expiring credential. - Tags: platform-gap, application-passwords - their servers are now a hot target ([View Highlight](https://read.readwise.io/read/01m19tnqptpjajf31qfbwx83ps)) - Note: The strongest form of the argument, because it requires no misconduct by group.one — only a breach. Waaijer explicitly declines to allege intent ("Will they do this? Probably not"). Concentration of credentials is itself the hazard, which is why "we're trustworthy" isn't a response to it. - Tags: threat-model, supply-chain-security - This Application Password does not expire ([View Highlight](https://read.readwise.io/read/01m19tntm2rsg7gakaj04j7qy7)) - Note: Persistence is where this beats the July WPForms case on severity. That token lasted ~1 hour and its AI write access defaulted off; this one lasts until manually revoked, survives closing the tab, and has no off switch. Identical grants with different lifetimes are different risks — expiry belongs in the evaluation next to scope. - Tags: credential-transfer - revoke anything starting with ([View Highlight](https://read.readwise.io/read/01m19tnxa4zwzv6zdx5g7zt0aq)) - Note: The action item, and it's free: WP Admin → Users → Profile → Application Passwords, revoke anything beginning "WAP –". Conditions are narrow (site connected to a rankmath.com account AND an admin opened Help & Support) but the credential is persistent, so exposure doesn't decay on its own. - Tags: remediation - a competing plugin to Rank Math, but without CVEs ([View Highlight](https://read.readwise.io/read/01m19tp01esygqjmbvrwne4ejz)) - Note: The disclosure is correct and necessary; "but without CVEs" is a competitive jab inside a safety disclosure and hands the accused an easy pivot to attacking the messenger. Weigh the conflict by track record instead — his structurally identical July WPForms finding was independently reproduced by Search Engine Journal, which installed and tested the plugin. That prior is what should move you, not the disclosure itself. - Tags: disclosure-ethics