UpdraftCentral breach reached customer WordPress sites; the affected-site count remains unknown

The revocation did not undo changes already made to a site

TeamUpdraft says its 19 October security release revoked old UpdraftCentral connection keys. Two days later, its updated incident notice confirmed that an attacker had already used customer-site connections to create administrator accounts and install malicious plugins. The vendor has not published a count of affected websites. A revoked key closes a route for further commands; it does not, by itself, remove a user or plugin that was already added to a site. Nethemba's code review also disputes how completely the release removed exposed keys.

The distinction matters because UpdraftPlus is widely installed, while only sites connected to the cloud UpdraftCentral remote-management service had the particular command channel described here. Neither the total installation figure nor the number of exposed keys is a count of compromised sites. TeamUpdraft also says the backup plugin and its downloads were not altered. This was a compromise of a service and its trusted connections, according to the evidence available so far.

What happened, and which dates remain missing

Event dates from TeamUpdraft's incident notice and Patchstack's own telemetry, read 21 October 2026. Vendor and researcher observations have different scopes.

Stage	What the record says	What it does not say
Initial access	TeamUpdraft identified unauthorised access over 17 to 18 October and now says a compromised key was used to access its site.	The exact first entry time, owner of that key and full entry route.
Customer-site commands	Patchstack observed backdoor installations from 18 October 15:32 to 19 October 09:23 in its telemetry; TeamUpdraft confirms malicious plugins and user creation on some connected sites.	A global start or end time, a complete victim count, or what happened on every site.
Containment	TeamUpdraft says it closed its own access route and released free 1.26.13 and Premium 2.26.13 just after 22:00 BST on 19 October. Nethemba's code review says those releases removed only site keys created before 12:07 UTC on 18 October.	That every site updated, that later keys were deleted, or that earlier site changes were reversed.
Notice and investigation	The public vendor notice was posted 19 October and updated at 11:05 BST on 21 October. TeamUpdraft says it has reported the incident to the ICO and police and engaged an outside security firm.	Customer notification completion, incident closure, or a final forensic report.

The Nethemba team reported the problem after observing malicious plugins on its own connected sites. Patchstack's research separately describes backdoor installations in its telemetry. Patchstack's 19 October page still contains an old status line saying no vendor update existed; that statement predates TeamUpdraft's later release. Nethemba subsequently inspected the release code and found a key-deletion cutoff earlier than TeamUpdraft's stated 21:00 UTC boundary. The vendor's current notice does not address that code-review finding.

Why a validly signed command can still be hostile

UpdraftCentral Cloud holds a dashboard private key and the connected WordPress site stores the corresponding public key. The site verifies a remote command's signature with that public key. A valid signature proves possession of the dashboard private key, not that the legitimate site operator issued the command. Nethemba reports that commands on its sites were signed with valid cloud dashboard keys. Separately, TeamUpdraft says an attacker used a compromised key to access its own website, but has not established that this was the same key or explained how the dashboard keys were obtained.

Nethemba found the remote-management channel behind the plugin upload on its sites; Patchstack independently documented installations and backdoor behaviour. TeamUpdraft now confirms an attacker used customer connections to install plugins and create users. This does not establish that every site with the plugin, or every UpdraftCentral-connected site, received a malicious command. It also does not establish that the code in every planted plugin worked as intended.

This is distinct from CVE-2026-10795, an earlier UpdraftCentral command-forgery vulnerability fixed in June. The present incident concerns valid keys used without the owners' authority, according to the current reporting. The familiar labels 'signed', 'encrypted' and 'updated' describe checks and software state; none alone proves that the person behind a command was authorised or that a previously changed site is clean.

The affected population has three different layers

Scope distinctions drawn from the TeamUpdraft notice, the plugin listing and the researchers' observations. These are categories, not interchangeable totals.

Population	Established	Not established
UpdraftPlus installations	The backup plugin is broadly deployed; its remote-management client can be present even where cloud remote management is not in use.	That all installations had a usable UpdraftCentral key or were attacked.
Cloud-connected sites	A site with an active connection key could accept a signed command from whoever held the matching dashboard key.	How many such sites existed during the incident.
Sites changed by an attacker	TeamUpdraft confirms plugin installation and account creation; Nethemba and Patchstack report firsthand or telemetry-backed cases.	The final number of distinct sites, people, records or successful persistence events.

TeamUpdraft says its customer database was believed to have been accessed. It lists names, email and billing addresses, order history, hashed passwords, two-factor settings and service connection keys among the fields it held. It says it did not store payment-card details, and that self-hosted UpdraftCentral was not affected. These statements describe the vendor's current assessment. The notice does not quantify the records actually copied, establish downstream data theft from customer websites, or say whether stolen site credentials were later used.

What a site owner should do, in order

The vendor's current advice says a user whose site was reached through UpdraftCentral should also consider changing remote-storage authorisation and access keys. Removing a malicious plugin alone may be insufficient if it created a second account or another persistent change. Conversely, a site with no evidence of a cloud connection should not be described as compromised merely because UpdraftPlus is installed.

The questions the incident notice still needs to answer

TeamUpdraft says a compromised key was used to access its website, but has not identified the owner of that key or explained how the attacker obtained it. Its update has not fixed a first-access timestamp, a complete access window, a count of affected cloud customers, a count of customer sites changed, or a confirmed list of data retrieved from either the vendor or those sites. Its statement that there is no evidence of continuing access to TeamUpdraft's own site is narrower than proof that all customer sites are clean.

TeamUpdraft suggests the speed and initial defects of some planted plugins could indicate AI-assisted attack development. That is the vendor's interpretation, not a demonstrated attribution of the tooling used. The practical question is simpler: after revocation, which connected sites have been checked for changes made before the keys stopped working?