The UpdraftCentral breach: how stolen keys put backdoors on UpdraftPlus sites, and what to check

Over the weekend of 17-18 October, someone got into teamupdraft.com, the site behind UpdraftPlus. TeamUpdraft says it believes its customer database was accessed, and that database held the connection keys for UpdraftCentral, the company’s remote management service. By the afternoon of 18 October, an attacker holding valid UpdraftCentral keys was installing backdoor plugins on connected WordPress sites. Patchstack’s monitoring recorded 99 differently named backdoor plugins between that afternoon and the next morning.

The campaign did not need a bug in UpdraftPlus. Every command was encrypted and signed with real dashboard keys, so each check on the receiving site passed. Patchstack’s verdict: “This is not a vulnerability in UpdraftPlus.”

Nethemba found the attack on three of its own sites in the early hours of 19 October and published the first analysis while the campaign was still running. Patchstack’s write-up confirms it and widens the scope. This piece brings the three sources together: how the channel works, what the backdoors do, where the vendor’s checklist falls short, and what to check on every site running UpdraftPlus.

What TeamUpdraft says was taken

According to the vendor’s notice, the customer database holds:

• each customer’s name, email address, billing address and order history
• account passwords, stored as hashes
• two-factor authentication settings
• connection keys for UpdraftCentral, UpdraftVault and UpdraftClone

Card details are not stored there; Stripe and PayPal handle payments. The vendor says the plugin and its downloads were not affected, and neither were backups sent to customers’ own remote storage or self-hosted UpdraftCentral dashboards.

In response, TeamUpdraft signed every account out, disconnected every site from UpdraftVault, replaced every UpdraftClone key, and released UpdraftPlus 1.26.12 (free) and 2.26.12 (Premium) to disconnect UpdraftCentral connections made before 22:00 BST on 18 October. It has reported the incident to the UK Information Commissioner’s Office. As of 20 October it has not said how the attacker got in.

How UpdraftCentral reaches your site

The UpdraftCentral client ships inside every copy of UpdraftPlus, free and Premium, and does nothing until the site has a key. Creating one sets up a key pair on the site and stores the dashboard’s public key. From then on, the site runs any command signed with the dashboard’s private key, with the permissions of the WordPress user who created the connection. Nobody approves individual commands, and the commands on offer include uploading and activating a plugin.

The dashboard’s private keys never leave UpdraftCentral Cloud. As Nethemba writes, every connected site depends on one assumption: that those keys stay there.

Three details that made it worse

• Keys do not expire. Keys created in November 2025 still worked in October 2026, and another administrator reported abuse of keys from 2022. An old key was no safer than a fresh one.
• Some keys were created by default. When you log in to a teamupdraft.com account from UpdraftPlus Premium to activate the licence, the option “Add this website to UpdraftCentral” is ticked unless you untick it. Nethemba confirmed this in the code of 2.26.11 and did not find the checkbox in the free 1.26.12. Patchstack reports sites with active keys whose owners only ever used UpdraftPlus for backups.
• The key that counts is stored on the site. Removing a site from the UpdraftCentral dashboard leaves it in place, and a stolen dashboard key keeps working until the site deletes its own. Nethemba saw the attacks on its sites begin after the vendor had confirmed the breach and closed the attacker’s access.

UpdraftPlus has more than four million active installations. For a flaw in the same channel in June, the vendor estimated that fewer than 10% of users have an UpdraftCentral or Migrator key, which Nethemba puts at up to around 400,000 sites. Nobody has published how many of those were hit.

How the attack ran

The attacker first sent each site a probe addressed to a key that does not exist. A site that answers it accepts UpdraftCentral commands. A few hours later came the real command, an instruction to upload a plugin, signed with that site’s dashboard key. WordPress installed and activated the plugin through its standard installer, the same route a plugin you install yourself takes.

The requests came from the attacker’s own server, not from TeamUpdraft’s. Real dashboard traffic carries a library version and the teamupdraft.com address in its User-Agent header; the attacker’s requests carried neither.

On Nethemba’s third site the install failed. The key there had been created by a user who no longer had the right to install plugins, and UpdraftCentral checks that before installing. Patchstack saw other installs that never activated, consistent with the same limit, and still treats those sites as affected because the files arrived.

The attacker also came back. On one administrator’s site they deleted a broken backdoor and uploaded a different one two seconds later. Another site received three variants within ten hours. The same IP address had sent path traversal attempts to other sites on 23 September, almost a month before.

