The UpdraftCentral key breach has exposed a risk that routine WordPress plugin updates cannot address on their own: an attacker using credentials a website already trusts. Researchers recorded malicious plugins being remotely installed on 18–19 October 2026. TeamUpdraft confirmed unauthorised access to its customer website and warned users of its cloud remote-management service to disconnect affected sites.

There is now an important update for site owners. On 19 October, UpdraftPlus released version 1.26.13 after an initial emergency release did not correctly apply key revocation. The distinction matters when choosing which version to install and what to check afterwards.

UpdraftCentral key breach: what is confirmed?

On 19 October, security company Nethemba described suspicious UpdraftCentral commands reaching three of its own WordPress websites. Two accepted commands that installed unknown plugins; the third rejected an installation because the connected user lacked the necessary permissions. Nethemba found that the requests were signed using valid remote-management keys, even though its plugins had been updated against an earlier June vulnerability.

Patchstack independently reported malicious plugin installations in its telemetry between 18 October at 15:32 and 19 October at 09:23, identifying 99 different plugin names. These are observed installations, not a reliable count of every compromised website.

TeamUpdraft said it detected unauthorised access to teamupdraft.com over 17–18 October and believed its customer database had been accessed. That database included UpdraftCentral connection keys alongside customer records and credentials for other services. The precise route by which an attacker acquired and used individual keys remains subject to investigation.

Which WordPress sites are exposed?

The relevant condition is an active cloud UpdraftCentral connection key, not simply having UpdraftPlus installed. UpdraftCentral can manage plugins and other functions across multiple sites. Its client is included in both the free and paid backup plugin, but sites without a cloud connection key do not accept this class of signed management command.

A site may have a key without its owner remembering an explicit UpdraftCentral setup: Patchstack observed that connecting a TeamUpdraft account could select remote-management enrolment by default. TeamUpdraft says free users without a teamupdraft.com account need not take action for this particular incident. It also says self-hosted UpdraftCentral was not affected.

What the UpdraftPlus security update changes

TeamUpdraft prepared an emergency update to disconnect cloud keys created before the incident cut-off. The official WordPress.org changelog lists UpdraftPlus Free 1.26.12 on 19 October as the first revocation release, followed by 1.26.13 the same day to properly apply that revocation. The corresponding Premium branch uses a 2.x version number.

For a site on the free branch, check that 1.26.13 or later is installed. For Premium, install the corresponding latest vendor release. The changelog correction is a reason not to stop at 1.26.12. Crucially, a successful update cannot undo a malicious plugin installation or remove an attacker account that already exists.

Why trusted UpdraftCentral commands were dangerous

Nethemba found that the attacker used the ordinary remote command channel to submit a plugin installation request. The site accepted the signature because the command was made with a trusted key. No WordPress administrator needed to approve each command manually.

Patchstack’s analysis found a backdoor designed to create a user whose displayed role was Editor while separately granting powerful capabilities. Some observed samples caused HTTP 500 errors because of mistakes in the malicious code. An unfamiliar plugin causing a site failure should therefore be investigated, not ‘fixed’ by altering its code to make it run.

This is different from an ordinary plugin programming flaw. June’s CVE-2026-10795 involved a separate authentication bypass already fixed in older UpdraftPlus releases. The October case centres on the misuse of legitimate keys.

How to check and secure a connected site

1. Inspect connections directly

Sign in through each site’s own WordPress dashboard. Open Settings → UpdraftPlus → Advanced Tools → UpdraftCentral and look for existing keys. Administrators using WP-CLI can inspect the presence of the updraft_central_localkeys option without sharing its contents. Never paste key material into a public ticket or chat.

2. Revoke old keys and update

Delete every old UpdraftCentral cloud connection key locally, then install the latest UpdraftPlus security release directly on the site. Removing the site from a remote dashboard alone is not an adequate substitute for checking local keys. Ordinary backups to other storage destinations can continue without UpdraftCentral remote management.

3. Look for unauthorised changes

Review plugins, Must-Use plugins, users and recent UpdraftCentral events. Investigate entries such as Command received: plugin.upload_plugin, unexpected plugins installed on 18–19 October, or error messages naming plugins nobody authorised. Researchers found examples using the description Small maintenance toolkit: keeps option storage tidy. Names and descriptions can change, so their absence proves little. Check user capabilities, not only the displayed administrator role.

4. Treat evidence of a backdoor as an incident

If malicious activity is found, preserve evidence where practical and isolate the access path. Consider restoring files and the database from a verified clean backup predating the incident, or engage a qualified incident responder for full cleanup. Replace compromised WordPress, hosting, database and API credentials from a trusted device; review sessions and two-factor authentication. A backup restore does not itself rotate exposed secrets.

The wider lesson resembles the distinction in our Backuply restore-security analysis: recovery must establish what changed, not merely get the website working again.

Limitations and trade-offs

Disconnecting UpdraftCentral sacrifices cloud-based remote administration until a safe reconnection is agreed, but it does not require uninstalling the backup plugin. TeamUpdraft’s 19 October notice recommends reconnecting with a new key after checks and cleanup; Nethemba and Patchstack advised caution about reconnecting while the cause and scope of the key exposure remained uncertain. Their differing advice should be evaluated against subsequent vendor updates and each site’s operational needs.

The breach also affects related services differently. TeamUpdraft says it disconnected UpdraftVault accounts and replaced UpdraftClone client keys. Those services have separate reconnection steps. Its notice does not claim that standard plugin downloads or backups stored with third-party providers were modified.

Critical analysis

The central failure here is a broken trust relationship, not necessarily outdated WordPress code. An otherwise current site could accept an attacker-signed command because the key was trusted. A prompt update, local key revocation and a retrospective compromise review therefore solve different parts of the problem.

The revised 1.26.13 release shows why incident instructions must be tied to a date and the latest vendor evidence. Early reports accurately described a period with no plugin fix; the WordPress.org changelog now documents revocation code and a follow-up correction. Neither makes it reasonable to declare previously connected sites clean without investigation.

For agencies managing many websites, the practical priority is a site-by-site inventory of cloud connections, evidence of unwanted changes and completion of recovery actions. That is more useful than treating all four million UpdraftPlus installations as compromised or assuming that a green update indicator settles the incident.

Sources


Leave a Reply

Your email address will not be published. Required fields are marked *