On the afternoon of 18 October, someone began installing backdoors on WordPress sites running UpdraftPlus, one of the most widely used backup plugins. The attacker had genuine UpdraftCentral keys, which TeamUpdraft, the company behind UpdraftPlus, believes were taken from its customer database over the weekend.
TeamUpdraft released UpdraftPlus 1.26.12 on 19 October. The update revokes the UpdraftCentral Cloud keys created before the incident. If you run UpdraftPlus, update it now.
If your site is with Prostack, we’ve put a temporary rule across our fleet that blocks the UpdraftCentral remote commands used in the attack. Your backups keep running as normal.
What UpdraftCentral is, and why so many sites have a key
UpdraftCentral is TeamUpdraft’s dashboard for updating, backing up and installing plugins on many WordPress sites from one place. The part that runs on your site is built into every copy of UpdraftPlus, free and Premium. When a site is connected, it gets a key, and from then on it accepts any command signed by the matching dashboard key.
Many site owners have a key without knowing it. When you connect UpdraftPlus to a TeamUpdraft.com account, a box labelled “Add this website to UpdraftCentral” is ticked by default. Leave it ticked and your site is connected to UpdraftCentral Cloud with a key that doesn’t expire.
How the attack worked
TeamUpdraft says an intruder got into teamupdraft.com, and that it believes the customer database was accessed. That database held customer details and the connection keys for UpdraftCentral Cloud, UpdraftVault and UpdraftClone. TeamUpdraft hasn’t said how the intruder got in. Self-hosted UpdraftCentral wasn’t affected, and nor were the plugin downloads.
The first known backdoor went in at 15:32 on 18 October, the most recent at 09:23 the next morning. Every one used the same command, plugin.upload_plugin, which tells a site to install and activate a plugin. The command was signed with a genuine dashboard key, so the site installed it. The requests came from the attacker’s own server as ordinary POST requests to the site’s home page.
What the backdoor does
Three variants have been found so far. Each one logs in anyone who visits the site with a secret parameter in the URL carrying a 32-character token.
One variant creates a user with a name like data-ops43, the display name “Site Tools” and an @example.org email address. It gets the Editor role, which draws less attention than Administrator in a list of users, plus two extra permissions: changing site settings and installing plugins. With those, the attacker can install more code or make the account an Administrator. It logs the visitor in by setting the login cookie directly, so the login page never runs and two-factor authentication never gets a look in.
Nethemba found two more. One creates a full Administrator account with an @example.com address. The other creates no account at all and logs in as the site’s first existing administrator, which leaves almost nothing in the database.
Removing the plugin doesn’t remove any account it created, and the attacker knows those passwords. Some copies have a bug that makes the site return an HTTP 500 error on every uncached page. If your site started erroring on 18 or 19 October, this could be why. Don’t try to fix the plugin, as fixing that bug makes the backdoor work.
What we did
We picked this up on 19 October and treated it as an incident. We added a temporary WAF rule across our fleet that blocks the remote command channel UpdraftCentral uses. The command never reaches WordPress, so it doesn’t matter whose key signed it or whether the site has been updated.
The rule can’t tell the attacker’s commands from yours, so while it’s in place:
- UpdraftCentral can’t manage your site remotely.
- UpdraftPlus Migrator can’t send a backup directly to another site.
Scheduled backups, manual backups, restores and uploads to your remote storage all work as normal. (If you use UpdraftVault, TeamUpdraft disconnected every site from it, so you’ll need to reconnect.)
We’re also adding rules that block requests carrying the backdoor’s login trigger, so a backdoor that’s already installed can’t be used, and the attacker’s known IP address. The IP block matters least, as the attacker moved to new infrastructure within a day.
What you should do
Update UpdraftPlus. Free users need 1.26.12 or later, Premium users the latest Premium release. If you’re on 1.26.4 or older, you’re also exposed to CVE-2026-10795, an earlier bug that let attackers forge UpdraftCentral commands without a key. It was fixed in June.
If you don’t use UpdraftCentral, delete the key. Go to Settings > UpdraftPlus > Advanced Tools > UpdraftCentral in your site’s own WordPress dashboard. Removing the site from the UpdraftCentral dashboard isn’t enough, because the key lives on the site. Do this even if you’ve never knowingly used UpdraftCentral. To check from the command line, any output from this means the site has a key:
wp option get updraft_central_localkeysCheck your users. Look for any Administrator or Editor you don’t recognise, and in particular:
- usernames made of two words and two digits, such as
data-ops43ormedia-staff96 - the display name “Site Tools”
- email addresses at
@example.orgor@example.com
One variant creates no account, so a clean user list doesn’t prove the site is clean.
Check your plugins, including the Must-Use tab. The most reliable sign is the description “Small maintenance toolkit: keeps option storage tidy.” The name “Site Health Cache” turns up repeatedly, but most of the 99 names seen so far are random two- or three-word names used once. The sources below list them all. Don’t delete a suspect plugin from wp-admin, because its uninstall routine wipes the evidence.
Change your TeamUpdraft.com password, and any other password you’ve reused it on. Type the address in yourself, and be wary of emails claiming to be from TeamUpdraft.
If you find any of the above, treat the site as compromised. If it’s hosted with us, contact support before you remove anything and we’ll work through it with you. If it’s hosted elsewhere, the write-ups below cover clean-up in detail. Start by deleting the UpdraftCentral key, so the attacker can’t push a replacement, then restore from a backup taken before 17 October, change every administrator password and log out all sessions.
Remote management keys
This attack needed no bug in UpdraftPlus. The plugin trusted commands signed by a dashboard it was connected to, as designed, and the keys for a lot of sites were held in one database elsewhere. A pre-ticked checkbox meant many of those sites were connected without their owners noticing.
Other tools that manage WordPress remotely work in a similar way. If you use any, check which are connected to your sites and disconnect the ones you don’t use. We wrote more about this sort of thing in the strange new world of server security.
Sources and thanks
Nethemba and Patchstack published their findings during a live incident so that others could act on them. Thanks to both.
- Critical security problem in UpdraftCentral: an attacker holding the service’s keys planted a backdoor on our websites. Nethemba’s write-up of the attack on their own sites, covering all three backdoor variants and a read-only checking script.
- Stolen UpdraftCentral keys are backdooring WordPress sites. Patchstack’s advisory, with the full list of plugin names seen so far.
- TeamUpdraft security incident: what customers need to know. TeamUpdraft’s statement on the breach and the steps they’ve taken.
