UpdraftPlus Breach: UpdraftCentral Keys Used for Backdoors

If you run UpdraftPlus, check for an UpdraftCentral key today, even if you’ve never used UpdraftCentral. Attackers broke into TeamUpdraft’s systems over October 17–18, 2026 and took the keys that let its cloud dashboard control customers’ sites. Then they used them, signing real commands that installed backdoor plugins on connected WordPress sites. It’s the second vendor-side compromise of a major WordPress plugin in a week, after Rank Math PRO.

At a glance

CVE	None. This is stolen keys, not a code flaw. (Separately, versions below 1.26.5 / 2.26.5 are also open to CVE-2026-10795, an authentication bypass fixed in June.)
Plugin	UpdraftPlus, free and Premium (about 4 million installs). Only sites holding a cloud UpdraftCentral connection key are exposed
Type	Vendor breach: stolen remote-management keys used to push backdoor plugins
Severity	Critical for exposed sites: full site takeover through validly signed commands
Affected	Sites with a cloud UpdraftCentral key, on UpdraftPlus before 1.26.13 (free) / 2.26.13 (Premium)
Fixed	1.26.13 / 2.26.13 revoke older keys. Updating does not remove a backdoor that’s already installed
Status	Exploited. Patchstack logged backdoor installs from October 18, 15:32 to October 19, 09:23. One host reports more than 100 of its customers’ sites hit

What’s wrong

UpdraftCentral is TeamUpdraft’s dashboard for managing many WordPress sites from one place: run backups, update plugins, install plugins. Every copy of UpdraftPlus, free and Premium, includes the client that listens for its commands. A connected site trusts any command signed with the dashboard’s key, and runs it with the permissions of the WordPress user who made the connection, usually an administrator.

For the cloud version of UpdraftCentral, TeamUpdraft holds those keys. So when its customer database was breached, the attackers got the ability to send genuine, correctly signed commands to every connected site. Nothing in UpdraftPlus was broken. It did exactly what it was built to do, for the wrong people.

Three details made it worse:

Keys never expire. Patchstack found keys from November 2025 still working in October 2026.
Removing a site from the dashboard doesn’t remove the key on the site, and the key on the site is the one that matters.
The connection checkbox is ticked by default. When you connect a site to a TeamUpdraft account, the option “Add this website to UpdraftCentral” is pre-checked, according to Patchstack and Nethemba. Sites can hold a key their owners never meant to create.

The attack, step by step:

Breach. An intruder gets into teamupdraft.com over October 17–18 and takes the customer database: names, emails, billing addresses, password hashes, two-factor settings, and connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. Card details aren’t stored there.
Push. Using the stolen keys, the attacker sends a plugin.upload_plugin command to connected sites. Each site installs and activates a plugin with a random name. Patchstack counted 99 different names.
Trigger. The plugin hooks into every request and waits for a secret 32-character token in the URL.
Take over. Given the token, it creates a user with a hardcoded password, gives it the Editor role plus the manage_options and install_plugins capabilities, and logs it in by setting a cookie directly.

That last step is the clever part. Logging in by cookie skips the login form entirely, so two-factor authentication, login limits and login-protection plugins never run. The account shows up as an Editor, so a quick look at your administrators misses it. And it survives after the plugin is removed.

The one thing that went the defenders’ way: the samples Patchstack analysed had a coding error that crashed sites with HTTP 500 errors. That’s how many owners noticed. Patchstack warns that “fixing” that error just switches the backdoor on.

What the attacks look like

A plugin you didn’t install, often named “Site Health Cache,” with the description “Small maintenance toolkit: keeps option storage tidy.” Patchstack calls the description its most reliable file-level indicator. One variant hides from the plugin list.
A user you didn’t create, named as two words and two digits (data-ops43 and media-staff96 were seen), display name “Site Tools,” an @example.org email, and the Editor role with extra capabilities.
A database option whose name ends in _sync_token.
In the UpdraftCentral log: Command received: plugin.upload_plugin that nobody on your team sent.
In access logs: a query parameter carrying a 32-character token, and requests whose User-Agent reads class-udrpc.php without a version number.
Error emails from WordPress naming a plugin you don’t recognize.

The source IP addresses reported by Patchstack and Nethemba:

43.250.53.42
2a09:bac5:4e21:2e3c::49b:9

