Rank Math Created an Admin Password on 4 Million Sites. Check What Else Has One.

For a few days at the end of August, a plugin installed on more than four million WordPress sites created an administrator-level credential on your site and sent it to its parent company, without asking first. The feature has since been pulled. The more useful question is the one that outlives it: what else on your site already has a credential like that, and would you know if it did?

This article covers what happened with Rank Math, what a WordPress Application Password actually gives away, and how to audit every one on your site in about ten minutes. The audit is the part worth keeping. It applies whether you use Rank Math or not.

TL;DR

• Rank Math 1.0.277 (August 26, 2026) added a Support Agent that created a WordPress Application Password when an admin opened the plugin's Help & Support panel and sent it to parent company group.one. Version 1.0.277.2 (August 31) removed the feature.
• Update to 1.0.277.2 or later, then check Users → Profile → Application Passwords and revoke anything named WAP – Rank Math Support Agent. Rank Math's own post confirms that no new credentials are created, but does not say existing ones are removed, so check by hand rather than assuming.
• An Application Password lets whatever holds it act as that user through the REST API and XML-RPC. It has no capability scoping of its own, no expiry setting, and it does not go through your login form, so a two-factor plugin is not involved.
• Check every user account, not just yours. Any administrator can view and revoke another user's Application Passwords from that user's profile screen.
• The rule of thumb: you should be able to name the software behind every entry in that list. If you cannot, revoke it and see what breaks.

What to do right now if you run Rank Math

Five minutes, in this order.

1. Update the plugin. The current version on the WordPress.org directory is 1.0.277.2. Anything earlier still contains the Support Agent.
2. Open your own profile. Go to Users → Profile and scroll to Application Passwords.
3. Revoke anything named WAP – Rank Math Support Agent. The separator is an en dash, not a hyphen, so a browser search for "WAP -" may not match. Look for entries beginning with WAP.
4. Repeat for every other administrator account. Go to Users → All Users, edit each one, and check the same section. The credential was created for whichever user opened the panel, so it will not necessarily be on your profile.
5. Do not stop there. While you are in that screen, read every other entry too. That is the rest of this article.

Two things worth being precise about, because the coverage has been loose on both.

Updating removes the feature. Rank Math's own post says that on 1.0.277.2 or later the agent is gone and no new credentials are created. It does not say that a credential created last week has been deleted. The Repository reported that the release also added a cleanup function to remove passwords the feature made, and Sybre Waaijer, who found the behaviour, still told readers afterwards to check the list themselves. Where the vendor's own wording and press reporting differ on whether an existing credential survives the update, looking at the list takes ten seconds and settles it for your site.

And this was not a hack. Rank Math was not breached. What happened was a shipped feature that created credentials without a clear consent step, which is a different kind of problem from a compromise and should not be described as one.

What actually happened

Rank Math 1.0.277 shipped on August 26, 2026, and introduced a Support Agent: an AI assistant living in the plugin's Help & Support panel. To answer questions about a site's configuration, the agent needed a way to read that configuration. The mechanism the plugin used was a WordPress Application Password.

When an administrator whose site was connected to a free Rank Math account opened that panel, the plugin generated an Application Password tied to that user's account and transmitted it to servers run by group.one, Rank Math's parent company. It appeared in the user's profile as WAP – Rank Math Support Agent.

Sybre Waaijer, founder of The SEO Framework, a plugin that competes directly with Rank Math, flagged the behaviour publicly in late August after reviewing the release. He reported that the credential did not expire, was not revoked when the Help & Support tab was closed, and could not be turned off from inside the plugin, and that a terms and conditions checkbox existed but did not gate the creation or the transfer. His practical advice was blunt: revoke anything starting with "WAP –".

The uncomfortable detail is that the same 1.0.277 release also carried a batch of security fixes, credited in the changelog to Patchstack, Project Black and two independent researchers, and reported elsewhere as roughly a dozen issues. Site owners who were doing the right thing by patching promptly are the ones who got the feature.

What Rank Math says

