UpdraftCentral keys are being used to backdoor WordPress sites right now

Since Saturday afternoon, someone holding valid UpdraftCentral dashboard keys has been installing backdoor plugins on WordPress sites connected to that service. The commands are properly encrypted and correctly signed. Every security check the plugin performs passes, because from the site's point of view nothing is wrong — its remote manager asked it to install a plugin, so it did.

TeamUpdraft has said it believes the TeamUpdraft.com customer database was accessed over the weekend of October 17-18, and that the database holds UpdraftCentral, UpdraftVault and UpdraftClone connection keys.

There is no plugin update that fixes this today. Running the newest version of UpdraftPlus does not help, because the problem was never in the plugin's code. The fix is to delete your UpdraftCentral connection key on every site, and to do it now rather than waiting for the emergency release TeamUpdraft has said is coming.

wp option get updraft_central_localkeys

What's happening

The first backdoor installation Patchstack observed was at 15:32 UTC on October 18th, and the campaign ran continuously from there — the most recent one logged as this is written was at 09:23 UTC on October 19th. Patchstack has since deployed mitigation rules and is blocking UpdraftCentral remote commands outright.

What makes this different from the usual plugin vulnerability story is the trust model it breaks. UpdraftCentral is a remote-management service: you connect your sites to a dashboard, and that dashboard can install plugins, run updates and manage the site without logging in. For that to work, each site holds a key and obeys signed commands from the service.

Someone else now has those keys. The commands arriving at these sites are not forged, malformed, or exploiting anything. They are legitimate instructions from a legitimate controller, and the only thing wrong with them is who is sending them.

Your UpdraftCentral connection keys can send commands to your connected sites, so please secure each site directly rather than waiting for our update.

That is TeamUpdraft's own guidance, published this afternoon in their incident notice, and it is the right instruction. The rest of this post is about carrying it out properly — including one place where the vendor's checklist, followed literally, will tell you a compromised site is clean.

What was and wasn't affected

Affected or at risk:

• UpdraftCentral cloud connection keys, which can send commands to your sites

• UpdraftVault keys — every site has been disconnected, so Vault backups are not running until you reconnect

• UpdraftClone client keys — all replaced, so old keys now fail

• Names, email addresses, billing addresses and order history

• Account passwords, hashed rather than plain text, and two-factor authentication settings

Not affected:

• The UpdraftPlus plugin itself and its downloads

• Backups already sitting in your own remote storage — Google Drive, Dropbox, Amazon S3

• Self-hosted UpdraftCentral installations

• Payment card details — TeamUpdraft stores none; Stripe and PayPal handle payments

• Free UpdraftPlus users with no TeamUpdraft.com account

What the backdoor actually does

The command sent is plugin.upload_plugin, and WordPress installs and activates the result. From there:

1. The plugin hooks early into every request and watches for a secret 32-character URL token.

2. When that token appears, it creates a user account with a hardcoded password and the Editor role — then quietly grants that account manage_options and install_plugins.

3. It sets the login cookie directly. That bypasses the login form entirely, and with it two-factor authentication and every login-limiting plugin you have.

4. The account stays behind after the plugin is gone.

There's one piece of luck in this: the samples analysed so far contain a coding error that throws HTTP 500 errors on uncached requests. That is how several victims noticed at all. If your site started throwing intermittent 500s over the weekend, do not treat it as a performance problem.

Indicators of compromise

• Plugin description. The attacker used 99 different plugin names, mostly random two- and three-word combinations — Site Health Cache recurs and is the strongest name-based signal. Far more reliable is the description, identical across every sample analysed: Small maintenance toolkit: keeps option storage tidy. Search wp-content/plugins/ for that line, and check the Must-Use tab as well as the main plugin list.

• The account. Any Editor-role user that also holds manage_options. Confirmed usernames include data-ops43 and media-staff96. Watch also for an @example.org email address or the display name Site Tools.

• The database option. An entry whose name ends in _sync_token.

• The UpdraftCentral log. Entries showing probe.central.updraftplus.com followed by Command received: plugin.upload_plugin.

• Access logs. The 32-character token parameter appearing in a request URL means the backdoor was used, not merely installed. That changes the severity considerably.

