Attackers Holding UpdraftCentral Keys Are Installing Backdoor Plugins on WordPress Sites, and No UpdraftPlus Update Stops It

An attacker holding valid UpdraftCentral dashboard keys has been installing backdoor plugins on WordPress sites since at least Sunday, October 18, according to two security firms, and no UpdraftPlus update stops it. Nethemba found backdoors on two of its three sites overnight and published a teardown on Monday, October 19. Patchstack, which sells real-time WordPress vulnerability mitigation, says its telemetry recorded installations “across a broad set of sites” between 15:32 on October 18 and 09:23 on October 19, under 99 different plugin names. The plugin itself is not broken: the commands arrive correctly encrypted and signed with genuine dashboard private keys, so every check on the site passes, and the remedy both firms give is to delete the UpdraftCentral keys on each site.

UpdraftPlus has over 4 million active installations on WordPress.org and carries the UpdraftCentral client in every copy, but only a site that holds an UpdraftCentral key accepts these commands. How the keys reached the attacker is not known. Both firms say the evidence points to TeamUpdraft’s UpdraftCentral Cloud service, where the dashboard private keys are kept, and neither has shown how; Nethemba says it had no reply from the vendor when it published. This is a developing story, and the details here are as of 10:20 UTC on October 19, when we last re-read both reports and TeamUpdraft’s blog, which carried no notice about it.

If you run UpdraftPlus, check for a key first: wp option get updraft_central_localkeys prints something if the site holds one. Delete every key, do not reconnect until TeamUpdraft explains what happened, and look for the signs in the table further down. We read the UpdraftPlus 1.26.11 source and ran the firms’ search commands against sample data; what we could not test is listed at the end.

What the two firms found

Nethemba’s three sites ran WordPress 7.1.3 and UpdraftPlus 2.26.11, which is patched against the June flaw, and all three were connected to UpdraftCentral Cloud. Its first warning was an automatic WordPress email: “WordPress caught an error with one of your plugins, Load Stack 35C,” a plugin nobody had installed. Every file in the plugin’s folder carried the same timestamp, and the access log held a single POST to the site root in that second from 43.250.53[.]42 with the user agent “WordPress/6.4; class-udrpc.php”. UpdraftCentral’s own log recorded “Command received: plugin.upload_plugin”. Before each install the attacker had sent a probe addressed to a key name that does not exist, probe.central.updraftplus.com; the site’s answer shows that it accepts UpdraftCentral commands, and the next command went to a real key.

Nethemba publishes its times in CEST. The table converts them to UTC by subtracting two hours, which matches the UTC times in its own script output. Patchstack’s two times are shown as printed, and its post names no time zone.

The third site escaped by chance. Its key had been created in November 2025 by a user who is no longer an administrator, and UpdraftCentral checks that the key’s owner can install and activate plugins before it accepts an upload. Patchstack credits Nethemba with the discovery, says its own findings match and extend the observed scope, and adds three things from its telemetry: two source addresses active at the same time, the repeated plugin name “Site Health Cache”, and a description shared by every sample, “Small maintenance toolkit: keeps option storage tidy.” It also says some installations never activated, which it reads as consistent with the key owner lacking the capability to activate plugins. Patchstack says it currently blocks UpdraftCentral remote commands for protected sites, and that affected dashboards show those sites as unreachable while scheduled backups continue.

Registry records put the IPv4 address in a range assigned to RedSwitches (AS50049) and the IPv6 address, 2a09:bac5:4e21:2e3c::49b:9, in a Cloudflare block named CLOUDFLAREWARP (AS13335). A registry entry shows who runs a range, not who the customer is, and Patchstack notes that the attacker rotated infrastructure within a single day, “so IP blocking is not a control here.”

Why no update fixes it

UpdraftCentral is TeamUpdraft’s remote-management dashboard. Its client code ships inside every copy of UpdraftPlus, free and premium, and stays dormant until the site gets a key. When a site connects, it generates an RSA key pair and stores the dashboard’s public key; from then on it executes any command signed with the dashboard’s private key, with the permissions of the user who created the connection, and nobody confirms individual commands. The dashboard’s private keys never touch the connected sites. They live with the UpdraftCentral Cloud service, so every connected site rests on the assumption that they stay there.

Nethemba ruled out the other explanations on its sites. The four UpdraftCentral files it compared match the official 1.26.11 release byte for byte, the key fingerprints were unchanged across daily backups from October 15 to 18, both keys are 2048-bit RSA, no unauthorized administrator or plugin upload appeared in the logs, and the June flaw did not apply because the sites were patched. The requests also did not come from TeamUpdraft: the real dashboard identifies itself as “WordPress/6.8.5; class-udrpc.php/2.0; https://teamupdraft.com”, while the attacker’s user agent had neither a library version nor a URL. Nethemba concludes that the keys leaked from the UpdraftCentral Cloud environment and were used outside it. Patchstack says the evidence points the same way, and that TeamUpdraft had published no explanation when its post went live.

