UpdraftCentral keys are being used to backdoor WordPress sites right now

Since Sunday morning, 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 now a plugin update, and it is worth installing — but it does not finish the job. UpdraftPlus 1.26.13 and 2.26.13 revoke stolen cloud keys automatically, and the cutoff they use stops nearly nine hours short of the one TeamUpdraft advertises, inside the window when the attack was already running. The fix that works is still to delete your UpdraftCentral connection key on every site, by hand, today.

wp option get updraft_central_localkeys

What's happening

The first backdoor installation Patchstack observed was at 11:32 a.m. ET on October 18th (15:32 UTC), and the campaign ran continuously from there — the most recent one logged in their analysis was at 5:23 a.m. ET on October 19th (09:23 UTC). 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.

That is TeamUpdraft's own guidance, from their incident notice. As first published on October 19th the sentence ended 'rather than waiting for our update', a phrase since removed now that the update exists. It was the right instruction then, and for the reasons below it is still the right instruction now. 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

One wrinkle in that second list: TeamUpdraft has since added advice to reauthorize your remote storage and change its access keys if your site was reached through UpdraftCentral. That sits a little awkwardly beside 'remote storage is not affected', and the reconciliation is straightforward — the storage service was never breached, but a site running attacker-supplied code could read whatever credentials that site held. If a site of yours was connected, rotate them.

The emergency release, and what it misses

UpdraftPlus 1.26.12 and 2.26.12 were released on October 19th to revoke the stolen UpdraftCentral cloud keys. Per the plugin's own changelog they did not work: 1.26.13 followed the same evening carrying the release note FIX: Properly apply the revocation in 1.26.12. Install 1.26.13 or 2.26.13 or later — not 1.26.12, which TeamUpdraft's incident page was still instructing people to install at the time of writing.

Then check your keys anyway, because the revocation is narrower than advertised. It runs on every page load and deletes cloud keys created before a hardcoded timestamp:

$this->udcentral_keys_revocation(1792325220);

That Unix timestamp is 8:07 a.m. ET on October 18th, 2026 (12:07 UTC). TeamUpdraft's incident notice says the release 'automatically disconnect[s] every UpdraftCentral connection' made before 5:00 p.m. ET on October 18th (21:00 UTC). Those two statements are not the same, and the difference is nearly nine hours.

The plugin does also accept a remote command, revoke_keys_issued_before, which lets TeamUpdraft push a wider revocation later without shipping another release. That is sensible design, and it means today's cutoff may not be the final one. It also means the thing protecting your site is a command you don't control, arriving over the same channel the attacker has been using.

One caveat for Premium users: TeamUpdraft lists 2.26.13 as released, but reports on October 20th indicated it had not yet reached every Premium installation. If it hasn't appeared for you, don't wait — deleting the key doesn't require it.

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 analyzed 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 analyzed: 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 pre-checked box 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. We are removing keys by hand rather than relying on the update's revocation, for the reasons set out above.

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 authorizes incoming commands.

3. Update UpdraftPlus — to 1.26.13 or 2.26.13, not 1.26.12. Do this after deleting the key, not instead of it. The update revokes cloud keys created before 8:07 a.m. ET on October 18th (12:07 UTC), which covers most sites but not keys issued during the hours the attack was already running. 1.26.12 shipped first and, per the plugin's changelog, did not apply its revocation correctly.

4. 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 recognize, particularly Site Health Cache, and check the Must-Use tab if your installation shows one.

5. 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.

6. 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.

7. 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.

8. 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. Reauthorize your remote storage and rotate its access keys as well — a site that ran attacker-supplied code had access to whatever storage credentials it held. The attacker had the ability to run arbitrary code, so anything the site could read should be considered read.

9. 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.

10. 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.

11. Expect phishing. The breached database held names, email addresses, billing addresses and order history — exactly the material a convincing message needs. TeamUpdraft has reported the incident to the UK's data protection regulator and says it will never ask for your password or keys. Treat any unexpected email about this incident accordingly.

The part worth remembering afterward

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?

Four 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.

• Verify the remedy, not just the advisory. The release note and the code did not say the same thing here, and the gap between them was nine hours wide in the middle of a live attack. Where a one-line command settles it yourself, run the command.

Common questions

Will updating UpdraftPlus fix this?
Partly, and only if you update to the right version. UpdraftPlus 1.26.13 and 2.26.13 revoke UpdraftCentral cloud keys created before 8:07 a.m. ET on October 18th (12:07 UTC). Keys created after that — including during the hours the attack was already running — are left in place, and no update removes a backdoor that is already installed. Update, then delete your keys by hand and check the site. Don't settle for 1.26.12: per the plugin's changelog, its revocation did not apply.

I updated and the key is gone. Am I clean?
It means that key can no longer be used. It does not mean nothing was done with it first. If the site was connected to UpdraftCentral at any point since October 17th, work through the indicators above — the plugin, the Editor account holding manage_options, the _sync_token option, and the token in your access logs. The account outlives both the plugin and the key.

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 checked 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 authorizes 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 analyzed 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 afterward 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.