Revoking WordPress access does not remove a backdoor

Revoking a stolen key can stop an attacker from using that key again.

It cannot remove a plugin, account or other change already left on the website.

That distinction became urgent for WordPress businesses using UpdraftCentral Cloud. TeamUpdraft’s incident page, updated on October 29, says it has seen a small number of sites that were compromised during the original incident, showed no obvious sign at the time, then later had an attacker-installed plugin create a new administrator account after the site had been disconnected from UpdraftCentral.

The vendor now asks anyone whose site has ever been connected to UpdraftCentral Cloud to complete its security checks on every such site, even where nothing looks unusual. The guidance applies to both free and Premium UpdraftPlus users.

This is a specific incident, not evidence that every UpdraftPlus installation is compromised. TeamUpdraft says the UpdraftPlus plugin and its downloads were not affected, its customer database may have been accessed, self-hosted UpdraftCentral is outside the incident, and backups sent to a customer’s own remote storage were not affected. The affected path involved cloud connection keys that could issue commands to connected websites.

For a business, the practical lesson is broader than one product: a successful patch or credential revocation closes an access route, but incident response must also determine whether anything was installed or changed before that route closed.

What happened

Over the weekend of October 17 and 18, TeamUpdraft identified unauthorised access to its website. The company says it believes its customer database was accessed. That database included account information and connection keys for UpdraftCentral, UpdraftVault and UpdraftClone.

UpdraftCentral Cloud lets a central dashboard send management commands to connected WordPress sites. Patchstack’s technical analysis says those commands can include installing plugins, and that the attacker used valid UpdraftCentral keys to send signed commands to sites. This was a compromise of cloud credentials, not a newly discovered defect in the UpdraftPlus plugin code.

TeamUpdraft released UpdraftPlus 1.26.13 and 2.26.13 to revoke older UpdraftCentral connections. That was an important containment step. It stopped the compromised keys from continuing to reach sites through the same route.

But a remote command can change the site itself. An attacker can leave a plugin, user account or other persistence mechanism behind. Disconnecting the remote service does not reverse those changes. The October 29 update is significant because it reports that some planted plugins remained and later created administrator accounts after the remote connection was gone.

That is why “the plugin is updated” and “the site is clean” are different statements. The first describes a software version. The second requires checking the site’s files, users, settings and activity.

Who should check

Businesses should check every WordPress site that has ever been connected to UpdraftCentral Cloud, including sites that are no longer listed in the dashboard, sites that were disconnected earlier, and sites where staff do not remember enabling the connection.

TeamUpdraft says its security review applies to sites using both the free and Premium versions of UpdraftPlus. Patchstack’s analysis notes that the connection could be created when linking a TeamUpdraft account, so a site owner may have had an active key without recognising that they had enrolled the site in remote management.

If your team uses an agency or maintenance provider, ask them to identify the complete site list. Include old campaign sites, staging sites that contain production data, and sites no longer managed day to day. A missing site in the current dashboard is not proof that it was never connected.

The incident does not mean every installation of UpdraftPlus needs the same response. TeamUpdraft says self-hosted UpdraftCentral is not affected by this incident. It also says free UpdraftPlus users without a TeamUpdraft account do not need incident-specific action. Confirm the actual connection model with the person who manages the site rather than inferring exposure from the presence of the backup plugin alone.

What businesses should do now

1. Build the affected site list

Ask the business owner, hosting provider and website agency for the WordPress sites that have ever been connected to UpdraftCentral Cloud. Keep the site URL, hosting account, person responsible, last known connection status and review status in one record.

Do not limit the review to the current UpdraftCentral dashboard. Include sites disconnected before the latest warning and any site for which connection history is uncertain.

2. Confirm the access route is closed

On each site, confirm UpdraftPlus is on version 1.26.13 for free or 2.26.13 for Premium, or a later version. Then check the site itself for existing UpdraftCentral keys and remove any that remain, following TeamUpdraft’s current instructions.

Updating the plugin or removing the key is containment. Record it as such, and continue to check whether the earlier access was used to change the site.

3. Inspect beyond the obvious administrator list

Review administrator and editor accounts, including account creation dates and permissions. Look for accounts the business cannot explain, and for accounts with permissions that do not fit their displayed role. TeamUpdraft warns that some malicious plugins can hide unauthorised accounts from the normal Users screen, so a technical reviewer may need to query accounts independently of the dashboard.