The result, in Patchstack’s words: “This is not a vulnerability in UpdraftPlus, and as of 19 October no plugin update stops it.” Its summary card lists the CVE as “None” and adds that “this is a key compromise, not a code flaw.” Our inference, not the firms’: a scanner that looks for CVE IDs or vulnerable plugin versions has nothing to match here and would likely report these sites clean.

What the UpdraftPlus 1.26.11 source shows

WordPress.org lists 1.26.11, released October 16, as the current version, and its changelog has no entry about UpdraftCentral keys since 1.26.5 on June 5. We downloaded it and read the relevant code. We did not run an attack and have no WordPress install here, so these are readings of the code, not exploit tests.

• No key, no listener. central/bootstrap.php starts the UpdraftCentral listener only when the updraft_central_localkeys option holds at least one key, which matches Nethemba’s statement that sites without a key are not at risk from this attack.
• The enrollment box is pre-checked. On the TeamUpdraft.com account screen, admin.php renders a checkbox labeled “Add this website to UpdraftCentral (remote, centralised control)”, followed by the words “free for up to 5 sites”, hard-coded as checked and shown only while the site has no key. The script that handles the login says, in its own comment, “create a key if the checkbox was checked,” and sets the consent flag itself. That confirms Patchstack’s account of how a site can end up with a key nobody chose.
• Plugin uploads need two capabilities. central/commands.php refuses a plugin upload unless the user it runs as can both install_plugins and activate_plugins, the check that stopped the attempt on Nethemba’s third site. In the free 1.26.11 code that check comes before anything is installed, so it does not by itself explain Patchstack’s installations that never activated; the premium build may differ.
• Messages arrive in one POST field. The bundled RPC library reads the incoming message from a POST field named udrpc_message and handles it on the wp_loaded hook, which is what Nethemba’s optional block, shown below, relies on.
• The log keeps 50 events. The client stores the last 50 UpdraftCentral events, each with a time, the message, the caller’s IP address and its user agent, so on a busy site the record of an attack can scroll out.

What the backdoor does

Both firms describe the same behavior. Nethemba’s samples pose as ordinary add-ons, with a complete header, a GPL license and an invented publisher, and each plugin waits for a secret URL parameter carrying a 32-character token. Given the token, it creates an account with a hard-coded password, gives it the Editor role plus the manage_options and install_plugins capabilities, sets a login cookie directly and redirects to the admin area. Two details make it effective. The account shows as an Editor, so a review of the administrator list misses it, yet install_plugins allows arbitrary code execution and manage_options allows promotion to full administrator. And because login happens by setting a cookie, two-factor authentication, login attempt limits and login protection plugins never run. The account also outlives the plugin, whose uninstall routine erases the plugin’s own traces.

The samples analyzed so far contain a coding error that makes the plugin throw a fatal error on uncached requests, which is how Nethemba found it. Both firms warn against repairing such a plugin. Nethemba: “Fixing it would switch the backdoor on. Remove it.” It adds that its two samples come from one generator that produces different names, tokens and passwords for every site, which it reads as a tool built for a large number of sites.

Who is exposed

The client sits in every install, but the key is what exposes a site. TeamUpdraft’s June 5 notice about the earlier flaw, which per the 1.26.5 changelog affected sites with a Migrator or UpdraftCentral key, said it “affects only a small percentage of users (we estimate less than 10%).” On roughly 4 million installs that caps the sites holding either kind of key at about 400,000 (our arithmetic; Nethemba makes the same estimate), and this campaign needs an UpdraftCentral key specifically. The cap may not tell you much about your own site, because enrollment can happen without anyone choosing it. Patchstack says it sees sites with active keys “whose owners only ever used UpdraftPlus for backups,” and keys do not expire: Nethemba’s keys from November 2025 still worked in October 2026, and a search of the plugin’s central/ and bundled RPC folders for expir found nothing that ages a key out.

Nethemba says it does not yet know whether self-hosted UpdraftCentral dashboards are affected as well as the TeamUpdraft-run cloud service.

What to do now

1. Check for a key. Run wp option get updraft_central_localkeys, or open Settings, UpdraftPlus Backups, the Advanced Tools tab and UpdraftCentral, and look at “Manage existing keys.” Patchstack says to run the check even if you have never used UpdraftCentral.
2. Delete every key. Use the Delete button next to each key, or wp option delete updraft_central_localkeys. Removing the site from the dashboard is not enough, because the key that matters lives on the site; backups keep working. Patchstack adds that deleting the keys stays the right move even after a vendor fix ships, because the attacker already holds keys issued before it.
3. Do not reconnect until TeamUpdraft explains the cause; both firms say so. If you need remote management, both suggest creating the key under an account without install_plugins, which is what stopped the attack on Nethemba’s third site.
4. Look for signs of a compromise using the table below. If the site already answers with HTTP 500, add --skip-plugins --skip-themes to WP-CLI commands: Nethemba says an installed copy crashes WP-CLI otherwise, and the WP-CLI documentation describes the flag as skipping plugin loading.
5. If you find the backdoor, delete the key first, or the attacker can push a corrected replacement. Deactivate the plugin and move it out of the web root rather than deleting it in wp-admin, because the plugin’s uninstall routine erases the evidence, and remove the _sync_token option and the account. If the account exists or the trigger parameter appears in your access logs, both firms say to treat the site as fully compromised: restore from a backup taken before the attack, compare files against a clean install, review every user with extra capabilities, rotate administrator and UpdraftCentral Cloud passwords, end all sessions and enable two-factor authentication.

