UpdraftCentral Keys Stolen: Check Every UpdraftPlus Site, Even Updated Ones

Over the weekend of 17 and 18 October 2026, someone got into teamupdraft.com, the company behind UpdraftPlus. TeamUpdraft says the customer database it believes was accessed held connection keys for UpdraftCentral, its remote management service. Within hours those keys were being used to push backdoor plugins onto WordPress sites. UpdraftPlus is the backup plugin on more than 4 million active installations, so even a small share of connected sites is a lot of servers.

This one does not behave like a normal plugin bug. The malicious commands were signed with genuine keys, so the plugin accepted them as legitimate. Patchstack notes that the latest releases at the time were affected exactly like older ones, and on 29 October TeamUpdraft added that some sites hit during the original wave looked clean, then grew a new administrator account days later. Updating the plugin is necessary. It is not the end of the job.

What happened, in order

• 18 October, 15:32: first backdoor installation in Patchstack's telemetry. The last one it recorded in that wave was at 09:23 on 19 October.
• 19 October: Nethemba, who caught the attack on their own sites, published the first technical analysis. Wordfence shipped a firewall rule that blocks UpdraftCentral commands on affected versions and released it to free users within hours instead of after its usual 30-day delay.
• 19 October: UpdraftPlus 1.26.12 shipped to revoke cloud keys created before the incident, and 1.26.13 followed the same day because the revocation in 1.26.12 did not apply properly. Premium versions are numbered 2.26.12 and 2.26.13.
• 21 October: Nethemba reports the attacker sent new UpdraftCentral commands to two of their sites after 1.26.13 was out. The vendor later corrected its revocation cutoff to 12:07 UTC on 18 October, so keys created after that moment are not revoked automatically.
• 26 October: UpdraftPlus 1.26.14 stopped adding sites to UpdraftCentral by default when you connect a TeamUpdraft account.
• 29 October: TeamUpdraft wrote that "a plugin installed by the attacker was left in place and later used to create a new administrator account, after the site had already been disconnected from UpdraftCentral."

Why sites that never used UpdraftCentral are on the list

The UpdraftCentral client ships inside every copy of UpdraftPlus, free and premium. It stays dormant until the site holds a key. According to Patchstack, the screen for connecting a TeamUpdraft.com account carried a checkbox, ticked by default, that added the site to UpdraftCentral at the same time. Plenty of people connected an account for UpdraftVault or a licence and enrolled the site in remote management without noticing. Patchstack also found keys issued in November 2025 that still worked in October 2026.

The backdoor itself is built to slip past the usual checks. Patchstack describes it creating an account that shows the Editor role, then quietly granting it manage_options and install_plugins. Scan your administrator list and you will miss it. Login happens by setting a cookie directly, so two-factor authentication and login-limit plugins never run. And the account stays after the plugin is removed.

There is an older problem in the same channel. In June 2026 the vendor fixed CVE-2026-10795, a flaw that let attackers forge UpdraftCentral commands without any key, in versions 1.26.5 and 2.26.5. Patchstack says exploitation attempts for it are still arriving, so a site below those versions has both problems at once.

Step 1: find out which sites hold a key

Run these from the WordPress root of each site. The --skip-plugins --skip-themes flags matter: Nethemba points out that some backdoor samples throw a fatal error and would crash WP-CLI if it loaded them.

wp plugin list --fields=name,version,update --skip-plugins --skip-themes
wp option get updraft_central_localkeys --format=json --skip-plugins --skip-themes

If the option exists and holds one or more entries, the site accepts remote commands. Wordfence notes that an empty array means no connection, and that a missing key today does not prove nothing arrived earlier. Do not paste the option value anywhere public, since it contains key material.

Then compare plugin files against wordpress.org:

wp plugin verify-checksums --all --skip-plugins --skip-themes

This only verifies plugins hosted on wordpress.org. Premium and custom plugins are skipped with a warning, and so is any backdoor, because none of them have published checksums. Read that skipped list line by line. Every name on it should be something you installed on purpose.

Step 2: the same check across many Docker-hosted sites

The official wordpress image does not include WP-CLI, but the wordpress:cli variant can join a running site container. Docker's documentation says it needs the site's files, its network and the same WORDPRESS_* environment variables, because the image's wp-config.php reads them directly. It also warns that the CLI image runs as UID 82 while the Debian-based WordPress images use UID 33, so --user 33:33 is usually needed. This loop puts that together for every running WordPress container on a host:

for c in $(docker ps --format '{{.Names}} {{.Image}}' | awk '$2 ~ /wordpress/ && $2 !~ /cli/ {print $1}'); do
  env=$(mktemp)
  docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' "$c" | grep '^WORDPRESS_' > "$env"
  echo "== $c"
  docker run --rm --volumes-from "$c" --network "container:$c" \
    --env-file "$env" --user 33:33 -e HOME=/tmp wordpress:cli \
    sh -c 'wp plugin get updraftplus --field=version --skip-plugins --skip-themes;
           wp option get updraft_central_localkeys --format=json --skip-plugins --skip-themes'
  rm -f "$env"