When	What happened	Source
June 2026	CVE-2026-10795 fixed in UpdraftPlus 1.26.5 / 2.26.5. Older versions accept forged UpdraftCentral commands with no key at all.	Patchstack
23 September	The attacker’s IP address sends path traversal attempts to other sites.	Nethemba
17-18 October	Unauthorised access to teamupdraft.com.	TeamUpdraft
18 October, afternoon	First backdoor install in Patchstack’s data.	Patchstack
19 October, early hours	Backdoors installed on two of Nethemba’s three sites.	Nethemba
19 October, morning	Latest install in Patchstack’s data.	Patchstack
19 October	Vendor notice. UpdraftPlus 1.26.12 / 2.26.12 released, then 1.26.13 / 2.26.13 the same evening.	TeamUpdraft, Nethemba
20 October	Nethemba documents the pre-ticked checkbox and a backdoor that hides from the plugin list.	Nethemba

What the backdoors do

Nethemba and the administrators who sent it samples have described four kinds so far. All of them arrive as ordinary-looking plugins, with a GPL header and an invented publisher.

The first variant: a disguised account

Given a secret 32-character token in the URL, it creates a user with a password written into the plugin, gives it the Editor role, then adds two capabilities on top: manage_options and install_plugins. It logs the visitor in by setting a 14-day cookie directly. The login form never runs, so two-factor authentication, login attempt limits and login protection plugins never run either.

In the user list the account shows as an Editor. With install_plugins it can run any code on the server, and with manage_options it can make itself a full administrator. The account stays after the plugin is removed, and the attacker knows its password.

The samples Nethemba analysed contain a coding error that crashes PHP 8 before the token check, so every uncached request returned error 500. Early victims found out from WordPress’s own email about a failing plugin. Fixing that error would switch the backdoor on, so remove the plugin rather than repair it.

The working variant: no account needed

Without extra parameters it logs the attacker in as the first existing administrator and writes nothing to the user tables. The plugin file and a line in the access log are all it leaves. In setup mode it creates a real administrator and tries to hide it from the user list. That hiding code does not work, so the account shows up normally.

The minimal variant

A single 673-byte file with the token written into the code. It logs the attacker in as the first administrator and creates no account.

The hidden variant

Site Health Cache, a plugin title Patchstack saw again and again, removes itself from the plugin list and from the recently active list. It is active, and you will only see it on disk.

Where the vendor’s checklist falls short

TeamUpdraft’s steps for UpdraftCentral users were last updated at 19:03 BST on 19 October. Compared with the two technical write-ups, four of the steps are incomplete.

• The version. The notice says to update to 1.26.12 or 2.26.12. Nethemba read the code: because of a bug, that release deletes no keys. 1.26.13 / 2.26.13, released the same evening, deletes keys created before 12:07 UTC on 18 October. Keys created between 12:07 and 21:00 UTC that day survive and have to be deleted by hand.
• The users. The notice says to look for administrator accounts you do not recognise. The first variant’s account is an Editor, and the working and minimal variants create no account at all.
• The plugins. The notice says to check the plugin list, including Must-Use plugins. Site Health Cache hides itself from that list, and a plugin that failed to install can still leave its unpacked files in wp-content/upgrade.
• Reconnecting. The notice ends with reconnecting the site to UpdraftCentral. Patchstack advises against reconnecting until the vendor explains how the keys leaked. If you need remote management, create the key under an account that cannot install plugins. On Nethemba’s third site, that alone stopped the attack.

One more limit: UpdraftCentral’s own log keeps only the last 50 events, so on a busy site the record of the attack may already be gone. Check the web server’s access logs as well.

What to check on every site running UpdraftPlus

Do this even if you have never used UpdraftCentral. Patchstack and Nethemba both found keys on sites whose owners never set one up on purpose.

Cut the connection

1. Update UpdraftPlus to 1.26.13 (free) or 2.26.13 (Premium) or later.
2. Delete every remaining key under Settings > UpdraftPlus Backups > Advanced Tools > UpdraftCentral > Manage existing keys. With WP-CLI, the first command below shows whether a key exists (any output means the site still accepts commands) and the second deletes them.
3. Remove the site from the UpdraftCentral dashboard as well. Backups keep running after the key is gone; only remote management stops.
4. Change your teamupdraft.com password by typing the address into the browser, change it anywhere you reused it, and reset two-factor authentication.

wp option get updraft_central_localkeys
wp option delete updraft_central_localkeys

Look for the backdoor

