Delete UpdraftCentral keys after WordPress site takeovers
UpdraftCentral keys stolen from the remote management service are being used to install backdoors on connected WordPress sites. Patchstack said the campaign operated continuously during an 18-hour window on 18 and 19 October 2026, with the first installation recorded at 15:32 on 18 October and the most recent at 09:23 the following day. Its 08:00 UTC status update said exploitation remained active and no vendor fix existed. TeamUpdraft published a security incident post at 13:00 UTC.
This is a credential compromise rather than a flaw in UpdraftPlus code, so installing the latest plugin does not stop the attack. All free and premium UpdraftPlus versions are affected when a site has an active UpdraftCentral connection, including releases 1.26.11 and 2.26.11. Patchstack assigned the incident a CVSS score of 9.8, using the Common Vulnerability Scoring System scale for security severity. UpdraftPlus has more than four million active installations, although only sites holding an UpdraftCentral key are exposed to this campaign.
UpdraftCentral is a separate remote management service whose client is included in every UpdraftPlus installation. The client remains inactive until a site receives a connection credential. At that point, the site creates an RSA key pair, a matched set used to verify encrypted instructions, and stores the dashboard's public part. It will then execute commands signed by the corresponding private part with the permissions of the WordPress user who established the connection. Individual commands do not require further confirmation.
A site can receive such a credential by joining an UpdraftCentral dashboard or connecting to a TeamUpdraft.com account. On the account screen, the option to add the website to remote centralised control is selected by default. The option only appears if no credential exists, so one successful account connection can enrol a site whose owner did not knowingly intend to use UpdraftCentral. Patchstack said credentials issued in November 2025 were still valid in October 2026 because they do not expire. The dashboard's private credentials remain in the cloud service rather than on connected websites.
The attacker sends a validly signed plugin.upload_plugin instruction through the remote command channel, which accepts ordinary POST requests, meaning data sent to the website. WordPress then installs and activates the supplied plugin through its normal installer. Nethemba, which found the campaign on three sites in its own infrastructure and published the first analysis, reported that the local plugin files matched official releases, credential fingerprints had not changed across days of backups, the cryptography worked correctly, and logs showed neither an unauthorised administrator nor a conventional plugin upload. The hostile requests came from attacker-controlled infrastructure rather than the service's normal systems. The evidence therefore pointed to credentials escaping from the UpdraftCentral Cloud environment, but TeamUpdraft had not explained the cause when Patchstack published its findings.
Each uploaded plugin contains a backdoor that runs early during every WordPress request and waits for a secret URL parameter containing a 32-character value. If supplied, it creates an account with a built-in password and labels it as an Editor. It then separately grants manage_options and install_plugins, two WordPress capabilities that allow settings changes and installation of executable plugin code. The visitor is logged in through a persistent browser cookie and redirected to wp-admin without passing through the login form. That bypasses two-factor authentication, login-attempt limits and login-protection plugins.
The disguised account remains after the malicious plugin is removed, and the attacker already knows its password. The samples analysed contained a programming error that caused an HTTP 500 server error before their activation check could run, making every uncached page request fail. That visible outage alerted the first victims within minutes. Site owners should not repair the malicious code because correcting the error would activate its intended behaviour.
Patchstack recorded 99 different plugin names. “Site Health Cache” appeared repeatedly, while most others were random two-word or three-word combinations used once. The more reliable indicator is the identical description “Small maintenance toolkit: keeps option storage tidy.” Confirmed accounts included data-ops43 and media-staff96, but other names should be expected. Additional signs include an address ending in @example.org, the display name “Site Tools”, a database option ending in _sync_token, unfamiliar WordPress error emails, and plugin installations with no matching administrator action.
The observed requests came from 43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9. The IPv6 address appeared about three hours before the IPv4 address, and both operated concurrently. Because the attacker changed infrastructure within one day, blocking those addresses is not an adequate defence. Genuine remote traffic includes a library version and service URL in its User-Agent identification; the hostile requests omitted both. UpdraftCentral logs may also show probe.central.updraftplus.com followed by “Command received: plugin.upload_plugin.”
Administrators should check for a connection even if they only use UpdraftPlus for backups. With WP-CLI, the command-line tool for administering WordPress, run wp option get updraft_central_localkeys. Any output means a credential is present. In wp-admin, it can be removed through Settings, UpdraftPlus Backups, Advanced Tools, UpdraftCentral, then “Manage existing keys” and deletion of every entry. The WP-CLI alternative is wp option delete updraft_central_localkeys. Removing the website only from the central dashboard is insufficient because the relevant copy remains on the site. Scheduled backups continue after deletion; only remote management stops.
If a backdoor is found, remove the UpdraftCentral credential first so the attacker cannot send a replacement. Deactivate the plugin and move it outside the web-accessible directory instead of deleting it through wp-admin, because its uninstall process removes its own traces. Delete the associated _sync_token option and concealed account. If that account exists, or access logs show the secret activation parameter, treat the site as fully compromised: restore a backup from before the attack, compare files with a clean WordPress installation, review every user with extra capabilities, change administrator and UpdraftCentral Cloud passwords, terminate all sessions and enable two-factor authentication. Do not reconnect until the cause has been explained. If remote management is essential, Patchstack notes that using an account without install_plugins prevented the attack on one publicly analysed site.