UpdraftCentral: Stolen Keys Signed Real Commands, and WordPress Sites Obeyed. A Valid Signature Is Not Consent.
If your WordPress sites use UpdraftPlus and you ever connected them to the UpdraftCentral cloud dashboard, act today. Over the weekend of October 17 to 18, an intruder got into teamupdraft.com and, the company says, likely reached its customer database, which held the keys that let the dashboard send commands to connected sites. From the afternoon of October 18, those stolen keys were used to tell sites to install a backdoor plugin, and the sites did. No bug in the plugin was needed. The commands were signed with real keys, so they looked exactly like the site owner's own. Update UpdraftPlus to 1.26.13 or 2.26.13, delete your UpdraftCentral connection keys, and check for the backdoor described below.
What happened
UpdraftCentral is a cloud dashboard for managing many WordPress sites at once. Each connected site holds a key, and the dashboard holds the matching one, so it can sign commands such as "install this plugin" that the site will accept. TeamUpdraft says unauthorised access to teamupdraft.com was found over the weekend of October 17 to 18 and that its customer database was likely exposed, including names, emails, billing addresses, hashed passwords, two-factor settings, and the connection keys for UpdraftCentral, UpdraftVault and UpdraftClone.
According to Patchstack's analysis, the attacker used those keys to send the "upload plugin" command to connected sites between 15:32 on October 18 and 09:23 on October 19. The plugin it installed creates a hidden account that shows as an Editor but holds administrator powers, plus a login bypass, triggered by a secret link, that skips the login form and two-factor authentication. Estimates of reach vary: one widely cited figure puts the exposed population at around 400,000 sites with keys, while one incident-response firm reported more than 100 confirmed compromises early in the week. TeamUpdraft has not said how many sites received the plugin.
Protect, today
1. Update, then delete the keys. UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium) disconnect UpdraftCentral connections made before 22:00 BST on October 18. Some researchers report that keys created later that day may survive the update, so delete the keys yourself on every site: in wp-admin go to Settings, UpdraftPlus Backups, Advanced Tools, UpdraftCentral. Do this even if you think you never used UpdraftCentral. Do not reconnect until you have checked the site.
2. Look for the backdoor. Patchstack reports the plugin's description reads "Small maintenance toolkit: keeps option storage tidy." Its name varies, with around a hundred random two- and three-word names seen, but "Site Health Cache" recurs. Look for a user with the display name "Site Tools" and an example.org email address, shown as an Editor but holding administrator capabilities. Check the must-use plugins folder too, because plugins there do not appear in the normal list. In your web server logs, the trigger is a URL parameter that starts with an underscore and carries a 32-character token.
3. If you find it, rebuild. Delete the connection key first, or the attacker can push a replacement. Do not uninstall the plugin from wp-admin, because Patchstack reports its uninstall routine erases its traces; move it out of the web root instead. If the hidden account exists or the trigger appears in your logs, treat the site as fully compromised: restore from a backup taken before October 17, review every user with extra powers, rotate administrator and UpdraftCentral passwords, and end all sessions.
4. If you had a teamupdraft.com account, change that password, and anywhere you reused it, and reset two-factor authentication.
What we added to our feed, and what we left out
Patchstack published two addresses the attacker used, and warned they are a starting point, not a control, because the attacker rotated infrastructure within a day. We added one, 43.250.53[.]42, which sits at a hosting provider, to our feed under the source manual-batch-updraftcentral-2026-10, credited to Patchstack. It is their observation, not ours. We deliberately left the other one out. It belongs to Cloudflare's network and looks like shared VPN exit traffic, so blocking it would block everyone else using the same exit. An IP blocklist is not the main defense here anyway. The keys are.
Why this one matters beyond WordPress
All day we have been writing about one idea: a consequential action should carry a named approval of that exact change, from someone who could have said no. UpdraftCentral is the clearest case of what happens without it. Every command was validly signed. The site checked the signature and obeyed. But a signature only proves which key was used, not that its owner agreed. A dashboard key that can install plugins on hundreds of thousands of sites, with no human approving each install, is a standing "the robot may act for me." Stolen, it becomes the attacker's.
Patchstack's own advice points the same way: if you need remote management, create the key under an account that cannot install plugins. Narrow what a key can do, and make the dangerous actions need a person. That is the cheapest protection there is, and it could have turned this attack into a list of failed install attempts.
Our write-up of the approval model we now run on our own deploys: Everyone Says Prepare. Here Is How to Protect, Today.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=updraftcentral-stolen-keys-signed-real-commands-and-wordpress-sites-obeyed-a-valid-signature-is-n
Comments