UpdraftCentral Stolen Keys: How WordPress Sites Were Backdoored

On 17 and 18 October 2026, an attacker reached teamupdraft.com and, TeamUpdraft says, probably took UpdraftCentral connection keys from its customer database. Those keys were used to install backdoor plugins on connected WordPress sites. If a site uses UpdraftPlus, update to 1.26.13 or 2.26.13 or later, delete its UpdraftCentral keys, and check admins, plugins and files.

No exploit was needed. The attacker held keys the sites already trusted, so each command looked genuine. Most remote management, backup and agency tools for WordPress work the same way, which makes this worth studying even if you never used UpdraftCentral. If you are also dealing with the PHP runtime flaws from the same week, see our separate post on PHP2Shell for WordPress site owners.

What happened

TeamUpdraft makes UpdraftPlus, one of the most widely installed WordPress backup plugins, and UpdraftCentral, a dashboard for managing many WordPress sites from one place. It comes as a cloud service run by TeamUpdraft or as a self-hosted version.

TeamUpdraft says it identified unauthorised access to teamupdraft.com over the weekend of 17 to 18 October. Its incident post, by Joe Whittaker, says the customer database was accessed, including names, email and billing addresses, order history, hashed account passwords, two factor settings, and connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. TeamUpdraft says it does not store card details.

Patchstack reports the first backdoor install at 15:32 on 18 October, with installs running for about 18 hours. Nethemba, a Slovak security firm, found unknown plugins on its own sites early on 19 October and published the first technical analysis, which Patchstack credits as its primary source.

Timeline

Times are as each source gave them. Patchstack did not state a time zone for its install times.

What is not affected

TeamUpdraft says the UpdraftPlus plugin and its downloads, backups in your own remote storage (Google Drive, Dropbox, Amazon S3 and so on) and self-hosted UpdraftCentral were not affected. One caveat: if a site was accessed through UpdraftCentral, re-authorise its remote storage and change storage access keys.

What sources disagree on

• Which version fixes it. TeamUpdraft's update notes cite 1.26.13 (free) and 2.26.13 (Premium), while its step by step section cites 1.26.12 and 2.26.12 as a minimum. Nethemba says the .12 releases did not delete any keys. Use 1.26.13 or 2.26.13 or later.
• The revocation cutoff. TeamUpdraft says the update disconnects connections made before 22:00 BST on 18 October. Nethemba says the cutoff in the code does not match that, and advises deleting by hand any keys created between 12:07 and 21:00 UTC on 18 October.
• Whether the attack has stopped. TeamUpdraft said on 21 October that there is no evidence the attacker still has access to its systems. Nethemba reported attacker commands on 21 October against sites that had not yet updated or deleted keys. Both can be true: stolen keys keep working wherever they have not been revoked.
• How to describe it. Patchstack stresses that this is a key compromise rather than a code flaw in UpdraftPlus, and no CVE has been assigned. Nethemba calls it a critical problem in the UpdraftCentral service.
• Scale. No source we read gives a count of affected sites. Patchstack reports 99 distinct backdoor plugin names.

How a remote management key became a backdoor path

Remote management means each site accepts instructions from elsewhere without a person approving each one. UpdraftCentral does this with key pairs. In plain terms, based on the Patchstack and Nethemba write-ups:

1. Every UpdraftPlus install carries the remote client. It ships in free and Premium copies and sits idle until the site is given a key.
2. Keys get created more often than owners realise. Connecting a site to a dashboard creates one. So can signing in to a TeamUpdraft account inside UpdraftPlus, where a checkbox to add the site to UpdraftCentral is ticked by default, leaving many sites with keys their owners never meant to create.
3. The site trusts whoever holds the dashboard's private key. For UpdraftCentral Cloud, those private keys were held by TeamUpdraft's service, not on the sites. A command signed with the right key passes every check on the site.
4. Commands run with the rights of the user who made the connection. Usually that is an administrator, and commands are not confirmed one by one.
5. Keys do not expire. Patchstack says keys issued in November 2025 still worked in October 2026. IT-Connect's key dated from January 2020.

Put those together and a single database theft becomes a delivery channel. The attacker sent each site a correctly signed instruction to upload a plugin, and WordPress installed and activated it through its normal installer. Being fully patched did not help: IT-Connect had updated UpdraftPlus about an hour before the backdoor arrived.

