UpdraftPlus / UpdraftCentral
Remote Management Key Compromise – Backdoor Deployment
An attacker holding valid UpdraftCentral dashboard keys is installing backdoor plugins on connected WordPress sites. The campaign ran continuously through an 18-hour window on 18-19 October. Patchstack blocks UpdraftCentral remote commands and has deployed mitigation rules covering it.
Status, 19 October 2026: the campaign is active and no vendor fix exists. We update this post as that changes – check this line before acting on the rest.
This is not a vulnerability in UpdraftPlus, and as of 19 October no plugin update stops it. The commands are correctly encrypted and signed with genuine dashboard private keys. Every check in the plugin passes, because from the site’s point of view the instruction is legitimate. The latest releases, 1.26.11 and 2.26.11.26, are affected exactly like older ones. The fix is to delete your UpdraftCentral keys.
Nethemba discovered this campaign on their own infrastructure and published the first analysis. Our findings match theirs and extend the observed scope.
| Vendor / Product | TeamUpdraft / UpdraftPlus, UpdraftCentral |
| Type | Remote management key compromise leading to site takeover |
| CVE | None – this is a key compromise, not a code flaw |
| Authentication Required | No – the attacker authenticates with stolen dashboard keys |
| Affected | All UpdraftPlus versions, free and premium, on sites with an active UpdraftCentral key |
| Fixed Version | None as of 19 October 2026 – see the status line above |
| Exploitation Status | Active, ongoing |
| First Observed | 18 October 2026, 15:32 |
✌️ Our users are protected from this vulnerability. Are yours?
Identify vulnerabilities in your plugins and get recommendations for fixes.
Request auditProtect your users, improve server health and earn additional revenue.
Patchstack for hostsHow the UpdraftCentral channel works
UpdraftPlus is the most widely used WordPress backup plugin, with over four million active installations. UpdraftCentral is a separate remote management service from the same vendor, and its client ships inside every copy of UpdraftPlus, free and premium.
The client stays dormant until the site gets a key. Getting one generates an RSA key pair on the site and stores the dashboard’s public key. From then on, the site executes any command signed with the dashboard’s private key, with the permissions of the user who created the connection. Nobody confirms individual commands.
Connecting the site to an UpdraftCentral dashboard is one way to get a key. Connecting a TeamUpdraft.com account is the other, and it happens by default. That screen carries a checkbox reading “Add this website to UpdraftCentral (remote, centralised control) – free for up to 5 sites”, hardcoded as checked="checked" in admin.php. Leave it ticked and a successful login creates an UpdraftCentral key, with the plugin supplying the consent flag itself. The checkbox only renders when the site has no key yet, so one account connection is enough to enrol a site that has never knowingly used UpdraftCentral.
Those dashboard private keys never touch the connected sites. They live with the UpdraftCentral Cloud service. The security of every connected site rests on one assumption: that the keys stay there.
How the attack works
The attacker sends a signed plugin.upload_plugin command over the plugin’s remote procedure call channel, which listens on ordinary POST requests to the site root. WordPress installs and activates the supplied plugin through its standard installer.
Nethemba ruled out every site-side explanation: plugin files byte-identical to the official release, unchanged key fingerprints across days of backups, sound cryptography, no unauthorised administrator or plugin upload in the logs. The requests also did not come from vendor infrastructure – genuine dashboard traffic identifies itself with a library version and URL, while these came from the attacker’s own server. The evidence points to the keys leaking from the UpdraftCentral Cloud environment. TeamUpdraft had not published an explanation when this post went live.
Each delivered plugin is a backdoor. It hooks WordPress early on every request and watches for a secret URL parameter carrying a 32-character token. Given that token, it creates an account with a hardcoded password, assigns the Editor role, then separately grants that account manage_options and install_plugins. It logs the visitor straight in with a persistent cookie and redirects to wp-admin.
Two details make this effective. The account shows as an Editor, so reviewing your administrator list misses it entirely – while install_plugins allows arbitrary code execution and manage_options allows self-promotion to full administrator. And because login happens by setting a cookie directly, it bypasses the login form: two-factor authentication, login attempt limits and login protection plugins never run.
The account also outlives the plugin. It stays in WordPress after the plugin is removed, and the attacker knows its password.
The samples analysed so far carry a coding error that throws a fatal error before the token check runs, so affected sites returned HTTP 500 on every uncached request. That is how the first victims noticed within minutes. Do not repair such a plugin – fixing the error switches the backdoor on. Remove it.
This is the second incident in this channel in five months. In June 2026 the vendor fixed CVE-2026-10795 (CVSS 8.1), where an obsolete unsigned message format let an attacker forge UpdraftCentral commands with no keys at all. That was fixed in 1.26.5 and 2.26.5, but exploitation attempts continue, so sites below those versions face both problems at once.
What we’re seeing
Our telemetry recorded backdoor installations across a broad set of sites between 18 October 15:32 and 19 October 09:23. A minority of installations never activated, which is consistent with the key owner lacking the capability to activate plugins. Those sites still received the backdoor and should be treated as affected.
Two source addresses, active concurrently, with the IPv6 address appearing roughly three hours before the IPv4 one. The attacker rotated infrastructure within a single day, so IP blocking is not a control here.
We observed 99 distinct backdoor plugin names. One name, “Site Health Cache”, is reused repeatedly and is the strongest name-based indicator we have. The rest are randomised two or three word combinations, mostly appearing once each. Detection should key on the plugin description instead – every sample carries the identical line “Small maintenance toolkit: keeps option storage tidy.”
Indicators of compromise
Source addresses – a starting point, not a control:
43.250.53.42
2a09:bac5:4e21:2e3c::49b:9
The plugin description is the most reliable file-level indicator:
grep -rl "Small maintenance toolkit: keeps option storage tidy\." /var/www/*/wp-content/plugins/
The backdoor account is disguised as an Editor. Detect it by capability, not by name:
wp db query "SELECT u.user_login,u.user_email FROM wp_users u
JOIN wp_usermeta m ON m.user_id=u.ID
WHERE m.meta_key='wp_capabilities'
AND m.meta_value LIKE '%editor%' AND m.meta_value LIKE '%manage_options%'"
Usernames follow the pattern of two words plus two digits. The two confirmed so far are data-ops43 and media-staff96, both from the publicly analysed sites – our telemetry records plugin installations, not account creation, so assume other names exist. Supporting markers: an email address at @example.org, the display name “Site Tools”, and a database option ending in _sync_token.
A hit on the activation trigger means the backdoor was used, not merely installed:
grep -E '[?&]_[A-Za-z0-9]{4,10}=[A-Za-z0-9_]{32}([&"[:space:]]|$)' access.log
Genuine UpdraftCentral traffic always carries a library version and URL, for example WordPress/6.8.5; class-udrpc.php/2.0; https://teamupdraft.com. The attacker’s User-Agent has neither:
grep 'class-udrpc\.php"' /var/log/apache2/*access*
In the UpdraftCentral log itself, look for probe.central.updraftplus.com followed by Command received: plugin.upload_plugin. Also watch for plugin installations with no matching administrator action, and WordPress error emails naming a plugin you do not recognise.
Every backdoor plugin name observed so far. Useful for sweeping the current wave; the next one will use new names:
Asset Forge 2, Asset Kit 938, Asset Suite, Asset4works 329c, Block Dock A96, Block Dock F1B,
Card Board, Compress Guard, Compress3sweep 0ea3, Compress6fix, Content Helper, Content
Helper 2 3b8f, Content3fix 1f2b, Core Craft Fc81, Core Smith, Css Forge, Css Forge 4fd2, Css
Lab, Css8refine, Data Engine Cc0, Data Latch E22, Db Forge Ed19, Db1fix, Defer Lab, Fast
Engine, Fast Engine 7eeb, Fast Sweep, Flex Latch, Form Forge, Form Gantry 724, Grid Desk
394, Image Core B36, Image Forge, Image Shelf 85F, Image Suite 6, Image Works, Js Boost
B64e, Js Clean, Js Craft E1c0, Js Kit 5, Lazy Boost, Lazy Engine, Lazy Fix C141, Lazy
Helper, Lazy Polish, List Press A5F, List Shelf 1De, Lite Studio 6001, Lite3sweep, Load
Boost 63b0, Media Latch 1Af, Menu Stack E82, Menu Suite, Meta Bridge 284, Micro Fix, Micro
Lab, Micro Refine 7d0e, Minify Sweep 5999, Opt Fix 7 1277, Opt9studio, Page Helper, Page Lab
2, Page Smith B672, Page Stack, Post Hub 5Ac, Post Kit 91C, Post Suite, Quick Pack, Quick
Studio 8e52, Render Engine, Script Gantry Fd9, Script Shelf 3Fb, Seo Engine, Seo Helper, Seo
Manager, Seo Smith 8320, Site Health Cache, Site Studio 6, Site Suite C5F, Smart Helper,
Speed Kit, Speed Tune, Speed4helper 55c8, Src Guard, Src Helper, Src Studio F8e2, Src Works
7 5ca7, Static Lab, Static Master, Static Tune 7e64, Static1works 16ab, Static7refine, Style
Desk, Tiny Manager 8b6e, Tiny Sweep 5, Tiny7kit 9116, Tiny9helper 1f09, Wp Boost 5585, Wp
Forge
What to do
Check whether you are connected. Any output means the site is exposed:
wp option get updraft_central_localkeys
Run this check even if you have never used UpdraftCentral. Because of the default-ticked checkbox on the TeamUpdraft.com account screen, plenty of sites hold a key that nobody deliberately created – we see sites with active keys whose owners only ever used UpdraftPlus for backups. Keys also do not expire: keys issued in November 2025 still worked in October 2026.
Then delete the keys. In wp-admin: Settings → UpdraftPlus Backups → Advanced Tools → UpdraftCentral → “Manage existing keys (N)…” → delete every key. Or:
wp option delete updraft_central_localkeys
Removing the site from the UpdraftCentral dashboard is not enough – the key that matters lives on the site. Backups keep working after deletion; only remote management stops. Deleting the keys remains the right move even once a vendor fix ships, because the attacker already holds keys issued before it. Do not reconnect until the vendor explains the cause. If you need remote management, create the key under an account without install_plugins – on one publicly analysed site, that single detail stopped the attack.
If you find the backdoor, delete the UpdraftCentral key first, or the attacker pushes a corrected replacement. Deactivate the plugin and move it out of the web root rather than deleting it through wp-admin, because its uninstall routine erases its own traces. Remove the _sync_token option and the backdoor account.
If the account exists, or the trigger parameter appears in your access logs, treat the site as fully compromised: restore from a pre-attack backup, compare files against a clean installation, review every user holding extra capabilities, rotate administrator and UpdraftCentral Cloud passwords, end all sessions and enable two-factor authentication.
Patchstack customers are covered by mitigation rules across three paths: the forged-command path of CVE-2026-10795 on sites still on 1.26.4 / 2.26.4 or earlier, the UpdraftCentral command channel itself, and the backdoor’s activation trigger and service accounts. Patchstack currently blocks UpdraftCentral remote commands – affected dashboards show sites as unreachable, while scheduled backups continue.
Credits
Credit for this one goes to Nethemba. They caught the attack on their own sites, took it apart, published a detailed technical breakdown with indicators of compromise and a read-only checking script, and reported it to TeamUpdraft – all within hours, while the campaign was still running. Their write-up is the primary source for the backdoor analysis above and is worth reading in full.
Reference: Critical security problem in UpdraftCentral: an attacker holding the service’s keys planted a backdoor on our websites – Nethemba, 19 October 2026.
Timeline
🤝 You can help us make the Internet a safer place
Streamline your disclosure process to fix vulnerabilities faster and comply with CRA.
Get started for freeProtect your users too! Improve server health and earn added revenue with proactive security.
Patchstack for hostsReport vulnerabilities to our gamified bug bounty program to earn monthly cash rewards.
Learn more


