What the Rank Math Application Password incident means for your own support team
If you run a WordPress site connected to a free Rank Math account, open your own profile under Users in wp-admin and look at the Application Passwords section before you finish this paragraph. If you see an entry labeled “WAP – Rank Math Support Agent,” it was created when you opened Rank Math’s Help & Support screen, and it has been there ever since, whether or not you meant to grant anyone anything. Closing the tab didn’t revoke it. Nothing did, until you delete it yourself.
This shipped in Rank Math 1.0.277. It is the clearest recent example of what a support-access shortcut costs when nobody asks whether the person on the other end knows it is happening, and whether they can say no. If you ship a plugin or a theme with a Help & Support button of your own, the same question is already sitting inside your product.
Five days from ship to shutdown
Rank Math is one of WordPress’s largest SEO plugins, installed on more than four million sites. On August 26, 2026, the team shipped version 1.0.277, which, alongside a batch of unrelated security fixes, added a Support Agent feature and new AI capabilities. In that release, a site administrator with a connected free Rank Math account who opened the plugin’s Help & Support screen caused WordPress to create a full Administrator-level Application Password for that account, with no notice shown. The credential carried the whole account rather than a limited scope, and the administrator never clicked to approve it. It appeared before any Terms & Conditions screen, labeled in the user’s profile as “WAP – Rank Math Support Agent,” and sent to servers run by group.one, the parent company of both Rank Math and WP Rocket, so its AI support agent could act on the site directly.
The credential didn’t expire. There was no setting to turn the behavior off. And because it lived in the standard Application Passwords list rather than anywhere a user would think to look for a support tool’s footprint, most site owners had no reason to know it existed at all.
On August 27, 2026, Rank Math shipped 1.0.277.1, describing the fix as addressing “an issue involving the Help & Support AI Assistant and Application Passwords when Application Passwords had been disabled.” That is a narrower claim than “the plugin no longer creates a credential without asking.” The remedy Rank Math gave affected users afterward, opening their own profile under Users and manually revoking anything starting with “WAP -“, is the same manual check anyone should have run regardless of whether the patch caught every case.
On August 28, 2026, Sybre Waaijer, developer of the competing SEO plugin The SEO Framework, posted the details on X. Search Engine Journal published its report on August 30, with Relevant Audience and UltimateWB following. Community reaction was pointed: users reported that a large complaint thread on Rank Math’s own WordPress.org support forum was deleted rather than answered. The credential kept being created through all of it; on August 31, version 1.0.277.2 paused the Support Agent entirely, five days after the feature shipped and three after the disclosure.
Why an Application Password didn’t need anyone’s permission to exist
The credential itself worked exactly as WordPress’s Application Passwords feature is built to work. Application Passwords, part of WordPress core since version 5.6, exist so a script or integration can authenticate without touching a user’s main login password. Each one is created from your own profile under Users, shown once, and revocable on its own. What core doesn’t require is a consent screen before one gets created. Whether a user sees an approval step before a plugin generates one is entirely up to the plugin developer. Rank Math’s plugin didn’t add one. Neither, in a milder form, did WPForms Lite 2.0.0, which shipped a temporary one-hour administrative token during its onboarding wizard on July 14, 2026. It was also flagged by Waaijer, though WPForms moved faster to add a clear notice once raised.
That’s the pattern underneath both incidents: Application Passwords are a general-purpose primitive that WordPress never designed as a support-access feature. Nothing in WordPress core stops a plugin from generating one automatically, at full account privilege, with no expiry and no disclosure. Whether that happens is a decision each plugin’s developer makes alone, ticket by ticket, feature by feature. Every team that builds a “Help & Support” button makes that decision on its own, and nothing in the platform catches the ones who get it wrong.
The WPForms case shows the same instinct producing a milder outcome of the same kind. Its onboarding wizard’s temporary token expired in roughly an hour instead of never, which is real progress. But Waaijer’s framing holds up: an hour-long administrative token is still, for that hour, a credential capable of installing plugins or changing settings, handed over with no notice to the user that it existed. WPForms responded with an update adding a clear “you’re being transferred to our servers” notice within weeks. Rank Math’s fix, by its own description, addressed one specific scenario rather than the underlying design. Neither response required the customer’s permission before the credential existed in the first place. They differed only in how quickly, and how visibly, each company cleaned up afterward.
Your own Help & Support button may have the same shape
If your plugin or theme has any button that connects a customer’s site to your support team (a “Get Help,” “Connect Account,” or “Enable AI Assistant” flow), run these questions against it this week:
- Does the customer see a screen before access is created, or does it happen on click? If it happens silently, on tab-open, before any prompt, that’s the exact shape of the Rank Math flow.
- Can they say no and still use Help & Support? A flow that grants access as a side effect of opening a support panel, with no separate consent step, is not asking at all.
- Does the credential expire? If it’s a standing Application Password with no expiry, it doesn’t matter how well-intentioned the feature is. It’s a permanent addition to the site’s attack surface the day it’s created.
- Is it scoped to what support needs, or does it carry the full account? Reading plugin settings and reproducing a bug doesn’t require the ability to delete users or install other plugins.
- Is there a record of it, somewhere the site owner would think to look? “WAP – Rank Math Support Agent” sat in a standard WordPress screen most users never open. A support-access grant that only an expert knows where to find isn’t disclosed in any way that matters.
- If today’s the day this gets covered in the trade press, does the design hold up? The test is whether the flow is one you would want a customer reading about for the first time in a news story, rather than hearing about it from you.
Consent-first access asks before it creates anything
None of this is an argument against giving support teams access to customer sites. That access is the whole reason a Help & Support button exists, and it solves a real problem. The argument is for building the request explicitly: a visible screen before anything is created, a grant scoped to what the ticket needs, an expiry that isn’t a manual chore, and a revoke the customer can trigger themselves without knowing where Application Passwords live in wp-admin. That sequence is what TrustedLogin gives your support team by default: your customer clicks Grant Access inside your own product, sees what is being requested, and the account that gets created expires on its own. It’s the same job Rank Math’s Support Agent feature was trying to do. The difference is whether the customer got to see it happening.