What the backdoor did

The researchers describe plugins that, once triggered, created a hidden account that looks like an Editor but holds administrator powers, and logged that account in directly. That skips the login form, two factor prompts and login protection plugins. The account survives removal of the plugin. Nethemba later found variants that create a full administrator or hide from the plugin list.

Many first victims noticed only because some samples crashed the site with an HTTP 500. Patchstack warns that "fixing" such a plugin switches the backdoor on. Some sites received the plugin but never had it activated; Patchstack says to treat those as affected too.

TeamUpdraft says it suspects the attacker used AI, given the speed of the attack.

Why this is a supply chain problem

Your WordPress supply chain includes every service that can change your site without you logging in: remote dashboards, backup and migration tools, hosting panels. Each holds a key your site trusts, and each key is only as safe as the place it is stored. Our post on third party risk after the IDCF Cloud ransomware attack makes the same case for infrastructure providers.

Who is affected

On 21 October TeamUpdraft also asked Premium users to check for unusual activity even if they never used UpdraftCentral.

The June flaw is a separate issue

CVE-2026-10795 is an older code flaw in the same remote channel that let commands be forged without keys on sites with UpdraftCentral or Migrator keys set up. Patchstack lists it at CVSS 8.1; it was fixed in 1.26.5 and 2.26.5 in June, and Patchstack says exploitation attempts continue against older versions. The current release covers it.

What to do now: check and rotate each site

Work site by site. Log in to each WordPress dashboard directly, not through UpdraftCentral, as TeamUpdraft advises. The WP-CLI commands below are read only unless marked otherwise; run them from the site root, and adjust the wp_ table prefix if yours differs.

1. Delete the keys first

Patchstack and the vendor agree on the order: remove the key before you clean anything else, or the attacker can push a fresh plugin while you work.

Check whether a site holds UpdraftCentral keys (a check Patchstack and WP Umbrella both give). Any output means it does:

wp option get updraft_central_localkeys

Delete them in Settings > UpdraftPlus > Advanced Tools > UpdraftCentral, or from the command line (this changes the site):

wp option delete updraft_central_localkeys

Removing the site from the dashboard is not enough; the key on the site must go. Backups keep running. Delete any Migrator keys you do not use too.

2. Update UpdraftPlus

wp plugin get updraftplus --field=version
wp plugin update updraftplus

You want 1.26.13 or later for the free plugin, or 2.26.13 or later for Premium. TeamUpdraft says WordPress.org pushed the free update automatically; confirm it anyway, and check Premium sites by hand.

3. Look for plugins you did not install

wp plugin list --fields=name,status,version
wp plugin list --status=must-use
grep -rl "Small maintenance toolkit" wp-content/plugins wp-content/mu-plugins

Patchstack says every sample it saw carried the same plugin description, "Small maintenance toolkit: keeps option storage tidy." Names varied, so look for anything generic sounding you do not recognise.

If you find one, do not delete it from wp-admin; Patchstack notes its uninstall routine wipes its traces. Deactivate it and move it out of the web root as evidence:

wp plugin deactivate <plugin-folder>
mkdir -p ~/quarantine && mv wp-content/plugins/<plugin-folder> ~/quarantine/

Patchstack also lists a database option ending in _sync_token as a marker:

wp option list --search="*_sync_token" --fields=option_name

4. Check every account, not just the administrator list

The backdoor accounts can look like Editors while holding administrator powers. List all users, newest first, then check the real capabilities of anyone with an Editor role:

wp user list --fields=ID,user_login,user_email,roles,user_registered --orderby=user_registered --order=DESC
wp user list --role=editor --fields=ID,user_login,user_email
wp user meta get <ID> wp_capabilities

An Editor whose capabilities include manage_options or install_plugins deserves a close look. Patchstack advises checking capabilities rather than usernames.

5. Check files against clean copies

wp core verify-checksums
wp plugin verify-checksums --all
find wp-content -name "*.php" -newermt "2026-10-17" -print

verify-checksums only covers WordPress core and plugins from WordPress.org. Premium and custom plugins need a comparison against a fresh download from the vendor.

6. Read the logs

