UpdraftCentral Revocation Still Needs a Local Check
Stolen management keys let attackers deploy hostile add-ons; revocation cannot reverse earlier intrusion.
The breach over 17-18 October may have exposed account details, password hashes, two-factor settings and service keys. Plugin downloads and self-hosted UpdraftCentral were unaffected, the vendor says. Premium backup-plugin users should inspect sites even without knowingly using the cloud dashboard.
TeamUpdraft’s 23 October correction sets minimum builds at 1.26.13/2.26.13, revoking keys older than 18 October, 12:07 UTC. Nethemba says keys created later that day, through 21:00 UTC, still require manual deletion. Its review now agrees with the corrected cutoff. The researchers report no deletion in the preceding cleanup; Wordfence instead describes conditions that caused it to be skipped.
The researchers’ 21 October commands against two of their sites were blocked, not proof of successful post-update intrusion. Their samples hid plugins or reused existing privileged accounts. A normal dashboard cannot settle whether the site was accessed.
Wordfence advises retaining logs and suspicious files before cleanup, then inspecting the filesystem and effective user permissions independently. If integrity is uncertain, restore both site and database from a verified backup taken before the intrusion or obtain professional investigation. Reconnect only after checks and cleanup.
Wordfence’s filter blocks legitimate as well as malicious commands, but covers free versions through 1.26.11 and paid editions before 2.26.12. An update can cross that protection boundary while a local key remains.
Replace the vendor password and any reused copy, and reset its two-factor setup. UpdraftVault customers must reconnect storage and test a backup; previous disconnection can leave the next backup missing. Review credentials reachable by a compromised site too.
The researchers found the vendor password stored unencrypted in some site databases.
