CriticalSupply chainMonitoring

UpdraftCentral key compromise: stolen TeamUpdraft keys used to push 99 backdoor plugins to WordPress sites running UpdraftPlus

Stolen UpdraftCentral keys let attackers install backdoor plugins on UpdraftPlus sites. Update to 1.26.13 or 2.26.13, delete keys, then hunt for the backdoor.

Published
Updated
Fixed in
UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium) revoke the stolen keys but do not remove backdoors already installed
Exploitation
Yes. Patchstack observed backdoor installs from 18 to 19 October 2026 and 99 distinct backdoor plugin names

What happened

On 17 and 18 October 2026, attackers got into teamupdraft.com, the vendor site behind the UpdraftPlus backup plugin. TeamUpdraft says they took customer names, emails, billing addresses, order history, hashed passwords and 2FA settings, plus the connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. Card data, the UpdraftPlus plugin downloads, self-hosted UpdraftCentral and backups in customers’ own storage were not affected (TeamUpdraft).

The keys were the problem. UpdraftCentral lets a dashboard send signed commands to any site that holds a key, and every copy of UpdraftPlus ships the client. Patchstack found (Patchstack):

  • 18 October, 15:32: first backdoor install observed. 19 October, 09:23: most recent. The campaign ran continuously for 18 hours. Nethemba spotted it first, on three of its own sites.
  • The attacker sent a correctly signed plugin.upload_plugin command over the plugin’s RPC channel, an ordinary POST to the site root. WordPress then installed and activated the plugin through its normal installer.
  • 99 distinct plugin names, mostly random two- or three-word combinations. “Site Health Cache” was reused often. Every sample had the same description line.
  • Keys never expire. Keys issued in November 2025 still worked in October 2026.
  • The TeamUpdraft.com connection screen’s “Add this website to UpdraftCentral” checkbox is ticked by default, so sites that never used UpdraftCentral could still hold a key.

TeamUpdraft released UpdraftPlus 1.26.13 and 2.26.13 just after 22:00 BST on 19 October. They revoke UpdraftCentral keys and WordPress.org pushed them to all users. On 29 October TeamUpdraft warned that some sites were compromised without visible signs, and that a plugin left by the attacker created a new administrator after the site was disconnected (TeamUpdraft).

What the backdoor does

All details from Patchstack, which credits Nethemba for the first analysis.

  1. It hooks every request and waits for a secret URL parameter carrying a 32-character token. In the first variant the name is an underscore plus a few characters, such as _9f5696. Nethemba also saw 12-hex-character names, such as f2b9faa21ebd, and a fixed 83e590bb7e9b (Nethemba).
  2. With the right token it creates an account with a hardcoded password, gives it the Editor role, then adds manage_options and install_plugins. That is enough to run code and promote itself to administrator. Nethemba found a second variant that creates a full administrator, and one that logs in as an existing administrator without creating any account (Nethemba).
  3. It sets a login cookie directly and redirects to wp-admin, so 2FA and login-limit plugins never run.
  4. The account survives removal of the plugin. Some variants hide from the Plugins and Users screens, and some erase evidence when deleted through the dashboard (TeamUpdraft).
  5. Analysed samples had a bug that caused HTTP 500 errors before the token check. Patchstack warns that “fixing” the plugin turns the backdoor on.

Am I affected?

Does the site hold a key? Any output means exposure:

bash
wp option get updraft_central_localkeys
wp plugin list --fields=name,status,version | grep -i updraftplus

Find the backdoor by its description, in normal and must-use plugins:

bash
grep -rl "Small maintenance toolkit: keeps option storage tidy" wp-content/plugins/ wp-content/mu-plugins/ 2>/dev/null

Find Editor accounts with administrator powers, and the backdoor’s options (Nethemba lists <slug>_sync_token, <slug>_uid and <slug>_installed). Run WP-CLI with --skip-plugins so a hiding plugin cannot filter the result:

bash
wp --skip-plugins db query "SELECT u.user_login,u.user_email,u.user_registered FROM $(wp db prefix --skip-plugins)users u
  JOIN $(wp db prefix --skip-plugins)usermeta m ON m.user_id=u.ID
  WHERE m.meta_key LIKE '%capabilities' AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"
wp --skip-plugins db query "SELECT option_name FROM $(wp db prefix --skip-plugins)options WHERE option_name LIKE '%\_sync\_token'"
wp --skip-plugins user list --fields=user_login,user_email,roles,user_registered

Confirmed usernames include data-ops43 and media-staff96, with display name “Site Tools” and an @example.org address. Other names exist (Patchstack).

Check access logs. A hit on the first command means the backdoor was used, not just installed. The second looks for the attacker addresses Patchstack and Nethemba published. The attacker’s User-Agent was WordPress/6.4; class-udrpc.php on POST /, while genuine UpdraftCentral traffic carries a library version and a teamupdraft.com URL (Nethemba; Patchstack):

bash
grep -E '[?&](_[A-Za-z0-9]{4,10}|[0-9a-f]{12})=[A-Za-z0-9_]{32}([&"[:space:]]|$)' /var/log/apache2/*access* /var/log/nginx/*access* 2>/dev/null
grep -E '43\.250\.53\.42|178\.83\.37\.220|2a09:bac5:4e21:2e3c::49b:9' /var/log/apache2/*access* /var/log/nginx/*access* 2>/dev/null

Patchstack notes the attacker changed infrastructure within a day, so a clean IP search proves little.

What to do now

  1. Update UpdraftPlus to 1.26.13 (free) or 2.26.13 (Premium) or later on every site ever connected, including ones you have not looked at in a while (TeamUpdraft). Nethemba notes 1.26.12 and 2.26.12 do not delete the keys.
  2. Delete every UpdraftCentral key: Settings > UpdraftPlus > Advanced Tools > UpdraftCentral > “Manage existing keys”, or wp option delete updraft_central_localkeys. Removing the site from the dashboard is not enough, because the key lives on the site. Backups keep working (Patchstack).
  3. Remove a backdoor in the right order. Delete the key first. Then deactivate the plugin and move its folder out of the web root by SFTP or SSH; do not delete it from wp-admin, because its uninstall routine wipes traces. Then delete the backdoor account and the _sync_token option (Patchstack).
  4. If the account exists or the trigger parameter shows in logs, treat the site as fully compromised: restore a clean backup from before 17 October, compare files with a clean install, end all sessions (wp config shuffle-salts), and reset administrator and editor passwords (TeamUpdraft).
  5. Rotate storage credentials. Reset UpdraftVault and external backup storage keys and reconnect. UpdraftClone users need new client keys from their account (TeamUpdraft).
  6. Change your teamupdraft.com password by logging in directly, not through an email link, and change it anywhere you reused it.
  7. Reconnect to UpdraftCentral only after these checks. If you need it, create the key under an account without install_plugins. In one case Patchstack analysed, that alone stopped the attack.

Why this matters

Nothing in UpdraftPlus was vulnerable. The commands were genuine and correctly signed, so every check on the site passed. One leaked vendor key store turned a backup plugin’s remote management feature into a plugin installer for millions of sites, and a default-ticked checkbox meant many owners did not know they had a key.

Sources