TLDR: When UpdraftCentral was breached in October, we blocked the attack across WordPress.com the same day, then tracked down and cleaned up hundreds of affected sites. Most of their owners never noticed anything was wrong, and nobody paid a thing.
What happened
On October 19, 2026, the team behind UpdraftPlus, a popular backup plugin for WordPress, disclosed a security incident. Attackers got into UpdraftCentral, the service that lets people manage many UpdraftPlus sites from one dashboard.
With access to the data stored there, the attackers could send commands to any site linked to UpdraftCentral. They used that access to quietly install hidden plugins and create secret admin accounts. Patchstack has a detailed write-up of how the attack worked, if you’re interested in the technical side.
When you connect a TeamUpdraft account (the account you use to buy and manage UpdraftPlus), adding your site to UpdraftCentral is turned on by default. So a lot of folks who only ever used UpdraftPlus for backups were exposed without knowing it.
How we protected sites
As soon as we saw the first reports, our teams got to work. Just over two hours later, we had a protection live across all of WordPress.com that blocks the attack method outright. Site owners didn’t need to do anything, not even update the plugin.
That stopped new attacks, but it couldn’t undo the ones that had already happened. Some sites were hit before the block went live, so we went looking for them:
- We added new detection rules to our malware scanner to spot the hidden plugins.
- We searched across the platform for sites showing signs of the attack.
- Happiness Engineers (HEs) who specialize in security cleaned up those sites directly, removing the planted plugins and backdoor accounts.
For most customers, the problem was found and fixed before they ever noticed anything was wrong.
The team behind the fix
By the time a few customers wrote in about malware alerts the day after the disclosure, the HEs on our security support team were already working through the list of sites our scanner and search had turned up, including theirs. Rather than handle each ticket as it came in, the HEs started tracking every affected site in one place so none would slip through.
From there, our Escalated Support team cleaned up all of those sites in bulk, sharing progress with each other as they went.
Once all sites were cleaned, we reached out to their owners to explain what we found, what we removed, and next steps. In all, we emailed hundreds of customers (some folks had more than one site affected!).
We didn’t charge anyone for any of this. On WordPress.com, keeping your site safe is part of your plan, and when there’s something we can fix at the platform level, we do.
Keeping your site secure
If you’re on WordPress.com, your site is already protected from this attack, and if it was affected, you’ve heard from us by email. For anyone on any host, these are good habits to keep:
- Use strong, unique passwords for your WordPress.com account and your site login, and ask any other Administrators to do the same. Consider changing the password for the email address tied to those accounts too. Here’s how to change your WordPress.com password.
- Turn on two-step authentication for an extra layer of security on your WordPress.com account.
- Review your Administrators. Check Users > All Users, and remove anyone who shouldn’t be there, or change their role if they don’t need full control of your site.
- Review plugins and themes. Remove the ones you don’t use, and keep the rest updated.
How does your team handle a security incident that starts somewhere else? We’d like to hear what’s worked for you.
Leave a Reply