• User-Agent. Genuine UpdraftCentral traffic carries a library version and URL in its User-Agent string. The attacker's requests carry neither.

• Source IPs, useful for log review but not as a control: 43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9.

If we manage your WordPress site

You don't need to do anything, and you don't need to wait on an all-clear email before you stop thinking about this.

We don't use UpdraftCentral to manage client sites, so none of our own management tooling is implicated in this incident. That said, a key doesn't have to be ours to be live on a site — the default-ticked checkbox means a site can be connected without anyone choosing to connect it. So we swept the sites under management for an active UpdraftCentral key rather than for whether the service was ever deliberately set up. Keys we found are being removed. Any site that held one is being checked against the full indicator list above, not just scanned for the plugin name — the plugin name is the least reliable signal in this incident, and the account outlives the plugin.

We're checking by capability rather than by role, for the reason described above, and we're checking Vault connections too, so that no site ends the week silently not backing up.

Where anything needs more than key removal, you'll hear from us directly about your site, with what we found and what we're doing about it. Not a broadcast — a conversation. And if you'd simply like the result in writing for your own records, ask and we'll put it together.

If you manage your own site

Work through this per site. The order matters: delete the key first, so that no further commands can arrive while you're cleaning up.

1. Check whether the site has a key at all. Run wp option get updraft_central_localkeys, or look in wp-admin under Settings > UpdraftPlus > Advanced Tools > UpdraftCentral. Do this even if you're certain you never used the service. No key means no exposure to this campaign — but check rather than assume.

2. Delete every key, from the site itself. Log in to the site's own WordPress dashboard rather than going through UpdraftCentral. Go to Settings > UpdraftPlus > Advanced Tools > UpdraftCentral and delete the connection key. Or via WP-CLI: wp option delete updraft_central_localkeys. Removing the site from the UpdraftCentral dashboard does not remove the key from the site, and the key is what authorises incoming commands.

3. Look for the plugin, including Must-Use. Search wp-content/plugins/ for the description string Small maintenance toolkit: keeps option storage tidy. Check the plugin list for anything you don't recognise, particularly Site Health Cache, and check the Must-Use tab if your installation shows one.

4. Audit users by capability, not by role. This is the step most people will get wrong. List every account holding manage_options, not every account with the Administrator role. The backdoor account is an Editor with elevated capabilities and will not appear in the administrator list.

5. Check the logs. In the UpdraftCentral log, look for probe.central.updraftplus.com and Command received: plugin.upload_plugin. In your access logs, search for a 32-character token parameter. Finding the command means the backdoor was installed; finding the token means it was used.

6. If you find a backdoor, work in this order. Delete the UpdraftCentral key first. Then deactivate the plugin and move it out of the web root rather than deleting it through wp-admin. Remove the _sync_token option. Remove the backdoor account. Change the passwords for every administrator account on the site.

7. If the account existed, or the token appears in your logs, treat the site as fully compromised. Restore from a backup taken before October 17th, compare files against a clean install, review every user holding extra capabilities, rotate administrator passwords, invalidate all sessions, and enable two-factor authentication. The attacker had the ability to run arbitrary code, so anything the site could read should be considered read.

8. Reconnect Vault, and run a test backup. If you use UpdraftVault for storage, reconnect each site: Settings > UpdraftPlus > Settings, choose UpdraftVault under remote storage, and under Already got space? click Connect with your TeamUpdraft.com email and new password. Save changes, then run a manual backup and confirm it completes. Until you do this, that site has no Vault backups.

9. Secure the TeamUpdraft.com account itself. Change your TeamUpdraft.com password — type the address into your browser rather than following a link from an email. Change it anywhere you reused it. Reset two-factor authentication in My Account if you use it. If you've shared UpdraftClone client keys with your own clients, collect the new ones from My Account > UpdraftClone > UpdraftClone Key Management and send them on, because clones using old keys will fail.

The part worth remembering afterwards

Every site hit here did the right things. Current WordPress, current plugins, patched against June's flaw. None of it mattered, because the compromise happened upstream of the site entirely, in a service the site had been told to trust.

