Last updated: 23 October 2026. We update this page when the UpdraftPlus developer or the researchers change their guidance.
Attackers holding stolen UpdraftCentral connection keys have installed backdoor plugins on WordPress sites. The developer of UpdraftPlus and UpdraftCentral says someone gained unauthorised access to its own website over the weekend of 17 to 18 October 2026. It believes its customer database was accessed, and that database holds the connection keys. The full dated record is on our UpdraftCentral key compromise incident page.
What Did the Developer Say Happened?
In its security incident notice, the developer says the customer database may have exposed names, emails, billing addresses and order history. It also lists hashed passwords, two-factor settings and connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. It says it stores no card details, and that backups in your own remote storage were not affected.
On 21 October the developer added that the attacker used a compromised key to get into its site. It says it has no evidence the attacker still has access. It hired an external security firm and contacted the police. It also said the attacker used the keys to create admin accounts and install malicious plugins on customer sites.
How Does the Attack Work?
Patchstack describes a key compromise, not a flaw in the plugin code. The UpdraftCentral client ships inside every copy of UpdraftPlus and stays dormant until a site gets a key. With a valid key, the attacker sends a signed plugin.upload_plugin command to the site, and WordPress installs and activates the plugin.
Patchstack says keys do not expire, and that a key issued in November 2025 still worked in October 2026. It also says a checkbox that adds the site to UpdraftCentral is hardcoded as checked when you connect the site to an account on the developer’s website. That is why some owners hold a key they never knowingly created. The pattern fits a supply chain attack, because the weak point sat at a supplier, not on the victim sites.
Nethemba, a security firm that found the campaign, says the attacker sent the command to three of its own sites on 19 October. It ran on two of them. The third failed because the key belonged to a user without plugin install rights. Nethemba says its sites ran a version already patched against the June flaw CVE-2026-10795.
What Does the Backdoor Do?
Patchstack says the plugin watches every request for a secret parameter that carries a 32-character token. When it sees the token, it creates an account with the Editor role, grants it extra capabilities, and logs the visitor in by setting a cookie. That skips the login form, two-factor authentication and login protection plugins. The account stays after the plugin is removed.
Both researchers say the first samples contained a coding error that crashed the site with HTTP 500 errors. That is how Nethemba noticed: its site had returned error 500 since 04:14 CEST on 19 October. Patchstack warns against fixing the error, because a repaired plugin would activate the backdoor. Remove it instead. Nethemba describes three variants. A hidden version of the minimal one, a plugin named “Site Health Cache”, removes itself from the plugin list.
Which Versions Fix It? Sources Differ
The developer says UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium), published just after 10pm BST on 19 October, disconnect every UpdraftCentral connection made before 13:07 BST on 18 October. That is 12:07 UTC. WordPress.org pushed the release to all users, the developer says.
Patchstack’s article of 19 October says the latest releases at that time were affected like older ones and that no vendor fix existed yet. Nethemba says 1.26.12 and 2.26.12 deleted no keys because of a bug, so it tells owners to run 1.26.13 or 2.26.13 or later. Nethemba also says keys created on 18 October between 12:07 and 21:00 UTC are not removed by the update and must be deleted by hand. Check the key list on each site, whatever your version.
Patchstack gives the campaign window as about 18 hours on 18 and 19 October. Nethemba reports the activity went on. On 20 October it saw attempts to trigger removed backdoors on at least six sites. On 21 October the original attacker address, 43.250.53.42, sent commands to two of its sites after the fixed release, and its own blocking rule stopped them.
How Do You Check a Site?
The developer’s steps for each site: log in to the WordPress dashboard directly, update UpdraftPlus to 1.26.13, 2.26.13 or later, then delete the connection key under Settings, UpdraftPlus, Advanced Tools, UpdraftCentral. Next, check Users for administrator accounts you do not know, and check Plugins, including the Must-Use tab, for anything unfamiliar. Change all administrator passwords. If you find anything, the developer suggests restoring from a backup taken before 17 October.
Patchstack adds that you should check for a stored key even on sites where you never used UpdraftCentral, and that removing a site from the UpdraftCentral dashboard is not enough. Delete the key on the site itself. Its example commands:
- Check for keys:
wp option get updraft_central_localkeys - Find plugins by description:
grep -rl "Small maintenance toolkit: keeps option storage tidy\." /var/www/*/wp-content/plugins/
Patchstack publishes these indicators. It calls the IP addresses a starting point, not a control, and says the next wave will use new plugin names:
- Plugin description: “Small maintenance toolkit: keeps option storage tidy.”
- Plugin name: “Site Health Cache” is reused most often. Patchstack saw 99 distinct names in total.
- Account markers: an @example.org email address, the display name “Site Tools”, and a database option that ends in
_sync_token. - Attacker IP addresses seen by Patchstack:
43.250.53.42and2a09:bac5:4e21:2e3c::49b:9.
If the account exists or the trigger parameter shows up in your access logs, Patchstack says to treat the site as fully compromised. Restore a clean backup, rotate passwords, end sessions and turn on two-factor authentication. Stolen or reused passwords are a related risk, which our guide to leaked credentials covers.
What Did Our GitHub, X and Dark Web Checks Show?
We ran three checks on 23 October. GitHub: three repositories exist for the separate June flaw CVE-2026-10795, the first created on 11 June 2026. According to their authors, one is a proof of concept and one is a Docker lab. The third points to an external download script and asks for donations. We did not run or link any of them.
X: our search since 17 October found about 133 unique posts, the earliest on 19 October. Most are English, and the busiest days were 21 and 22 October. Two posts show the range.
“delete the key now” – @nethemba, 19 October. The researchers warned owners the day they found the campaign.
“including some never knowingly connected” – @therepositorywp, 20 October. The WordPress newsletter The Repository summarised who is affected.
The posts our filters flagged as exploit, proof-of-concept or scanning talk were round-ups of the week’s incidents, summaries of the vendor and researcher pages, and an audit prompt for defenders.
Dark web: our THANOS search since 17 October returned 39 results across three search terms, with many repeats. Most came from Telegram channels that repost security news. Two were posts on a Russian-language forum retelling the news, and one came from a Discord news channel.
What Is Still Unknown?
No source gives a count of compromised sites. Nethemba says it does not know how many sites the attacker hit, and the developer says the extent is unknown. Nethemba estimates up to about 400,000 sites could be affected. It starts from the vendor’s estimate, given for the June flaw, that fewer than 10% of users hold an UpdraftCentral or Migrator key. It applies that share to more than 4 million active installs. That is a ceiling on exposure and not a count of victims.
The developer says the attacker got in with a compromised key, but has not said how that key was obtained or what the underlying weakness was. On 21 October it said the speed of the attacks and the faulty first backdoors suggest the attackers used AI to speed up their work. That is the vendor’s inference, and the researchers do not confirm it. No government or security company we read has named the attacker.
Next Steps for Your Team
List every WordPress site you run and every site you manage for clients. Check each one for the key option and for unknown administrators and plugins. Then ask which other suppliers hold keys that can change your sites, and who can revoke them. Our glossary entry on third-party risk explains how to track that. For another WordPress incident, see our analysis of the WP2Shell WordPress remote code execution chain.