1. Run Nethemba’s read-only checking script from the WordPress root. It reads plugin files from disk, so it finds the variant that hides from wp-admin, and --skip-plugins stops a broken backdoor from crashing WP-CLI.
2. On the same UpdraftCentral screen, open “View recent UpdraftCentral log events” and look for Command received: plugin.upload_plugin, plugin.delete_plugin and probe.central.updraftplus.com.
3. Search the access logs for POST requests with the User-Agent WordPress/6.4; class-udrpc.php, and for the backdoors’ trigger parameters (Nethemba’s article has the search command). A matching request answered with a 302 redirect most likely means the attacker logged in.
4. Look for users by capability, not by role: Editors who also hold manage_options, and accounts with an @example.org or @example.com address and a display name such as “Site Tools” or “System Team”.

wp eval-file check-updraftcentral.php --skip-plugins --skip-themes

Indicator	Value
Source IP addresses	43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9
User-Agent	WordPress/6.4; class-udrpc.php (real dashboard traffic adds a library version and a URL)
Plugin description, first variant	“Small maintenance toolkit: keeps option storage tidy.”
Account email	@example.org or @example.com
Database options	<slug>_sync_token, <slug>_uid, <slug>_installed, <slug>_ver, sh_cache_ver

Patchstack notes that the attacker changed addresses within a day, so blocking the two IPs does not protect a site.

If you find one

1. Delete the UpdraftCentral key first. Otherwise the attacker can push a corrected replacement.
2. Deactivate the plugin and move its folder out of the web root. Deleting it from wp-admin runs its uninstall routine, which removes some of its own traces.
3. Delete its options and any account it created.
4. Change every administrator password and end all logged-in sessions.
5. If the account exists, or the trigger parameter appears in your access log, treat the whole site as compromised. The attacker could have added more plugins or scripts and changed files or the database.

Your backups are part of the cleanup

All three sources end at the same step: restore from a backup taken before 17 October. That step works only if four things hold.

A copy from before the attack still exists

Keys from 2022 were still valid this month, the attacker was testing sites in September, and two of the backdoor variants leave almost nothing in the database. A site hit this week could go unnoticed for weeks. With seven days of retention, every copy you hold by then contains the backdoor.

Backups are still running

Every site was disconnected from UpdraftVault, and the vendor says backups will not reach Vault until each site is reconnected by hand. Check the date of the newest backup on every site, including the ones you do not manage day to day.

The attacker could not reach them

UpdraftPlus stores the credentials for its remote storage in the site’s own settings, and a working backdoor gives the attacker code execution on that site. For that reason the vendor advises re-authorising remote storage and changing storage access keys on any site reached through UpdraftCentral. A copy kept under credentials the site never holds stays out of the attacker’s reach.

You can restore less than everything

Rolling the whole site back to 16 October also removes every post, comment, order and customer account added since. On a busy shop that means days of orders. If your backups can restore individual files and tables, you can put back the plugin folders and the user tables from before the attack, keep the rest, and then compare the files against a clean installation as Nethemba advises. On a shop, check the users table before you replace it, because customers who registered after 16 October would go with it.

Backvera is built around those four points. Our servers take the backups on their own schedule and store them in Backvera Cloud, and your site holds no storage credentials for an attacker to read. If a site’s backup fails, we email you. Retention runs up to 365 days, so a copy from before an attack is still there when the attack is found weeks later. Restores go down to a single file, table or order, with a dry run first if you want one, and you can restore into a staging copy before you touch production.

None of that stops a signed command from a stolen key. After an attack, you can go further back and lose less on the way.

The wider lesson

A remote management key that can install plugins carries the same power as an administrator password. This one was held by a third party, never expired, was sometimes created by a pre-ticked checkbox, and kept working until each site deleted it.

UpdraftCentral is not the only service of its kind. Remote management dashboards, backup services and security services all hold some form of key to the sites they serve. For each one connected to your sites, know what the connection can do, which WordPress account it runs as, and how to cut it off from the site itself rather than from the vendor’s dashboard. Where a service lets you choose, connect it under an account that cannot install plugins.

TeamUpdraft has not yet said how the attacker got into teamupdraft.com. Until it does, delete the keys by hand and check every site with the script. The update alone leaves some keys in place and checks nothing.

Sources

• TeamUpdraft security incident: What customers need to know, TeamUpdraft, 19 October 2026
• Stolen UpdraftCentral Keys Are Backdooring WordPress Sites, Patchstack, 19 October 2026
• Critical security problem in UpdraftCentral: an attacker holding the service’s keys planted a backdoor on our websites, Nethemba, updated 20 October 2026