--- title: "Stolen UpdraftCentral keys: is your WordPress site backdoored?" description: "An attacker took UpdraftCentral keys from the company and used them to plant malicious plugins on WordPress sites. Update UpdraftPlus to 1.26.13 or later, delete the key by hand, and check plugins and accounts." url: https://ihsanalapsi.dev/articles/updraftcentral-key-compromise-backdoors lang: en date: 2026-10-21 updated: 2026-10-24 tags: ["App security", "WordPress"] author: Ihsan Alapsi (إحسان العبسي) --- # Stolen UpdraftCentral keys: is your WordPress site backdoored? Between October 18 and 19, 2026, plugins with a backdoor were planted on WordPress sites. A backdoor is hidden code that opens a way for the attacker to get into the site without the password. The site owners did not install these plugins, but the commands that installed them were signed with real keys, so the site ran them like any normal command. This concerns every site that has UpdraftPlus and is connected to UpdraftCentral, even if its owner never used the service once. ## What exactly happened with UpdraftCentral? On October 17 and 18, 2026, the company TeamUpdraft discovered that an attacker had got into its website, and most likely took its customers' UpdraftCentral keys. With these keys the attacker sent signed commands to customer sites, which installed plugins with a backdoor on them. UpdraftCentral is a service from the same company that lets you manage several WordPress sites from one place. The part that receives its commands is inside every copy of UpdraftPlus, free and paid, and it stays dormant until the site gets a key. After that, the site runs any command signed with the private key of the UpdraftCentral dashboard, which is kept by the company and not on your site, with the permissions of the user who made the connection and without anyone confirming the command ([Patchstack, October 19](https://patchstack.com/articles/updraftcentral-key-compromise-wordpress-backdoors/)). Patchstack says the commands are encrypted and signed with real keys, so every check inside the plugin passes, and there is no CVE number for it because the problem is in the key, not in the plugin's code. According to [TeamUpdraft's notice](https://teamupdraft.com/blog/security-incident-october-2026/) (last updated October 21), the company believes the attacker reached its customer database, which contains: - Names, emails, billing addresses and order history. - Account passwords, stored as a hash, not as plain text. - Two-factor authentication settings. - Connection keys for UpdraftCentral, UpdraftVault and UpdraftClone. The company does not store card data, because payments go through Stripe and PayPal. And it says the plugin itself and its download files were not affected, nor the backups on your own storage, nor UpdraftCentral when you host it on your own server. The plugin's page on [WordPress.org](https://wordpress.org/plugins/updraftplus/) shows more than 3 million active installs, and the company itself [wrote 4 million](https://teamupdraft.com/blog/updraftplus-4-million-active-installations/) on October 2. As for how many sites were hit, the company says the extent of the damage is not known yet, and [Nethemba](https://nethemba.com/updraftcentral-backdoor-analysis/), the penetration testing company that discovered the attack on its own sites, wrote that it does not know how many sites the attacker reached. Patchstack recorded 99 different names for the malicious plugin over 18 hours between October 18 and 19. The company wrote on the 21st that the speed of the attack, and the plugins that were broken at first, suggest the attackers used AI to speed up their work. That is its conclusion, and it has not published details that prove it. ## Is my site affected even if I never used UpdraftCentral? It could be. The risk is that your site has an UpdraftCentral key connected to the company's cloud service, and this key may have been created without you noticing when you connected your teamupdraft.com account to the plugin. A site with no key does not accept these commands. The account connection screen inside the plugin has a checkbox "Add this website to UpdraftCentral" that is checked by default, and if you leave it, signing in creates a key on its own. Patchstack found that the box is checked in the plugin's code itself, and Nethemba confirmed it in the code of 2.26.11 and 1.26.13. The sites where this happens most are paid-version sites, because their owner signs in for the license and updates. And the keys have no expiry date: keys from November 2025 still worked in October 2026. | Your situation | What to do | | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | You connected your sites to the cloud UpdraftCentral | Everything in the list below, on every site, today | | You have the paid version, or you connected a teamupdraft.com account to the plugin even once | Check whether there is a key. On October 21 the company asked Premium users to check their sites even if they never used UpdraftCentral | | UpdraftCentral is hosted on your own server | The company says it is not affected | | The free version with no teamupdraft.com account | The company says there is nothing you need to do, and advises keeping the plugin up to date | The fastest way to find out whether there is a key is WP-CLI, a command-line tool for managing WordPress. Run this command in the site folder: ```bash wp option get updraft_central_localkeys --format=json --skip-plugins --skip-themes ``` If you get `Error: Could not get 'updraft_central_localkeys' option. Does it exist?` or `[]`, there is no key. And if you get anything else, meaning a list with entries, the site is connected. The two options `--skip-plugins --skip-themes` let the command run even if a broken malicious plugin is crashing the site. And if your sites are on the same server, you can go through all of them at once (change the path). A `==` line with the path appears for each site, so read what is under it: ```bash for d in /var/www/*/; do echo "== $d"; wp --path="$d" option get updraft_central_localkeys --format=json --skip-plugins --skip-themes; done ``` ## Why is this backdoor dangerous? The backdoor logs the attacker in with a cookie directly, so the login page and two-factor authentication never come into play. And the variants of it that worked either log them in as the first existing admin on the site, with no new account and no trace in the database, or create a full admin. As of October 21, Nethemba documented three variants, from its own sites and from samples other site admins sent it: | Variant | How it logs the attacker in | What it leaves on the site | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | The first | Built to create an Editor account with extra permissions, but every sample analyzed has a bug that crashes the site with a 500 error before it runs | A plugin described as "Small maintenance toolkit: keeps option storage tidy.", and an option whose name ends in `_sync_token` | | The second | Without the `m` parameter it logs them in as the first existing admin, and with `m=setup` it creates a full admin with an email at `@example.com` | A single file with a new name and description each time, an option whose name ends in `_installed`, and `_uid` with it if an account was created | | The third | Logs them in as the first existing admin | A small file and an option whose name ends in `_ver`. And a version of it called "Site Health Cache" hides itself from the plugins list | The first variant was built to wait for a secret parameter in the URL with a 32-character code, and to create an account with a password written inside the code. The account's role is Editor, with two extra permissions on top: `manage_options`, which opens all the settings, and `install_plugins`, which allows installing any plugin, meaning running any code on the server. If it had worked, the account would show as Editor in the users list so a review of the admin list would not catch it, and the attacker would come back with its password even after you removed the plugin ([Nethemba](https://nethemba.com/updraftcentral-backdoor-analysis/)). If you find a strange plugin crashing the site, do not fix its bug: the bug is what is stopping the backdoor, and fixing it turns it on. Remove it with the steps below. And a site that crashed may have been entered by the attacker before it crashed: on two sites belonging to one admin, working backdoors stayed open for more than 3 hours before the broken variant crashed the site. And the attacker is still sending commands. Nethemba saw them on the morning of October 21 sending new commands to two of its sites, after the update came out, and they were stopped there because it had deleted the keys and put in a file that closes the channel. The company wrote on the 20th that the 1.26.13 and 2.26.13 update revoked the connection keys and closed this path, and on the 21st that there is no evidence the attacker still has access to its website. But Nethemba found that 1.26.13 leaves the keys created on October 18 between 12:07 and 21:00 UTC, and sites that have not updated still receive the attacker's commands. ## The checklist for each site On every site with UpdraftPlus, in this order: update, delete the key, look for strange plugins, accounts and options, read the logs, and then change the passwords. Log in to the dashboard of the site itself, not through UpdraftCentral. And if any WP-CLI command below crashes with a PHP error, add `--skip-plugins --skip-themes` to it. ### 1. Update UpdraftPlus to 1.26.13 or later Install 1.26.13 for the free version or 2.26.13 for the paid one, or later. The company's notice still says "1.26.12 or later", but [the changelog](https://wordpress.org/plugins/updraftplus/#developers) says 1.26.13 came out the same day to "Properly apply the revocation in 1.26.12". And Nethemba checked the code of 1.26.12 and found that it does not delete a single key because of a bug. The company wrote that WordPress.org pushed the update to all users. But the WordPress.org page is for the free version, and the latest version there is 1.26.13. The paid version updates through the license from the company, and Nethemba's paid sites got 2.26.13 automatically on October 20. So check the version number on every site with your own eyes. And if your site is on a version older than 1.26.5, it also has the CVE-2026-10795 vulnerability in the same channel, which was fixed in June 2026 and still sees exploitation attempts according to Patchstack. ### 2. Delete the UpdraftCentral key by hand Even 1.26.13 leaves keys on the site: according to Nethemba, keys created on October 18 between 12:07 and 21:00 UTC remain. From the dashboard open `Settings > UpdraftPlus > Advanced Tools > UpdraftCentral`, click "Manage existing keys" and delete every key. Or with WP-CLI: ```bash wp option delete updraft_central_localkeys ``` The key that receives the commands is on the site itself, so removing the site from the UpdraftCentral dashboard leaves it as it is. Backups keep working after you delete it, and the only thing that stops is remote management. And if you are not migrating a site right now, delete the Migrator keys too (`wp option delete updraft_migrator_localkeys`), because they use the same channel. ### 3. Look for strange plugins, including Must-Use Open the plugins page, and the Must-Use tab with it if you see one. Must-Use plugins are files in the `wp-content/mu-plugins/` folder that always run on their own, and you cannot turn them off from the dashboard ([WordPress documentation](https://developer.wordpress.org/advanced-administration/plugins/mu-plugins/)). The first variant of the backdoor has the same description in every sample, so search for it from the site folder: ```bash grep -rl "Small maintenance toolkit: keeps option storage tidy\." wp-content/plugins/ wp-content/mu-plugins/ ``` The other variants have a new description each time so this search does not catch them, and "Site Health Cache" does not show up in the plugins list either. Nethemba published a read-only check script that changes nothing, which looks for the files, options, accounts and the UpdraftCentral log. Download it to the site folder as `check-updraftcentral.php`, and before you run it compare its SHA-256 with the number published on their page, because the script gets updated: ```bash curl -o check-updraftcentral.php https://nethemba.com/wp-content/uploads/2026/10/check-updraftcentral.txt sha256sum check-updraftcentral.php wp eval-file check-updraftcentral.php --skip-plugins --skip-themes ``` Lines marked `[ALERT]` are traces of an attack, and lines marked `[WARN]` are something you need to check. When you are done, remove the file from the site folder. ### 4. Look for strange accounts On the users page look for any account you do not recognize, not only among the admins. The second variant creates a full admin with a name like `system_team850` or `web.tech988` and an email at `@example.com`, and this account shows up as normal in the list. In samples of the first variant there are names like `data-ops43` and `media-staff96`, with the display name "Site Tools" and an email at `@example.org`. The names change, so Patchstack advises searching by permission: an Editor account that has `manage_options`. Replace `wp_` with your table prefix if it is different: ```bash 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%'" ``` Also check any admin created after October 17. And the variants that log the attacker in as an existing admin do not create an account, so only the plugin file and the server log give them away (step 6). ### 5. Look for the \_sync\_token option in the database The first variant saves an option in the database whose name starts with the plugin's name and ends in `_sync_token`: ```bash wp option list --search="*_sync_token" --fields=option_name ``` The options of the other variants (`_uid`, `_installed` and `_ver` at the end of the name) look like the options of normal plugins, so leave them to Nethemba's script. ### 6. Read the UpdraftCentral log and the server log On the same UpdraftCentral screen in the settings, open the event log and look for `probe.central.updraftplus.com` followed by `Command received: plugin.upload_plugin`. This log keeps only the last 50 events, so the trace may already be gone from it. If you have access to the server logs, search for the secret URL that triggers the backdoor (change the path; for nginx it is usually `/var/log/nginx/`): ```bash zgrep -E '[?&](_[0-9a-f]{6}|[0-9a-f]{12})=[^&" ]{32}[& ]' /var/log/apache2/*access* ``` According to Nethemba, a 302 response most likely means the attacker got in, a 500 means the broken variant is still there, and a 200 at your page's normal size means the backdoor is not here. And the attacker's commands have an incomplete User-Agent (`WordPress/6.4; class-udrpc.php`) without the library version and URL that the real service sends: ```bash grep 'class-udrpc\.php"' /var/log/apache2/*access* ``` The addresses seen in the attack are `43.250.53.42` and `2a09:bac5:4e21:2e3c::49b:9` according to Patchstack. And the attempts to trigger the backdoor on October 20 came from `178.83.37.220`, `178.83.37.243` and `178.94.218.31` and from the two ranges `69.33.133.x` and `69.33.134.x` according to Nethemba. Use them only to search the logs, because the attacker changed addresses on the same day. ### 7. Change passwords and watch your email Change the passwords of all admins on the site, and the password of your teamupdraft.com account: type the address yourself in the browser, not from a link in an email. If the same password is used somewhere else, change it there too, and set up two-factor authentication again from My Account. Customers' names and emails are most likely in the attacker's hands now, and the company itself warns about emails in its name that you were not expecting, and says it will not ask you for a password or a key. The company disconnected all sites from UpdraftVault, so backups will not reach it until you reconnect each site with the new password and try a manual backup. And old UpdraftClone keys stopped working, so if you gave some to your clients, send them the new ones. ## What do you do if you find a trace of the backdoor? Delete the key first, then remove the plugin and the account. And if the account exists, or the secret URL shows up in the log, treat the site as fully compromised and go back to a backup from before October 17. 1. Delete the UpdraftCentral key before anything else. As long as the key exists, the attacker can send a fixed version of the backdoor. 2. Deactivate the plugin and move its folder outside the site folder, and do not delete it from the dashboard: its `uninstall.php` file wipes its traces, and you want it as evidence. 3. Delete the options the plugin created, and the account the backdoor created. 4. Go back to a backup from before October 17 if the backdoor ran, compare the site's files with a clean install, and review every user with extra permissions. 5. Change the admin passwords and the UpdraftCentral account password, close all open sessions, and turn on two-factor authentication. The attacker had permission to install plugins, so they may have left behind another plugin, a webshell, or changes to the files or the database. And Nethemba warns that UpdraftPlus Premium can store the teamupdraft.com account password as you typed it in the `updraftplus-addons_options` option, so if the attacker reached the dashboard or the database, treat it as leaked. If after the cleanup you still do not know how far the attacker got, or the site holds customer or payment data, you need a deeper check than this list. [Muhassan](/muhassan) is penetration testing and hardening that finds the vulnerabilities in your platform before someone else does, and hands you a clear fix plan. ## When do you reconnect your sites to UpdraftCentral? The company says to reconnect after you delete the key, check the site and change the passwords. On October 19 Patchstack advised waiting until the company explains the cause, and as of October 21 the company has only said that the attacker got into its website with a leaked key. If you do not need remote management, the safest choice is to leave it disconnected. And if you need it, create the key from an account that does not have the `install_plugins` permission. On one of Nethemba's three sites, the key belonged to a user without this permission, and that detail alone stopped the attack. And if you are a developer building a plugin or a platform with remote control, the box checked by default is what connected sites without their owners knowing, and the key with no expiry date and the command with no confirmation are what let the stolen key work on any connected site, however old. So before you give any key permission to run commands, ask: what can this key do, and how long does it stay valid? To review the permissions in your code before you deploy, the [Security Skill Pack](/products/security-skill-pack) is still being prepared: skills that review your project's code and warn you about permission vulnerabilities, and you are the one who runs them. The pack is listed in the [AI skills](/products/c/ai-skills) section, meaning skills you add to Claude Code or to other AI tools. ## Where do you start now? Run the `wp option get updraft_central_localkeys` command above today on every site with UpdraftPlus, even the sites you do not open every day. Any site that returns something other than `[]` or a `Could not get` message has a key: start the list on it from step one. And you, how many of your sites turned out to have a key you did not know was there? ## FAQ **Which version of UpdraftPlus fixes the problem?** 1.26.13 for the free version or 2.26.13 for the paid one, or later. The plugin's changelog on WordPress.org says 1.26.13 came out to properly apply the key revocation that did not work in 1.26.12. And according to Nethemba even 1.26.13 leaves some of the keys, so delete the key by hand too. **Do I have to remove UpdraftPlus from my site?** No, there is no need to remove it. Delete the UpdraftCentral key (and the Migrator keys if you are not migrating a site), update to 1.26.13, and check the site. According to Patchstack and Nethemba, backups keep working. **Is there a CVE number for this incident?** No. Patchstack classifies it as a leaked key, not a bug in the code. The number CVE-2026-10795 you may see in the news is a different vulnerability in the same channel, fixed in June 2026 in versions 1.26.5 and 2.26.5. **Are my backups on Google Drive or Dropbox at risk?** According to TeamUpdraft, no, the backups on your storage were not affected. But if your site was accessed through UpdraftCentral, the company asks you to reconnect the storage and change its access keys as a precaution. **Where do I delete the UpdraftCentral key?** On each site individually, from the UpdraftPlus settings or with WP-CLI. The key that receives the commands is on the site, and the attacker has the private key of the UpdraftCentral dashboard, so removing the site from the UpdraftCentral dashboard leaves the site's key as it is. **What do I do with the IP addresses seen in the attack?** Search for them in your server logs, but do not rely on blocking them. Patchstack says the attacker changed addresses on the same day, and the protection is deleting the key.