Shahid Ali.WhatsApp

field note

Rank Math's support agent creates an admin application password: I read the code

WordPress

Shahid AliUpdated September 1, 2026all posts

Rank Math's support agent creates an admin application password: I read the code

Rank Math’s support agent, added in version 1.0.277 of the free plugin on 26 August 2026, is being accused of quietly creating a WordPress application password with your permission level and sending it to the servers of group.one, the company that owns Rank Math and WP Rocket. The accusation came from Sybre Waaijer, the developer of The SEO Framework plugin, on 30 August. Rank Math’s own FAQ for the feature says the agent is read-only.

Those two statements cannot both be the whole story, and the plugin runs on more than 4 million sites, so I did the thing the situation allows: the plugin’s source is public on wordpress.org, and I read the exact file Waaijer named. Here is what the code does, what is confirmed versus alleged, and the two minute check to run on any site you manage.

What Rank Math shipped in 1.0.277

Rank Math’s own free changelog for 1.0.277, dated 26 August 2026, lists two things side by side: a new Support Agent “that answers support questions anytime, directly from the plugin”, and a strengthened-security entry crediting Patchstack, Project Black and two researchers for responsible disclosures. The follow-up release 1.0.277.1, same day, fixes the Help & Support assistant “incorrectly showing an HTTPS-required notice … when Application Passwords were disabled by another plugin”.

That second line matters, because it is Rank Math’s own changelog confirming the support agent depends on WordPress application passwords. The knowledgebase article for the feature does not mention them at all. Its FAQ says the agent “is read-only” and “cannot modify your account or site settings”.

What the code actually does

The file Waaijer pointed at is vendor/groupone/wap-client/includes/class-app-password-manager.php, and since every version of a wordpress.org plugin is public, I fetched it from the 1.0.277 tag on the official SVN on 31 August and read it. What the class does is not in dispute, because its own docblocks say it plainly:

  • On each auth call it provisions a fresh WordPress application password for the logged-in user through an internal REST request. There is no authorization screen in this path.
  • The docblock states the plaintext password “is passed directly to the WAP backend and never stored” locally. The backend is group.one’s service, so the credential does leave your site.
  • The label an admin sees in their profile starts with “WAP – “, one password per user and product pair, and the previous one is revoked each time a new one is provisioned, so they replace rather than accumulate.
  • Revocation happens on a failed re-auth and on GDPR erasure. I found no expiry. The password stays active until something revokes it.

An application password is not an interactive login. Per the WordPress documentation it cannot be used on wp-login.php. What it is, though, is a revocable API credential with the full permission level of the user it belongs to. If an administrator triggers the flow, the credential can do over the REST API roughly anything that administrator can do. That is the gap between “the support agent is read-only” and what the credential itself would permit: the first is a statement about the agent’s current behaviour, the second is what the key in the drawer opens.

WordPress has a documented flow for exactly this situation. The application passwords integration guide from 2020 describes an authorization screen: the app identifies itself, the user sees what is being connected and approves or rejects it before any password is handed over. That flow exists for external applications. A plugin running inside your site can call the provisioning API directly as the logged-in user, which is what this code does, and no screen is shown. Waaijer’s charge is that consent never happens; the code I read is consistent with that, because the provisioning path contains no consent step. Whether the surrounding UI discloses it at the moment you open Help & Support is the part I have not verified on a live site, and I am labelling it as such.

What the 1.0.277 code does when Help & Support opens Admin on a connected site opens Help & Support App password provisioned, no authorization screen Plaintext sent to group.one backend, not stored locally Active at the user's permission level, no expiry Your revoke path: Users > Profile > App Passwords Look for names starting "WAP – ". One per user and product pair; a new one replaces the old. Source: class-app-password-manager.php, Rank Math 1.0.277 tag on the wordpress.org plugin SVN, read 31 August 2026.

The two minute check

This only applies if the site is connected to a rankmath.com account. If it is, on every WordPress site running Rank Math:

  1. Go to Users, open the profile of each administrator, and scroll to Application Passwords.
  2. Look for any entry whose name starts with “WAP –”. Waaijer reports it appears as “WAP – Rank Math Support Agent”.
  3. Revoke it. Revoking an application password kills that credential without touching the user’s real password.
  4. If you want the feature gone rather than just the current key, disconnecting the rankmath.com account removes the trigger, and application passwords can be disabled site-wide with the wp_is_application_passwords_available filter, which is the hammer the 1.0.277.1 changelog shows other plugins already use.

I audit WordPress sites weekly and Rank Math is the SEO plugin I meet most often, which is exactly why this went straight onto my audit checklist rather than into a bookmarks folder. The same lesson keeps coming up in the WordPress lane: what a setting or a plugin says it does and what it actually does are two different research questions. The reading-settings checkbox stopped doing what its label says years ago, and plugin defaults quietly decide what Google sees of your archive pages. This one is the security-shaped version of that pattern. The same week, WordPress announced the Core Security Initiative to scale how core handles vulnerability reports; plugin access like this stays outside its scope, and on the site owner’s checklist.

To be fair on the record: as of 31 August Rank Math has not, anywhere I could find, responded to Waaijer’s thread, and nothing here shows the credential being misused. The issue is consent and exposure, not a documented breach. If Rank Math adds an authorization step or a disclosure, this post gets a dated update.

Update 1 September 2026: Rank Math paused the agent and pulled the code

The dated update promised above arrived faster than expected. On 31 August Rank Math shipped version 1.0.277.2, whose entire changelog is one line: “Temporarily paused the Support Agent introduced in 1.0.277 while we add further transparency to how it requests site access.” The linked knowledgebase post goes further than the changelog wording. Rank Math accepts the consent criticism in plain terms: “When an AI agent is being given permission to create an application password, you should be told clearly and directly what is happening and what you’re allowing. That feedback is fair, and we take responsibility for making this clearer.”

The KB post says 1.0.277.2 “removes the Support Agent” and that “no new credentials are being created”. I checked that claim the same way I checked the original allegation, in the public tags on the wordpress.org SVN, on 1 September. In the 1.0.277 tag, vendor/ contains the groupone/ directory that holds the wap-client credential code this post describes. In the 1.0.277.2 tag, vendor/ has no groupone/ directory at all. The code that provisions the application password is not disabled behind a flag; it is gone from the shipped plugin. “Paused” in the changelog undersells it.

Rank Math also restates four protections: credentials were encrypted, were not stored or persisted on their side, inherited the current user’s role without elevating it, and the agent was read-only. Those are claims about their backend and their agent, so I cannot verify them from the code the way I could verify the provisioning path, and they stand as vendor statements. The company says the agent will return once the flow asks for access “clearly and explicitly” before any credentials are created.

One thing has not changed, and it is the reason the two minute check above stays on my audit checklist: neither the changelog nor the KB post says that updating to 1.0.277.2 revokes application passwords that were already created. With the wap-client code removed, the revoke-on-failed-reauth path described earlier is gone with it. If a “WAP –” entry was provisioned on a site you manage, updating the plugin stops new ones being made, and the existing one still needs to be revoked by hand under Users, Profile, Application Passwords.

Sources

Message me on WhatsAppRead the guides