Rank Math published a knowledge base post on August 31 alongside version 1.0.277.2. Its account is worth reading in full, and the summary here is not a substitute for it.

The company describes the Support Agent as the first step toward what it calls Agentic SEO, with more capabilities planned. It says the credentials were encrypted, that they were not stored or persisted on Rank Math's side and were used only while an agent session was running, that the agent took on the current user's role and did not elevate beyond it, and that it was read-only and could not change anything on the site. It characterises the problem as one of explanation rather than capability: the plugin did not make clear enough that credentials were being generated for the AI agent.

It also accepts the criticism directly. On the point that a user should be told plainly when an AI agent is being given permission to create an Application Password, the post says the company takes "responsibility for making this clearer". The company says the agent will return once the access request flow has been rebuilt, and that when it does it will ask explicitly, in plain language, before any credential is created.

The changelog entry for 1.0.277.2 is one line: the Support Agent is paused "while we add further transparency to how it requests site access".

Why both accounts can be true and still not agree

Rank Math's position is about what the agent was built to do. Waaijer's is about what the credential can do. Those are different claims, and neither one refutes the other.

A WordPress Application Password has no capability scoping. It is not a token with a permission list attached. It authenticates as the user it belongs to, full stop, and everything that user can do through the REST API or XML-RPC is available to whoever holds it. Waaijer's line, as reported by The Repository, is the clearest statement of the gap: "Steal the key, and you can skip the chatbot."

So "read-only" describes the intended behaviour of the software at the other end. It does not describe the credential. If the agent only reads, that is a property of Rank Math's code and infrastructure, not a property of the thing sitting in your user profile. Both statements can be accurate at the same time, and the disagreement is really about which one a site owner should plan around.

This is the second case in a month, and the third thing is different

Three weeks earlier, the same researcher reported a similar shape of problem in WPForms Lite 2.0.0, a plugin on more than five million sites. In that case the setup wizard handed a short-lived administrative token to the vendor's own application, which could then install plugins on the site, without a clear consent step. Search Engine Journal tested it and published what it found. The Repository reports that Awesome Motive subsequently updated the plugin to add a disclosure.

The mechanism was not the same. That was a time-limited session token created by the plugin's own onboarding flow, not a WordPress Application Password sitting in a user profile. What the two cases share is the pattern: admin-level access to an external service established during an ordinary action, disclosed afterwards rather than requested beforehand.

Keep one thing separate from both. Awesome Motive was also genuinely breached in June, in an incident reported by The Repository, where an attacker exploited a vulnerability in UpdraftPlus on the OptinMonster site, stole a CDN key and served tampered JavaScript. That was a compromise. The other two were design decisions. The distinction matters, because the remedy for a breach is incident response and the remedy for a design decision is a consent flow, and treating them as the same story helps nobody.

What a WordPress Application Password actually is

Application Passwords arrived in WordPress 5.6 in December 2020. The idea is sound: instead of handing your account password to a mobile app or a deployment script, you generate a separate credential for that one tool and revoke it later without changing anything else.

From the WordPress Advanced Administration Handbook, the properties that matter here:

Two limits are worth knowing, because they cut both ways. An Application Password cannot be used to log into wp-admin through wp-login.php. It is for API clients, not for humans typing into a login form. That reduces the blast radius in one direction and widens it in another: because the credential never touches your login form, a two-factor plugin that protects that form is not part of the transaction. The second factor you configured is not asked for, because nothing is asking.

That is the fact most site owners get wrong. Application Passwords do not defeat two-factor authentication by breaking it. They arrive through a door that two-factor authentication was never installed on.

How to audit every Application Password on your site

This is the part to keep. Most WordPress sites have never had this list read once.

In wp-admin

Go to Users → All Users. For each user, click Edit and scroll to Application Passwords. An administrator can view and revoke another user's Application Passwords from that screen, which is what makes a full audit possible without asking everyone to log in.

Read four things per entry:

• Name. Whatever the software called itself when it asked. It is not verified by anything, so treat it as a hint, not proof.
• Created. When it was issued.
• Last used. The useful one.
• Last IP. The address that used it most recently.