done

The temporary env file contains your database password, which is why the loop deletes it straight away. If your sites read secrets from *_FILE variables, mount those secret files into the CLI container too. Swap the inner commands for any check in this article to run it fleet-wide.

Step 3: cut the channel, then update

Deleting the key works on any version and stops new commands immediately:

wp option delete updraft_central_localkeys --skip-plugins --skip-themes
wp option delete updraft_migrator_localkeys --skip-plugins --skip-themes

The second line removes Migrator keys, which Nethemba recommends unless you are in the middle of a migration. Removing the site from the UpdraftCentral dashboard is not enough, because the key that matters lives on the site. Backups keep running after the key is gone.

Then update. For the free plugin, wp plugin update updraftplus is enough. Premium updates through its licence-connected updater, which does not load under --skip-plugins, so update it from wp-admin or upload the package from your TeamUpdraft account once the site has passed the checks below. Aim for 1.26.14 or 2.26.14, and never stop at 1.26.12. If your Dockerfile copies plugins into the image instead of keeping wp-content on a volume, change the version there and rebuild, or the next deploy will put the old plugin back.

Step 4: look for what the attacker left behind

Start with files. Some samples hide from the WordPress plugin screen, so TeamUpdraft says to inspect wp-content/plugins/ and wp-content/mu-plugins/ directly. Patchstack's best file-level marker is a description line shared by its samples:

grep -rl "Small maintenance toolkit: keeps option storage tidy\." wp-content/plugins/ wp-content/mu-plugins/

Do not rely on that string alone. Nethemba documents later variants with other descriptions, a single-file version and one named site-health-cache that filters itself out of the plugin list. Their article carries the names, option keys and SHA-256 hashes, plus a read-only checker you run with wp eval-file check-updraftcentral.php --skip-plugins --skip-themes.

Next, accounts. Check by capability, not by role name. Patchstack's query assumes the default wp_ table prefix, and wp db prefix tells you yours:

wp db query "SELECT u.user_login,u.user_email FROM wp_users u
  JOIN wp_usermeta m ON m.user_id=u.ID
  WHERE m.meta_key='wp_capabilities'
    AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"
wp option list --search='*_sync_token' --fields=option_name --skip-plugins --skip-themes

Confirmed usernames so far follow a two-words-plus-two-digits pattern such as data-ops43, with an @example.org address and the display name "Site Tools". Nethemba adds a second variant using @example.com with names like "System Team".

Finally, logs. A hit on the trigger parameter means the backdoor was used, not merely installed. The Apache variants of the official WordPress image send their logs to stdout, so on Docker you can search them with docker logs:

docker logs mysite 2>&1 | grep -E '[?&]_[A-Za-z0-9]{4,10}=[A-Za-z0-9_]{32}([&"[:space:]]|$)'

Patchstack lists 43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9 as source addresses, but the attacker rotated infrastructure within a day. Treat IPs as a search term, not as a block list that keeps you safe.

Step 5: clean up and rotate

If you find a backdoor, the order matters. Delete the UpdraftCentral key first, or the attacker can push a replacement. Then deactivate the plugin and move its folder out of the web root rather than deleting it in wp-admin, because Patchstack found its uninstall routine erases its own traces. Patchstack also warns against fixing the fatal error in the broken samples: that switches the backdoor on. Remove the _sync_token option and the rogue account.

Then rotate, whether or not you found anything on that particular site:

• wp config shuffle-salts to invalidate every login cookie, including the attacker's persistent one.
• New passwords for every administrator and editor.
• Your teamupdraft.com password and two-factor setup, which TeamUpdraft asks of every account holder.
• Remote storage credentials. Wordfence relays TeamUpdraft's advice to re-authorise remote storage and change storage access keys on any site accessed through UpdraftCentral. Nethemba adds that Premium may keep the account password in plain text in the updraftplus-addons_options option.
• UpdraftVault sites need reconnecting under Settings, followed by a test backup.

If the account exists or the trigger shows up in your logs, treat the site as fully compromised. Restore from a backup taken before 17 October, rotate the database password and the secrets in wp-config.php, and only then reconnect anything. We covered why backups need to sit out of an attacker's reach in our SafePay ransomware piece, and why patching alone does not undo a breach in our NetScaler article.

Our take

A remote management key gives its holder the power to install code on your site with nobody approving each command. That deserves the same care as an SSH key: issue it on purpose, give it to an account without install_plugins where you can (Patchstack saw that single detail stop the attack on one analysed site), and delete it when nobody uses it. On most backup-only sites the right number of UpdraftCentral keys is zero. If you are also running WordPress in containers, check the PHP underneath while you are in there; our PHP2Shell guide shows how.

Frequently asked questions

Sources: TeamUpdraft incident notice (updated 29 October 2026), Patchstack, Wordfence PSA, Nethemba analysis (updated 26 October 2026), UpdraftPlus changelog on wordpress.org and Docker official WordPress image docs.