The commands below come from the two reports. We ran the three grep commands exactly as printed, changing only the paths, against a synthetic access log and a dummy plugin folder built from the examples in the reports. Each matched only the attacker-style line or file, and not the real dashboard’s user agent or ordinary query strings such as utm_source and _ga. We did not run the WP-CLI commands.

# Is the site connected? (Patchstack, Nethemba)
wp option get updraft_central_localkeys

# Delete every key (Patchstack, Nethemba)
wp option delete updraft_central_localkeys

# Find the backdoor plugin by its description (Patchstack)
grep -rl "Small maintenance toolkit: keeps option storage tidy\." /var/www/*/wp-content/plugins/

# Find requests with the attacker's user agent (Nethemba; adjust the log path)
grep 'class-udrpc.php"' /var/log/apache2/*access*

# Find the backdoor's activation trigger (Patchstack)
grep -E '[?&]_[A-Za-z0-9]{4,10}=[A-Za-z0-9_]{32}([&"[:space:]]|$)' access.log

Nethemba also offers an optional block that makes a site refuse every UpdraftCentral command, saved as a file in wp-content/mu-plugins/. Nethemba warns that the block stops site migration through UpdraftPlus Migrator too, because that uses the same channel, and says to delete the file once the vendor has resolved the problem. We have not run it, because we have no PHP here.

<?php
// Nethemba: block all UpdraftCentral (UDRPC) commands until the vendor resolves the October 2026 incident.
if ( isset( $_POST['udrpc_message'] ) ) {
	http_response_code( 403 );
	exit;
}

What is still unknown

TeamUpdraft has not, in anything we could find, said how the keys reached the attacker, and a leak from its cloud service is the firms’ inference from what the attacker used and where it came from, not a confirmed breach. Nethemba notes one detail without drawing a conclusion: two of its keys had existed since November 2025 and went unused until October 19, and the attack came eight days after it added site A to the same account. Neither firm gives a count of affected sites. Patchstack counts 99 plugin names, most of which appeared once, while Nethemba saw three sites. Nethemba warns that the attacker needs to fix only a few characters for the next wave to work, and says it published at once because a vendor fix would not help site owners while the attacker holds valid keys: “Publishing does not help the attacker, who needs valid keys and already has them.”

This is the second incident in the UpdraftCentral channel since June. CVE-2026-10795, fixed in UpdraftPlus 1.26.5 and 2.26.5 on June 5, let an attacker forge UpdraftCentral commands without any key. NVD’s record carries CWE-347 (improper verification of a cryptographic signature) and a CVSS 3.1 score of 8.1, both supplied by Wordfence. TeamUpdraft said at the time that it had “no evidence of anyone attempting to exploit the vulnerability so far.” Nethemba says it still sees exploitation attempts against that flaw in the logs of two of its sites, from dozens of addresses, and that all of them fail on patched sites with “Could not decrypt incoming message.” Patchstack adds that sites below the fixed versions face both problems at once. CISA’s Known Exploited Vulnerabilities catalog (version 2026.10.16) has no UpdraftPlus entries.

How this compares with two recent incidents

Two days earlier we covered Rank Math PRO 3.0.123, where some downloads carried malware and the version number could not show whether a site was affected, and ConnectWise’s Cloud Backup credential, which attackers used to sign in to customers’ Microsoft 365 tenants as the backup app. The UpdraftCentral case resembles the second: a credential held by a backup vendor opens many customers’ systems, and each customer’s own defenses see a valid request. It differs in one respect that matters to site owners, which is that there is no fixed version to move to, so the only defense is removing the key.

Sources and method. We read Nethemba’s report and Patchstack’s post in full and re-read both just before publishing; TeamUpdraft’s June 5 notice and company news page; the WordPress.org plugin API (version, install count and changelog); the UpdraftPlus 1.26.11 package from downloads.wordpress.org; NVD’s record for CVE-2026-10795; CISA’s Known Exploited Vulnerabilities feed; the WP-CLI configuration documentation; and ARIN, APNIC and RIPEstat records for the two addresses. The counts of sites and plugin names are the firms’ own telemetry, and the firms are not independent of each other, since Nethemba notified Patchstack and Patchstack’s findings build on its report. We did not test an attack, the WP-CLI commands, Patchstack’s database query, Nethemba’s checking script or the mu-plugin, because we have no WordPress or PHP here.