UpdraftCentral Key Exposure Puts Connected WordPress Sites at Risk

Revoking the key is only the first step

Revoking an exposed UpdraftCentral key can close the remote access route, but it won’t reverse changes attackers made while that key still worked. A stolen key can give an intruder a way into a connected WordPress site; commands already run there may leave behind plugins, accounts or sessions that persist after access is cut off.

That distinction matters for administrators responding to this incident. They need to check each connected site for malicious plugins, rogue accounts and active sessions, rather than treating a software update or credential reset as proof that a site is clean. The key can be disabled remotely. The aftermath has to be checked on the site itself.

How the exposure happened

The incident followed unauthorized access to TeamUpdraft’s website. The company makes the UpdraftPlus backup plugin and related site management services, and said its customer database was likely accessed. Potentially exposed data included names, email and billing addresses, order histories, password hashes, two-factor authentication settings and service connection keys.

That list spans both personal information and credentials that could affect account security. A connection key has a different role from a password, but both can matter when administrators are working out what access an attacker may have had. TeamUpdraft said it doesn’t store payment card details; Stripe and PayPal handle card payments. That limits the payment information held directly by the company, while leaving the other potentially exposed account data relevant to a careful response.

Remote management made the keys consequential

UpdraftCentral lets administrators manage multiple WordPress sites remotely. That convenience also means a connection key can serve as a path to a site without the attacker having to break in through that site’s usual login screen. According to security firm Patchstack, attackers used exposed keys to run commands on sites linked through the service.

Patchstack observed attacks beginning October 18. The firm said attackers used malicious plugins to maintain access and create administrator accounts, turning an initial route into a foothold that could outlast the key itself. This is more significant than it looks: remote access can make routine site management faster, but the cleanup burden spreads across every site that trusted the connection.

Backdoors can outlast the stolen key

Patchstack identified at least 99 variants of malicious plugins, some disguised as maintenance or optimisation tools. Researchers said certain variants can create privileged accounts or impersonate existing administrators, while others hide from WordPress’s standard administrator screens. A plugin that looks ordinary, or that doesn’t appear in the usual list, therefore can’t be dismissed without further inspection.

Web application security firm Nethemba said attackers targeted three of its WordPress sites through UpdraftCentral and installed malicious plugins on two. That’s a practical example of why administrators need to inspect each connected site directly: disabling a key won’t remove installed backdoors, unauthorized accounts or sessions already in progress. (And this is the part most people overlook.)

A key can be revoked. A planted account can remain.

Updates close the access route

TeamUpdraft said it closed the route attackers used and released UpdraftPlus versions 1.26.13 for free users and 2.26.13 for Premium users. The updates revoke older UpdraftCentral Cloud connections. Installing the relevant update addresses the old connection path, but administrators still need to determine whether attackers used it before it was shut down.

The company said the UpdraftPlus plugin and its downloads weren’t compromised. It also said backups held in customers’ own remote storage, including Google Drive, Dropbox and Amazon S3, weren’t affected. That’s useful reassurance about those assets, though a backup’s presence alone doesn’t establish that the live site hasn’t been altered.

Still, TeamUpdraft advised customers whose sites were accessed through UpdraftCentral to re-authorise remote storage and change storage access keys as a precaution. The company also signed out customer accounts, reset login security, replaced UpdraftVault and UpdraftClone credentials, and added monitoring. It reported the incident to the UK Information Commissioner’s Office and other relevant authorities.

Exposure depends on the connection

UpdraftPlus had surpassed four million active WordPress installations in October. That figure gives a sense of the plugin’s reach, but it doesn’t establish how many sites were exposed to this attack. The reported attack required an active UpdraftCentral connection key, so exposure depends on whether a site was linked through that service.

If you’re working in this space, the practical question is whether any site you manage had that connection active and whether it was accessed. A large installation base can make an incident worth tracking, but the connection requirement is what administrators need to use when setting their own response priorities.

Inspect sites and rotate credentials

Administrators should update UpdraftPlus, remove any remaining UpdraftCentral connection keys, review administrator accounts and installed plugins, change administrator passwords, and check logs for suspicious activity. TeamUpdraft also recommends changing account passwords and resetting two-factor authentication where applicable. These steps address different parts of the exposure, so completing one doesn’t make the others unnecessary.

If a site shows signs of compromise, administrators may need to restore a verified backup made before October 17, then rotate credentials and check the site’s integrity. The date gives a reference point for choosing a backup, but the restore needs to be verified and followed by checks for persistent access. Otherwise, an account or plugin left behind could undermine the recovery.

That said, the core lesson is straightforward: treat key revocation as the start of cleanup. Verify every connected site for changes made while remote access was available, and treat the update as one part of that work. What this means for you is that the condition of each site—not just the status of the key—should guide the response.