UpdraftPlus keeps an UpdraftCentral log in its settings; look for unexpected "command received" entries and plugin uploads. Nethemba warns the attacker's requests may leave no trace there, so also search your web server access logs for the plugin's remote calls:

grep -i "udrpc" /var/log/nginx/access.log*

Adjust the path for Apache or your host's log location. Patchstack and Nethemba publish detailed indicators; use their pages for those.

7. Rotate

1. teamupdraft.com password and two factor. Type the address in rather than following an email link, and change reused passwords elsewhere.

2. Every administrator password on each site. wp user reset-password <login> sends a reset email.

3. Sessions. End all logged in sessions, including any session a backdoor created:

   wp user list --field=ID | xargs -I{} wp user session destroy {} --all
   

4. Authentication salts. wp config shuffle-salts invalidates every login cookie at once. It changes wp-config.php, so take a copy first.

5. Remote storage credentials. Re-authorise Google Drive, Dropbox or S3 in UpdraftPlus and replace storage access keys if the site may have been reached.

6. UpdraftVault and UpdraftClone. Reconnect Vault with your new password and run a manual backup to prove it works. Send updated Clone keys to anyone you shared them with.

7. The stored TeamUpdraft password. Nethemba advises removing it from UpdraftPlus Premium settings if it is still saved there.

8. If you find a backdoor, treat the site as compromised

If the hidden account exists, or your logs show the backdoor was triggered, Patchstack and Nethemba both say to treat the whole site as compromised. Restore from a backup taken before 17 October, compare files with a clean install, review every user with extra capabilities, rotate everything in step 7, and turn on two factor for every administrator.

9. Reconnect only on your terms

TeamUpdraft's last step is reconnecting to UpdraftCentral; Patchstack advised waiting until the vendor explains the cause. If you reconnect, create the key under a user that cannot install plugins. On one of Nethemba's three sites, that alone made the attack fail.

What would have helped

Practices any site owner or agency can use

• An inventory of trust, not just of plugins. For each site, list every outside service that can change it: remote dashboards, backup services, migration tools, security services, hosting panels. Record each key and when it was created; you cannot revoke a key you do not know about.
• Least privilege connections. Create remote management connections under a dedicated user that can update but not install plugins, where the tool allows it.
• Expiry and rotation. Keys that never expire turn an old leak into a live one. Rotate remote management keys on a schedule and when staff or vendors change.
• Deploy plugins from code. Sites built from version control, for example with Composer, make an unknown plugin folder stand out in git status. WordPress documents the DISALLOW_FILE_MODS constant, which turns off plugin and theme installs and updates from the admin. It also blocks your own dashboard updates, so test it first.
• Alerts on the events that matter. A new administrator, a new plugin, or a changed PHP file in wp-content should reach a person within minutes.
• Backups you have restored. A backup taken before 17 October is only useful if you know it restores.
• A written plan for a vendor breach. Who deletes the keys, in what order, and how you reach every site. Our incident response playbook for a compromised dependency is written for packages, but the order of work carries over.

Where Safeguard fits

Safeguard would not have prevented or detected this incident. It has no view into TeamUpdraft's systems, it does not hold or watch WordPress connection keys, and it does not see admin accounts or plugin installs on a live WordPress site. It does not detect malicious packages, so it would not have flagged the backdoor plugins. Its part is narrower.

Knowing what your sites are built from. If you build sites from a repository or container image, Safeguard can scan it (safeguard scan --dir ., --image <name> or --sbom <file>, with JSON results under ./output), produce an SBOM and match components against vulnerability databases, with reachability analysis to help prioritise. If your sites are built with Composer, plugins pulled that way appear in the lockfile as dependencies. The platform shows which projects contain a given component and version, so "which sites run UpdraftPlus, at which version" becomes a search. Our post on SBOM incident response explains the method.

Gates on what you ship. Policies and gates evaluated in the platform can stop a build that includes a dependency with a known critical vulnerability. They would not stop a correctly signed command sent to a live site.

Approved changes through the CLI. The Safeguard CLI's assistant can edit code and run commands on your machine, asking first in the default flow (/permissions offers Ask, Accept edits, Plan, Auto and Strict). An agency could ask it to write a read only script that runs the WP-CLI checks above across its sites and collects one report, then approve each command as it runs. The desktop and phone apps can send that work to a computer running the CLI and approve each command. In CI, safeguard exec runs the checks.