That's the real lesson in remote-management tooling, and it applies well beyond this one product. Anything that can install a plugin on your site without logging in is, functionally, an administrator — and its security is now part of yours. It deserves the scrutiny you'd give an admin account: does it need the permissions it has, do its credentials ever expire, and would you notice if somebody else started using them?

Three habits come out of this:

• Scope management keys down. A remote-management key tied to an account without install_plugins would have turned this incident into a failed command.

• Know what's connected. The sites in the worst position today aren't the ones that used UpdraftCentral. They're the ones that held a key for years without knowing it.

• Keep backups somewhere your vendor's incident can't reach. Sites using Vault as their only destination lost their backup pipeline as a side effect of someone else's breach.

Common questions

Will updating UpdraftPlus fix this?
Not yet. This was not a flaw in the plugin's code, so there was no patched version to move to. TeamUpdraft has an emergency release in progress that will automatically disconnect every UpdraftCentral connection made before 22:00 BST on October 18th, but it had not shipped at the time of writing. Delete your keys manually rather than waiting for it.

I use UpdraftPlus but never set up UpdraftCentral. Am I safe?
Check before concluding that. Connecting a site to a TeamUpdraft.com account offers UpdraftCentral access via a checkbox that is ticked by default, and the resulting keys never expire. Run wp option get updraft_central_localkeys on the site — any output means it is exposed.

Will deleting the UpdraftCentral key stop my backups?
No. Backups, schedules and remote storage all continue working. Deleting that key only disables remote management through the UpdraftCentral dashboard. Your UpdraftVault connection is a separate thing, and it is a different story — see the next question.

I use UpdraftVault. Is anything different for me?
Yes, and it is urgent in its own quiet way. TeamUpdraft disconnected every site from UpdraftVault and issued new credentials, so no backup is reaching Vault until you reconnect each site and run a test backup. Backups already stored in Vault are not affected, but new ones are not being created.

I removed my site from the UpdraftCentral dashboard. Is that enough?
No. The key lives on the site, and that is what authorises incoming commands. It has to be deleted from the site itself, through Settings > UpdraftPlus > Advanced Tools > UpdraftCentral, or with WP-CLI.

I checked my administrators and they all look fine. Am I clear?
Not necessarily, and this is the most important thing in this post. The backdoor account is created with the Editor role and then granted manage_options and install_plugins, so it has administrative power without appearing in the administrator list. Audit by capability instead: anything holding manage_options that is not a known administrator.

I found the plugin and deleted it. Am I clean?
Not yet. The account persists after the plugin is removed. Remove the account and the option ending in _sync_token as well, and if the 32-character token appears in your access logs, treat the site as fully compromised rather than cleaned.

My site threw random 500 errors over the weekend. Is that related?
Possibly. The backdoor samples analysed so far contain a bug that causes HTTP 500s on uncached requests, and that is how several site owners discovered it. Investigate it as a security event rather than a performance one — and do not fix the error, because correcting it makes the backdoor work properly.

Is self-hosted UpdraftCentral affected?
No. TeamUpdraft states that self-hosted UpdraftCentral is not affected. This incident concerns the cloud service, whose keys were held in the breached customer database.

Is this the same as the UpdraftPlus vulnerability from June?
No, though they share a channel. CVE-2026-10795 was an authentication bypass patched in 1.26.5 and 2.26.5. If you are still on 1.26.4 or earlier, forged commands work against you without any key at all, so update as well as deleting keys.

If you need a hand with this

If you've found the plugin, the account, or that token in your access logs, the cleanup is bigger than deleting files. The account survives the plugin, the attacker had the ability to install arbitrary code, and anything the site could read should be considered read.

We do WordPress incident response and malware removal, including the tedious parts: establishing how far the access went, auditing capabilities rather than roles, rotating credentials across every connected service, and watching the site afterwards to confirm it's actually clean. If you're affected, or you're not sure whether you're in scope and want someone to check properly, get in touch — say it's UpdraftCentral and we'll treat it as urgent.

You don't need to be an existing client to ask. If all you want is a straight answer about whether your sites are exposed, ask us that and we'll tell you.