A credential created eight months ago and last used yesterday from an address you do not recognise is a finding. So is a credential that has never been used at all, though that one is usually a leftover from a tool someone tried once.

With WP-CLI

If your host gives you SSH, this is much faster, especially across several sites. WordPress ships a wp user application-password command:

# List one user's credentials with the fields that matter
wp user application-password list 1 --fields=uuid,name,created,last_used,last_ip

# Revoke a specific one by UUID
wp user application-password delete 1 <uuid>

To sweep every account on the site rather than one at a time:

# Print each user ID, then that user's application passwords
for id in $(wp user list --field=ID); do
  echo "--- user $id ---"
  wp user application-password list "$id" --fields=name,created,last_used,last_ip
done

Run that once per site and keep the output. Comparing it against the same output in three months is a cheap way to notice a new entry that nobody authorised.

Deciding what to revoke

Be practical rather than absolutist. Plenty of legitimate software uses these: the WordPress and WooCommerce mobile apps, deployment and CI scripts, uptime and SEO monitoring services, headless front ends, publishing integrations that push posts in from elsewhere. Revoking all of them will break real things.

The working rule is ownership, not suspicion. You should be able to name the software behind every entry. If you can, leave it and note it. If you cannot, revoke it and find out what breaks. Recreating a credential for a tool you actually use takes a minute. Leaving one in place for a tool you cannot identify has no upper bound.

Before you start revoking on a live site, take a backup and, if you can, run the same check on a staging copy first. On MagicWP, staging is a one-click clone and backups run daily off-site with one-click restore, so testing a revocation on a copy and rolling back a mistake are both cheap. SSH and WP-CLI are available on every site, which is what makes the loop above practical when you are looking after twenty of them rather than one.

Which plugins are likely to have one

The category that matters is not "SEO plugins" or "AI plugins". It is any plugin that maintains an outbound connection to a vendor's servers and needs to act on your site from that side. In practice that means:

• Site management and maintenance dashboards
• Backup services with off-site storage and remote restore
• SEO plugins with cloud analysis or AI features
• Page builders with hosted template libraries
• Security services that perform remote scanning or remediation
• Anything with "connect your account" in the setup wizard

None of that is inherently wrong. A remote backup service that cannot act on your site is not a backup service. The point is not to remove these plugins. It is to know which ones they are, and to have decided that each connection is one you want.

There is a genuinely useful check most people have never used. WordPress.org plugin guidelines require plugins to disclose the external services they contact, in plain language, in their readme, and not to contact external servers without explicit consent. That disclosure shows up as an External Services section on the plugin's page in the directory. It lists each endpoint, what is sent, and when. Reading it takes two minutes and tells you more than any blog post about that plugin will.

Compare that section against what the plugin actually appears to do. The gap between the two is where stories like this one start.

Should you turn Application Passwords off completely?

You can. WordPress exposes two filters for this, documented in the Advanced Administration Handbook. Put either in a must-use plugin rather than a theme's functions.php, so it survives a theme change:

<?php
// Disable Application Passwords site-wide.
add_filter( 'wp_is_application_passwords_available', '__return_false' );

For something less blunt, wp_is_application_passwords_available_for_user lets you allow them for specific users or roles and refuse them everywhere else. On a site where one deployment account needs API access and no one else does, that is the better shape.

Important: Turning this off breaks every integration that relies on it, including mobile apps and any service that publishes to the site over the REST API. Check what is in the list before you disable the feature, not after.

The honest trade-off:

Disabling the feature is not a substitute for the audit. If a credential already exists and you turn the feature off afterwards, check the documentation and confirm behaviour on a staging copy rather than assuming existing credentials stop working.

The governance argument, which is not settled

Matt Mullenweg raised this in the WordPress Slack #pluginreview channel on August 31, and The Repository reported it. The proposal, as described there, is that plugins taking admin-level access to a site should be required to pass an infrastructure security audit, with legacy exceptions removed, on the grounds that unaudited admin-level external connections turn well-connected sites into infrastructure someone else controls.

