Summary: On October 18–19, 2026, an attacker used stolen UpdraftCentral dashboard keys to push backdoor plugins to WordPress sites around the world. A small number of sites we manage had UpdraftCentral keys. We reviewed every one of them. The attacker’s attempts against our sites were blocked by our firewalls before they reached WordPress, and we found no indicators of compromise on any site. All UpdraftCentral keys have been removed.
What happened
UpdraftPlus, a widely used WordPress backup plugin, includes a remote-management client called UpdraftCentral. When a site is connected to an UpdraftCentral dashboard, the dashboard holds a private key that lets it send signed commands to the site, including installing plugins.
Beginning around 15:30 UTC on October 18, an attacker began sending correctly signed “install plugin” commands to sites using keys that appear to have been taken from the vendor’s hosted UpdraftCentral Cloud service. Because the commands were validly signed, the plugin treated them as legitimate. The installed plugin was a backdoor that could create a hidden administrator-equivalent account and log the attacker in without a password. This was not a bug in the plugin code; it was a credential compromise, so there is no patch that fixes it on its own. The campaign ran for roughly 18 hours before security vendors deployed blocking rules and the vendor published a statement.
Sources
- Patchstack: UpdraftCentral key compromise used to install WordPress backdoors
- Nethemba: technical analysis of the UpdraftCentral backdoor
- TeamUpdraft: security incident statement, October 2026
What we did
As soon as the advisory was published on October 19, we identified every site we manage that runs UpdraftPlus and checked each one for an active UpdraftCentral key. For the sites that had keys, we:
- Deleted all UpdraftCentral keys from the sites themselves, which is the only step that actually revokes the attacker’s access. Removing a site from the dashboard is not enough.
- Preserved the UpdraftCentral logs from each site before making changes.
- Reviewed firewall and edge logs for the published attacker indicators. The attacker did probe several of our sites, one request each. Every attempt was stopped before it reached WordPress: by our web application firewall’s IP reputation blocking, by Cloudflare’s bot protection, or by HTTP authentication on non-production environments.
- Audited each site directly on the server for the published indicators of compromise: the backdoor plugin, its hidden account, the database options it creates, and any file or user changes during the attack window. We found none on any site.
- Confirmed that no site had ever received a plugin-install command through UpdraftCentral.
No client action is required. No sites were compromised, and no data was exposed.
What we are doing going forward
- Staying disconnected from UpdraftCentral. We will not reconnect any site to UpdraftCentral until the vendor fully explains how the keys were exposed and what has changed. Scheduled backups are unaffected; they do not depend on UpdraftCentral.
- Blocking the remote-command path at the edge. We are adding firewall rules that reject UpdraftCentral remote commands outright, so a leaked key alone can never reach a site again.
- Tightening plugin-install permissions. Our existing lockdown prevents people from installing plugins through the WordPress admin, but it did not cover automated remote-management channels that act on an administrator’s behalf. We are extending it so that plugin installation is denied at the permission level for every path except our own management tooling.
If you have questions about your site, contact your Workhorse account manager or reply to this notice.