What happened
TeamUpdraft says it identified unauthorised access over October 17-18, 2026 and updated its incident page on October 20, 2026 at 16:25 BST. The company believes its customer database was accessed; that database contained account data, password hashes, two-factor-authentication settings and connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. It says the UpdraftPlus plugin downloads and self-hosted UpdraftCentral were not affected. TeamUpdraft released UpdraftPlus 1.26.13 and 2.26.13 just after 22:00 BST on October 19, 2026 to revoke UpdraftCentral keys created before 22:00 BST on October 18, 2026.
Imunify360 says campaign requests reached WordPress sites on more than 2,200 servers from the evening of October 18 through October 19, 2026. Imunify360 recorded more than 18,000 campaign-related events between October 18 and October 19, 2026. Researchers found signed remote commands installing plugin backdoors capable of creating privileged users or authenticating as existing administrators. Some variants hide from WordPress’s Plugins or Users screens. Updating closes the exposed remote-management path but leaves previously installed plugins, users, capabilities and sessions in place.
Published indicators include 43.250.53.42, 2a09:bac5:4e21:2e3c::49b:9, the hidden plugin name Site Health Cache, and the description Small maintenance toolkit: keeps option storage tidy. The remote command observed in UpdraftCentral logs is plugin.upload_plugin, and Imunify360 exposes blocked requests under rule 77383256. The WP-CLI command wp option get updraft_central_localkeys checks for keys, and wp option delete updraft_central_localkeys removes them. The cited sources did not publish a single stable file hash for the campaign’s randomised plugin set. Attribution posture: TeamUpdraft and the cited researchers do not identify the attacker.
Why this matters now
This is not principally a plugin-vulnerability decision. Attackers used valid remote-management keys believed exposed through TeamUpdraft’s customer database, so connected sites accepted correctly signed commands. Normal signature validation, MFA on the WordPress login page and an up-to-date plugin did not prevent those commands. The trust relationship between a vendor cloud dashboard and customer sites became the attack path.
Updating revokes older UpdraftCentral Cloud keys but does not remove backdoor plugins, privileged accounts or authenticated sessions created before revocation. Two observed backdoor families hide from ordinary WordPress administration screens, and one can authenticate as an existing administrator. Hosting providers therefore need file-system, database and access-log evidence. A green plugin-version report is not a closure artefact.
The decision for security leaders
Assign web-platform or hosting owners to inspect every site directly, including sites believed to use UpdraftPlus only for backup. Query for UpdraftCentral keys, inspect plugin and must-use-plugin directories, enumerate administrators and editors without loading regular plugins, review access logs for activation triggers and compare plugin installation events with authorised administrator actions. Remove persistence before rotating credentials and reconnecting.
Separate release deployment from compromise closure. A fixed version proves that old cloud keys should no longer be accepted; it does not prove the site was never commanded, that a hidden user was not created or that an attacker lacks an active session. If a clean restoration is required, repeat updating, key removal, password rotation and session invalidation because an older backup can restore the exposed configuration.
Evidence of closure
- Every site reports a current UpdraftPlus release and no residual unauthorised key.
- File-system and database inspection finds no unexplained plugins, users or capabilities.
- All administrator credentials and active sessions have been invalidated after containment.
- Restored sites pass integrity checks and repeat the update and key-removal process.
The Security.io assessment
The material change is confirmation that a vendor-cloud trust mechanism was actively used to deliver backdoors, followed by current key-revocation releases and stable malware detections. This is stronger evidence than a speculative database-exposure scenario. The attack used legitimate signatures, so controls focused solely on exploit payloads or WordPress login MFA were positioned after the decisive trust boundary.
The vendor says the unauthorised access route is closed and the current releases revoke older Cloud keys. That supports containment but not site-level clearance. The most defensible closure combines current versions, absence of residual keys, direct file and database inspection, invalidated sessions and validated restoration evidence. Any command accepted after revocation, or additional exposed key classes, would materially widen the response.
Questions for the morning meeting
- Which WordPress sites have or previously had an UpdraftCentral Cloud connection key?
- Can hosting teams inspect plugin files and user capabilities outside the WordPress interface?
- Who can approve restoration when pre-incident backups reintroduce vulnerable versions and keys?