Plugins Team co-rep David Perez told The Repository the team met on Monday to discuss it and that it is too early to say more. Nothing has been published.

The obvious objection is worth stating rather than leaving to the comments. As reported, the proposal treats Automattic's own plugins as already trusted, and Automattic ships Jetpack, which maintains exactly the kind of persistent admin-level connection under discussion. A rule enforced by WordPress.org, on everyone except the plugins of the company whose CEO also controls WordPress.org, is a hard sell in an open-source project regardless of whether the underlying security argument is right. Both things can be true: the risk category is real, and the governance of the fix is contested.

For a site owner, none of this changes anything today. There is no audit requirement. There is no approved list. The check in this article is what you have.

Frequently Asked Questions

Does updating Rank Math revoke an Application Password that was already created?

Rank Math's post says that on 1.0.277.2 or later the Support Agent is removed and no new credentials are created. It does not state that existing credentials are deleted. The Repository reported that the release added a cleanup function to remove them, and the researcher who found the behaviour still advised checking manually afterwards. Given that, do not rely on the update alone. Open Users → Profile → Application Passwords on every administrator account and confirm the list is what you expect.

Was Rank Math hacked?

No. This was a feature the company shipped deliberately, then paused after criticism of how it asked for consent. That is a design decision, not a compromise. It is worth being precise about, because commentary on this story has grouped it with an unrelated breach at a different company, and the two situations call for different responses.

Should I uninstall Rank Math?

That is not what this story supports. The feature has been removed, the company has acknowledged the consent problem publicly, and the advice in this article works the same either way. If the pattern concerns you, the useful response is to audit the credentials on your site and read the External Services disclosure for every plugin you run, not to swap one SEO plugin for another.

How do I know if an Application Password is being used by an attacker rather than a tool?

You cannot know for certain from wp-admin alone, but the last used and last IP fields on the profile screen are the strongest signal available without server logs. A credential you cannot attribute to software you installed, being used from an address you cannot explain, is enough to revoke it. Revocation is instant and reversible in the sense that any legitimate tool can be reconnected.

Do Application Passwords bypass two-factor authentication?

Effectively, yes, though not by defeating it. Two-factor plugins protect the interactive login at wp-login.php. Application Passwords cannot be used there at all; they authenticate API requests over HTTP Basic Auth instead, which is a separate path that never involves a second factor. If you rely on 2FA as your main account protection, the Application Passwords list is the gap in that plan.

Can other users see or create these on my site?

Any user can create Application Passwords for their own account, and administrators can view and revoke them for other users from the user edit screen. On a multi-author site or a WooCommerce store with staff accounts, that means the audit has to cover every account, not just the administrators. Editors and shop managers can do a great deal through the REST API.

Is there any way to be notified when a plugin creates one?

Not in WordPress core. Nothing in wp-admin tells you that a credential has been created, and the entry appears in the profile screen without any notice. An activity log plugin can record it, and comparing scripted wp user application-password list output between checks will catch new entries after the fact. Neither is a warning at the moment it happens.

How often should I run this audit?

Quarterly is reasonable for a site with a settled set of integrations, and after any of these events: adding a plugin that connects to an external account, a staff member leaving, a plugin taking over an admin panel you had not seen before, or any suspicion of compromise. Scripting it makes the cadence question mostly irrelevant, because a diff of two outputs takes seconds.

Conclusion

The specific fix here is small: update Rank Math, open your profile, revoke anything you did not authorise. The larger point is that WordPress gives every plugin on your site the same ability to create a credential that acts as you over the REST API, and almost nobody has looked at the list. Doing a WordPress Application Password audit once, and scripting it so the second one is trivial, is the highest-value security work available to most site owners this month.

If you would rather that check ran against a staging copy with a same-day backup behind it, that is the kind of thing managed WordPress hosting should make routine rather than special.

The feature is gone from Rank Math, and the company says it will come back with a proper permission step. Nothing else has changed. WordPress core works the same way it did last month, no audit requirement exists, and there is still no notification anywhere in wp-admin when a plugin creates an Application Password on your site.