Check installed plugins, including must-use plugins and plugin directories through the hosting file manager, SFTP or SSH. TeamUpdraft warns that some malicious plugins may hide from the standard Plugins screen. Do not delete a suspicious plugin through the dashboard: the vendor says some identified plugins can remove evidence when deleted that way. Preserve relevant logs and a copy of suspicious files, then have a qualified reviewer deactivate and remove a confirmed malicious plugin from the server. Its published names are examples, not a complete detection list. A clean dashboard view does not establish that every file is expected.

Review the UpdraftCentral activity log and relevant web server logs for plugin upload commands or other unexplained activity during the incident period. Compare plugin files and user changes with a known-good backup or deployment record where possible. Preserve relevant logs and a copy of suspicious files before cleanup if a compromise is suspected, so the business and its technical support can understand what happened.

Patchstack’s technical investigation describes attacker-installed plugins that could disguise a privileged user as an Editor. That is why checking only for unexpected administrators may miss relevant evidence. Use the vendor’s latest guidance and qualified technical support to interpret suspicious accounts, files or log entries. Do not treat a single clean indicator check as proof that a site is unaffected.

4. Reset credentials after removing persistence

If the site shows suspicious changes, first close the known remote access path and preserve evidence. Then remove confirmed malicious components, invalidate active WordPress sessions by rotating the site’s security keys, and reset administrator and editor passwords. If UpdraftCentral was used to reach the site, re-authorise remote storage and rotate storage credentials as a precaution, as TeamUpdraft advises.

The order matters. Changing passwords while an attacker-controlled plugin remains active may not prevent that plugin from creating another account or restoring access. Where a business cannot confidently identify the changes, ask its host or a qualified incident responder to help before making destructive cleanup changes.

5. Restore when the evidence supports it

If malicious files, unauthorised accounts or unexplained commands are confirmed, compare the site with a known-good backup from before October 17. TeamUpdraft recommends considering a restore from a pre-incident backup when suspicious activity is found.

A restore is not a substitute for containment. Close the remote key path, rotate relevant credentials, and verify the restored site before reconnecting management tools. Confirm that the backup itself is clean, that customer records or orders created since the backup are preserved, and that the restored site’s forms, checkout, bookings and integrations work.

If there is no evidence of compromise, a blanket restore may create unnecessary disruption. Record what was checked, what evidence was available and why the business concluded that a restore was or was not appropriate.

6. Reconnect only after the review

Do not reconnect a site just to make the dashboard look complete. First confirm the site has been reviewed, required keys and credentials have been rotated, and any suspicious changes have been addressed. If remote management is restored, ensure the account and its permissions are appropriate for the work it needs to perform.

Where technical judgement is required

The first judgement is scope. A business may have several environments and suppliers, while the incident affects sites with a particular cloud connection. Establishing which sites had that connection is more useful than assuming every site is affected or checking only the most visible website.

The second judgement is whether a finding is malicious. An unfamiliar plugin or account can be legitimate, especially on an older site with incomplete records. Names alone are weak evidence, and the absence of known names is not a clean bill of health. Compare files, capabilities, timestamps, logs and deployment history, then ask the people who own the site to account for changes.

The third judgement is whether to clean in place or restore. A small, well-understood change may be removable after evidence is preserved. A hidden plugin, privilege escalation or unexplained access may justify restoring a known-good copy and reviewing the exposure period. The right response depends on the site’s data, business role, logging quality and recovery point.

The fourth judgement is whether the backup and recovery path are dependable. This incident did not affect customer-owned remote backups according to TeamUpdraft, but a business still needs to verify that its particular backup exists, can be restored and predates any suspected compromise. A backup that has never been tested is not enough evidence for a recovery decision.

This is part of Website Growth & Care: maintaining a live website includes knowing who can manage it, what changed and how the business can recover. The broader case for treating security as ongoing website operations is covered in WordPress security needs an operating rhythm. When the site inventory, plugin history or hosting responsibility is unclear, a focused Website Audit can establish the facts and prioritise the work.

For a business coordinating a host, agency and internal team, a Fractional Technical Partner can help set the response sequence, assign ownership and decide when deeper incident support is warranted. If the site’s current management setup is no longer supportable, Website Development can address that longer-term constraint after the immediate review.

The practical standard

UpdraftCentral’s compromised keys were revoked. TeamUpdraft’s October 29 update shows why revocation alone did not settle the question for every connected site: a previously installed plugin could remain and create new access later.

For any business that used UpdraftCentral Cloud, the responsible response is to identify every site that was ever connected, confirm the old access is closed, inspect the site itself, preserve evidence when something looks wrong, and document the recovery decision.

The same principle applies to any remote management tool. Closing the door stops future entry through that door. It does not prove that nobody came in before it was closed. The response also follows the distinction in verifying a critical WordPress update: confirm the change on the live site, then test and record the result.