Two Plugin Compromises in One Week, and Neither Was a Bug

Between 15 and 19 October 2026, two of the most installed premium tools in WordPress were used against the sites running them. Rank Math PRO distributed a build with a backdoor in it for about eleven hours. Then an attacker holding TeamUpdraft's own signing keys spent eighteen hours installing backdoor plugins on sites connected to UpdraftCentral.

Neither incident involved a vulnerability. Nobody found an unescaped parameter or a missing capability check. In both cases the attacker used a channel the site owner had deliberately opened: an update feed from a vendor's server, and a management key that lets a remote dashboard run commands as an administrator. The sites did exactly what they were configured to do.

Rank Math PRO: a poisoned release from the vendor's own server

Rank Math's advisory puts the window at 20:02 UTC on 15 October to 07:12 UTC on 16 October. Anyone who downloaded or auto-updated to version 3.0.123 of the PRO plugin in those eleven hours may have received a package with malicious code in it. The free version on WordPress.org was not affected. The clean release is 3.0.124, and Rank Math has not said how its distribution was compromised.

The payload is a persistence kit rather than a one-off shell. According to the vendor's own indicators and Wordfence's write-up, it drops a fake core file at wp-includes/class-wp-cache-util.php, writes three rows into wp_options (_uf6qdn2hmm, t8krdk990phb and _np5pvf754c), adds a system cron entry tagged #ms6v46, hides further loaders in mu-plugins and in theme inc and includes directories, and leaves .cache files that execute as PHP. It creates administrator accounts with usernames starting wpsupport_ on @wp-mail.net addresses, calls home to rank1cdn.com, and rebuilds whatever you delete on the next page load. It is also a credential thief: database passwords, API keys, cloud and SSH credentials readable by the web server user all go out.

Rank Math PRO does not come from WordPress.org. It updates from rankmath.com, and that matters for how you run updates. The release cooldown and automated review that the Plugins Team introduced this summer, which I covered in September, apply only to the directory. A premium plugin's update channel is the vendor's server, the vendor's build pipeline and the vendor's keys, and none of that is covered by anything WordPress.org does. The same was true of ShapedPlugin's Pro releases in May and June. Premium plugins are not safer than free ones because you paid for them. They are safer only if the vendor's release process is, and you have no way to inspect that.

If you ran 3.0.123 and it was active during the window, the vendor's advice is to restore files and database from a backup taken before 20:02 UTC on 15 October and then rotate every password, key and salt the site held. That is the right advice. The persistence is spread across too many places to find by hand.

UpdraftCentral: a stolen key, not a stolen password

UpdraftCentral is the remote dashboard for UpdraftPlus. When you connect a site to it, the site generates an RSA key pair and hands the public half to the dashboard. From then on, any command encrypted for the site and signed with the dashboard's private key is executed by the site without a login, without a password, and without two-factor authentication, because that is what a management connection is for.

Over the weekend of 17 and 18 October, TeamUpdraft's website was breached and the customer database taken. That database held the connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. From 15:32 UTC on 18 October until 09:23 UTC on 19 October, Patchstack watched someone use those keys to push plugins through the normal WordPress installer onto connected sites. The cryptography was sound and the commands were valid, so the sites installed and activated what they were told to.

Patchstack counted 99 different plugin names, mostly two or three innocuous words, with one called "Site Health Cache" reused many times. The plugin itself is small. It hooks early on every request and watches for a URL parameter carrying a 32-character token. Present the token and it logs you in by setting the authentication cookie directly, so the login form, the two-factor prompt, the attempt limiter and whatever login protection plugin you run never execute. One variant creates a user whose display role says Editor but whose capabilities include manage_options and install_plugins. Another skips the user entirely and logs the attacker in as your first existing administrator, which leaves nothing in the users table to find. Nethemba, a Slovak security firm that found the backdoor on its own sites, noted that the checkbox to connect a site to UpdraftCentral is ticked by default when you log into your TeamUpdraft account from the plugin, so a lot of owners will have a key they never knowingly created.

TeamUpdraft released UpdraftPlus 1.26.13 and the Premium 2.26.13 on 19 October to disconnect every UpdraftCentral connection made before 22:00 BST on 18 October. The release a few hours earlier, 1.26.12, deleted no keys at all because of a bug, and Nethemba found a window of keys created on 18 October that the fix missed. So do not trust the update to have done it. Check:

wp option get updraft_central_localkeys

If that returns anything and you do not actively use UpdraftCentral, delete it:

wp option delete updraft_central_localkeys

The same thing is available in the dashboard under UpdraftPlus Backups, Advanced Tools, UpdraftCentral. Then look for the backdoor. Patchstack's marker string is in every sample it saw:

grep -rl "Small maintenance toolkit: keeps option storage tidy." wp-content/plugins/

And look for users whose role and capabilities disagree:

wp db query "SELECT u.user_login, u.user_email FROM wp_users u
  JOIN wp_usermeta m ON m.user_id = u.ID
  WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%editor%'
  AND m.meta_value LIKE '%manage_options%'"

Adjust the prefix if yours is not wp_. Usernames seen so far include data-ops43 and media-staff96, on @example.org addresses, with the display name "Site Tools". If you find any of it, treat the site as compromised, not as a site with an extra plugin on it. The backdoor only needed to run once to create something you have not found yet.

The thread between them

The handbook's chapter on plugin hygiene listed three shapes of supply-chain attack from this year: a plugin portfolio sold to someone who added a backdoor, a vendor's build pipeline compromised so poisoned releases went out through the normal channel, and a vendor's CDN key stolen so scripts were altered in place. Rank Math is the second shape again. UpdraftCentral is a fourth, and it is the one with the widest reach, because it does not need you to update anything. The chapter now lists four.

Every remote management tool works the way UpdraftCentral does. MainWP, ManageWP, and the others all put a key on your site that lets a server somewhere else act as an administrator without going through the login page. That is the product. It is also a standing credential that you did not create, cannot see the other half of, and will only hear about if the vendor tells you it has been stolen. The question for each site is not whether the tool is reputable. It is whether you actually use the connection, and whether you would notice if someone else did.

Three habits follow from this week, and none of them is "update faster":

• Know which keys exist on each site. Management connections, licence keys for premium plugins, API tokens for backup destinations. Put them in the same inventory as the plugins themselves. If you cannot say what a key is for, remove it and see what breaks.
• Treat a vendor breach as a credential event, not an update event. When the notice says keys or a customer database were taken, the fix is to revoke and rotate on your side, then install the update. The update may not revoke anything, as 1.26.12 demonstrated.
• Keep the observation window for premium updates too. The WordPress.org cooldown does not cover them. Eleven hours was long enough for Rank Math's build to reach a lot of sites. Letting a Pro release sit for a day before applying it would have missed it entirely.

Both incidents were authorised, which is the uncomfortable part. Your site accepted a signed update from a server it trusted, and executed a signed command from a dashboard it trusted. Security tooling that looks for exploits has nothing to look at. What catches this is the boring work: knowing what is connected to each site, noticing a user whose role does not match their capabilities, and having a backup from before the date on the advisory.

Where this fits

Chapter 8 of the Protect My WP handbook covers plugin and theme hygiene, including the supply-chain incidents of 2026 and the inventory that tells you within minutes whether you are exposed to the next one. Keys and connections were added to that inventory this week. Chapter 11 covers backups and the cleanup decision, and why a restore from before the incident beats a manual clean when persistence is spread across core, mu-plugins and cron. Chapter 13 is for agencies running management dashboards across many client sites, which after this week is the place to start.

Get the book for £19.