Blocking them won’t protect you on its own. Attackers change addresses, and the commands that installed the backdoors were signed with real keys, so they looked legitimate. Use the addresses to search your logs.

What to do

1. Find out whether the site holds a key

Go to Settings → UpdraftPlus Backups → Advanced Tools → UpdraftCentral and look for connection keys. With WP-CLI:

wp option get updraft_central_localkeys

Any output means the site is exposed. Check even if you’ve never used UpdraftCentral, because of the default checkbox. Free UpdraftPlus users who never connected a teamupdraft.com account have nothing to do here, according to TeamUpdraft.

2. Update, then delete the key anyway

Log in to the site directly, not through UpdraftCentral, and update to 1.26.13 (free) or 2.26.13 (Premium) or later. Skip 1.26.12 / 2.26.12, which Nethemba says shipped with a bug and removed no keys. Then delete the UpdraftCentral key yourself, in the same screen or with:

wp option delete updraft_central_localkeys

Your backups keep working without it. Only remote control is switched off.

3. Check whether you were hit

Users: check Editors as well as Administrators. Look for the name pattern, the @example.org email and the “Site Tools” display name.
Plugins: check the Must-Use tab too.
Database: look for options ending in _sync_token.
Logs: look for the UpdraftCentral commands and access-log patterns above.

If you find the backdoor, the order matters: delete the key first (so a replacement can’t be pushed), then deactivate the plugin and move it out of the web root, then remove the _sync_token option and the account. Treat the site as fully compromised: restore from a backup taken before October 17 if you can, change every admin password, log out all sessions, and re-authorize your remote backup storage with fresh access keys. If you have a teamupdraft.com account, change that password too, typing the address yourself rather than following an email link, and reset your two-factor authentication.

4. Take plugin installs off the table

Every attack in this incident, and in Rank Math’s, ended the same way: new code got installed on a live site through WordPress itself. If your production site’s code only changes through your own deployment process, you can tell WordPress not to modify files at all. In wp-config.php:

// No plugin or theme installs, updates or file edits from inside WordPress.
// Code reaches production only through your own deployment process.
define( 'DISALLOW_FILE_MODS', true );

With this set, a remote-management command to upload a plugin fails, and so does an attacker who gets an admin login and tries to install one. It’s a real trade-off. It also stops dashboard updates and automatic updates, core security releases included, so it only makes sense if you deploy updates yourself, through staging, and promptly. If you can’t commit to that, leave it off and keep remote management on an account that can’t install plugins.

Where sources disagree

Is updating enough? TeamUpdraft says update to 1.26.13 / 2.26.13, delete the key and reconnect. Patchstack, writing on October 19 before 1.26.13 existed, said no update stops the attack, and that you should delete keys and keep them deleted until the vendor explains how it happened. Nethemba reports that keys created between 12:07 and 21:00 UTC on October 18 survive 1.26.13, because TeamUpdraft’s revocation cutoff is 13:07 BST on the 18th. TeamUpdraft hasn’t addressed that gap. Deleting the key covers all of these.
Reconnect or not? TeamUpdraft’s steps end with reconnecting to UpdraftCentral. Patchstack advises against it until the cause is explained.
The default checkbox. Patchstack and Nethemba report it. TeamUpdraft’s notice doesn’t mention it.
Which accounts to check. TeamUpdraft’s early steps said to look for unrecognized administrators. The backdoor creates an Editor. TeamUpdraft added a request to check editor roles on October 22.
Scale. TeamUpdraft hasn’t said how many sites were affected. One host reports more than 100. Other estimates circulating online are unverified.
Timing. Patchstack doesn’t give a time zone for its October 18–19 window.

The bigger lesson

Rank Math was the update server. This was the remote control. In both cases the plugin code was fine, and in both cases a vendor’s systems became a way into thousands of sites, because those sites were set up to trust whatever the vendor sent.

Remote management dashboards are convenient because they hold the keys to many sites at once. That’s also exactly why they’re worth breaking into. Before you connect a site to one, ask the questions from How a Plugin Earns Its Place: who holds the keys, what can they do with them, do they ever expire, and how would you know if someone else were using them? A key nobody remembers creating, that never expires, that can install code as an administrator, has not earned its place.

UpdraftCentral Breach: Stolen Keys Used to Backdoor WordPress Sites