Zero-Day Discovery and Gold

These answer a different question. This incident was a stolen key, not a vulnerable component, and nothing below would have caught it.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It did not find anything about this incident, and there was no code flaw here to find.
• Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. It is where you would look up a code flaw such as the June UpdraftPlus CVE, if it has a record.
• Gold Registry at registry.safeguard.sh is paid: hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

The habit they support helps here too: know exactly what runs on each site, pull components from a source you trust, and be able to rebuild a clean site fast. For the rest of the month's incidents, see October 2026 security incidents and what would have helped, and for a package-side view of trust in a publisher, our post on the Tensorlake npm compromise.

Common mistakes

• Updating and stopping there. The update revokes older keys. It does not remove a backdoor plugin or a hidden account that is already in place.
• Removing the site from the dashboard instead of deleting the key on the site. The key on the site is what the attacker uses.
• Trusting 1.26.12 or 2.26.12. Nethemba says those releases did not delete keys. Use 1.26.13 or 2.26.13 or later.
• Deleting the backdoor from wp-admin. Its uninstall routine erases traces. Deactivate and move it out of the web root instead.
• Checking only the Administrators list. The accounts can look like Editors. Check capabilities.
• "Fixing" a plugin that crashes the site. Patchstack warns that repairing the broken samples activates the backdoor.
• Assuming you are safe because you never used UpdraftCentral. The default ticked checkbox may have created a key for you.

FAQ

Is this a vulnerability in UpdraftPlus?

Not in the usual sense, and no CVE has been assigned. Patchstack describes it as a key compromise: keys stolen from TeamUpdraft were used to send commands the plugin was designed to accept. Nethemba calls it a critical problem in the UpdraftCentral service. The separate June flaw, CVE-2026-10795, was a code vulnerability and was fixed in 1.26.5 and 2.26.5.

I never used UpdraftCentral. Do I need to do anything?

Check for keys anyway. Signing in to a TeamUpdraft account inside UpdraftPlus could create one through a default ticked checkbox, according to Patchstack and Nethemba. If wp option get updraft_central_localkeys returns nothing and you have no TeamUpdraft account, TeamUpdraft says free users need take no action beyond keeping the plugin updated.

Which UpdraftPlus version should I be on?

1.26.13 or later for the free plugin, 2.26.13 or later for Premium. TeamUpdraft's guidance mentions both 1.26.12 and 1.26.13; Nethemba says only the .13 releases revoke keys.

Does updating remove the backdoor?

No. The update cuts off older keys. Any plugin or account already planted stays until you remove it, which is why the checks in steps 3 to 5 matter.

Were my backups affected?

TeamUpdraft says backups in your own remote storage were not affected. UpdraftVault users were disconnected and need to reconnect. If a site was accessed, re-authorise its remote storage and change storage access keys, and pick a restore point from before 17 October.

Is the attack over?

TeamUpdraft said on 21 October there is no evidence the attacker still has access to its systems. Nethemba reported commands on 21 October against sites that had not updated or deleted keys. Treat any site with an old key as exposed until you have deleted it.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident or a WordPress site. Each is a real Safeguard session; the text says how the same flow applies here.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. Here, you would open the same session where you keep your WP-CLI aliases and ask for a read only script that checks every site for UpdraftCentral keys, unknown plugins and Editors with administrator capabilities. It asks before each command.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. On a Composer based site repository, the same flow could raise the free UpdraftPlus plugin to 1.26.13 in the lockfile, with each edit approved first.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. This attack ran overnight in Europe; whoever is on call could approve the key checks from a phone and deny anything that deletes or restores without a second look.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• TeamUpdraft: security incident, what customers need to know
• Patchstack: stolen UpdraftCentral keys are backdooring WordPress sites
• Nethemba: UpdraftCentral backdoor analysis
• IT-Connect: UpdraftPlus backdoor found on IT-Connect via UpdraftCentral
• WP Umbrella: UpdraftPlus backdoor attack, what happened and how to protect your sites
• Reclaim Hosting: UpdraftCentral (UpdraftPlus) compromise

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.