/
← Voltar ao feed
critical

Stolen UpdraftCentral dashboard keys used to push backdoor plugins to connected WordPress sites

1 fonte(s) · 1 atualização(ões) · publicado 19/10/2026 05:19 · coletado há 5 horas

An attacker holding valid UpdraftCentral dashboard private keys installed backdoor plugins on connected WordPress sites in an 18-hour campaign on 18-19 October 2026. Patchstack telemetry shows installations across a broad set of sites between 18 Oct 15:32 and 19 Oct 09:23 UTC. This is not a vulnerability in UpdraftPlus: the commands are correctly signed, so every plugin check passes, and no plugin update stops the attack as of 19 October. Nethemba discovered the campaign on its own infrastructure and published the first analysis. Evidence points to the keys leaking from the UpdraftCentral Cloud environment, and TeamUpdraft has published an incident post. This is the second incident in this channel in five months, after CVE-2026-10795 in June 2026.

Technical Details

  • UpdraftCentral's client ships in every UpdraftPlus copy (over 4 million installs) and stays dormant until the site holds a key. Connecting a TeamUpdraft.com account creates a key by default through a pre-ticked checkbox, so many sites hold keys nobody deliberately created. Keys do not expire: keys issued in November 2025 still worked in October 2026.
  • The attacker sends a signed plugin.upload_plugin command over the RPC channel (POST requests to the site root). WordPress installs and activates the plugin through its standard installer, with the permissions of the user who created the connection.
  • The backdoor plugin hooks early on every request and watches for a secret URL parameter carrying a 32-character token. It then creates an account with a hardcoded password and the Editor role, and grants it manage_options and install_plugins. It sets a persistent login cookie directly, which bypasses 2FA and login protection plugins.
  • The account persists after the plugin is removed. Because it appears as an Editor, administrator-list reviews miss it.
  • Analysed samples contain a coding error that causes HTTP 500 on uncached requests. Do not repair the plugin, because fixing the error activates the backdoor.
  • A minority of installations never activated, but those sites should still be treated as affected.
  • 99 distinct plugin names were observed. "Site Health Cache" is reused most. Every sample carries the description "Small maintenance toolkit: keeps option storage tidy."
  • Source IPs were 43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9, rotated within a day, so IP blocking is not a reliable control.
  • Attacker requests use a User-Agent containing class-udrpc.php without the library version and URL that genuine dashboard traffic carries.
  • Known backdoor usernames are data-ops43 and media-staff96. Other markers are an @example.org email, the display name "Site Tools" and a DB option ending in _sync_token.
  • Sites below 1.26.5 / 2.26.5 also face the forged-command flaw CVE-2026-10795 (CVSS 8.1), which is still seeing exploitation attempts.

Remediation

  • Check for keys with wp option get updraft_central_localkeys, then delete them via the UpdraftCentral settings or wp option delete updraft_central_localkeys. Removing the site from the dashboard is not enough. Backups keep working.
  • Do not reconnect until the vendor explains the cause. If remote management is needed, create the key under an account without install_plugins.
  • Hunt for the plugin description string, Editor accounts holding manage_options, the activation-parameter pattern in access logs, and plugin.upload_plugin entries in the UpdraftCentral log.
  • Delete the key before removing the backdoor, or the attacker pushes a corrected replacement. Deactivate the plugin and move it out of the web root rather than deleting it via wp-admin. Remove the _sync_token option and the rogue account.
  • If the account exists or the trigger appears in logs, treat the site as fully compromised: restore from a pre-attack backup, review accounts with extra capabilities, rotate administrator and UpdraftCentral Cloud passwords, end all sessions and enable 2FA.
  • Patchstack customers are covered by mitigation rules, and Patchstack currently blocks UpdraftCentral remote commands.

Linha do tempo

  1. patchstack.com ↗ · pub. 19/10/2026 05:19 · coletado 20/10 16:32 primeiro registro

    Stolen UpdraftCentral dashboard keys used to push backdoor plugins to connected WordPress sites

    ler a análise desta fonte

    An attacker holding valid UpdraftCentral dashboard private keys installed backdoor plugins on connected WordPress sites in an 18-hour campaign on 18-19 October 2026. Patchstack telemetry shows installations across a broad set of sites between 18 Oct 15:32 and 19 Oct 09:23 UTC. This is not a vulnerability in UpdraftPlus: the commands are correctly signed, so every plugin check passes, and no plugin update stops the attack as of 19 October. Nethemba discovered the campaign on its own infrastructure and published the first analysis. Evidence points to the keys leaking from the UpdraftCentral Cloud environment, and TeamUpdraft has published an incident post. This is the second incident in this channel in five months, after CVE-2026-10795 in June 2026.

    Technical Details

    • UpdraftCentral's client ships in every UpdraftPlus copy (over 4 million installs) and stays dormant until the site holds a key. Connecting a TeamUpdraft.com account creates a key by default through a pre-ticked checkbox, so many sites hold keys nobody deliberately created. Keys do not expire: keys issued in November 2025 still worked in October 2026.
    • The attacker sends a signed plugin.upload_plugin command over the RPC channel (POST requests to the site root). WordPress installs and activates the plugin through its standard installer, with the permissions of the user who created the connection.
    • The backdoor plugin hooks early on every request and watches for a secret URL parameter carrying a 32-character token. It then creates an account with a hardcoded password and the Editor role, and grants it manage_options and install_plugins. It sets a persistent login cookie directly, which bypasses 2FA and login protection plugins.
    • The account persists after the plugin is removed. Because it appears as an Editor, administrator-list reviews miss it.
    • Analysed samples contain a coding error that causes HTTP 500 on uncached requests. Do not repair the plugin, because fixing the error activates the backdoor.
    • A minority of installations never activated, but those sites should still be treated as affected.
    • 99 distinct plugin names were observed. "Site Health Cache" is reused most. Every sample carries the description "Small maintenance toolkit: keeps option storage tidy."
    • Source IPs were 43.250.53.42 and 2a09:bac5:4e21:2e3c::49b:9, rotated within a day, so IP blocking is not a reliable control.
    • Attacker requests use a User-Agent containing class-udrpc.php without the library version and URL that genuine dashboard traffic carries.
    • Known backdoor usernames are data-ops43 and media-staff96. Other markers are an @example.org email, the display name "Site Tools" and a DB option ending in _sync_token.
    • Sites below 1.26.5 / 2.26.5 also face the forged-command flaw CVE-2026-10795 (CVSS 8.1), which is still seeing exploitation attempts.

    Remediation

    • Check for keys with wp option get updraft_central_localkeys, then delete them via the UpdraftCentral settings or wp option delete updraft_central_localkeys. Removing the site from the dashboard is not enough. Backups keep working.
    • Do not reconnect until the vendor explains the cause. If remote management is needed, create the key under an account without install_plugins.
    • Hunt for the plugin description string, Editor accounts holding manage_options, the activation-parameter pattern in access logs, and plugin.upload_plugin entries in the UpdraftCentral log.
    • Delete the key before removing the backdoor, or the attacker pushes a corrected replacement. Deactivate the plugin and move it out of the web root rather than deleting it via wp-admin. Remove the _sync_token option and the rogue account.
    • If the account exists or the trigger appears in logs, treat the site as fully compromised: restore from a pre-attack backup, review accounts with extra capabilities, rotate administrator and UpdraftCentral Cloud passwords, end all sessions and enable 2FA.
    • Patchstack customers are covered by mitigation rules, and Patchstack currently blocks UpdraftCentral remote commands.