Stolen UpdraftCentral Keys: Why Patching and 2FA Will Not Save You

Attackers are installing backdoors on WordPress sites using keys stolen from the vendor, not a plugin flaw. Updating does not fix it, two-factor authentication is bypassed, and removing the plugin can leave the account behind.

There is a WordPress compromise going on right now that will not show up in any vulnerability scan, because nothing on your site is vulnerable. The plugin is not flawed. Your version is not out of date. Someone stole a key from the vendor, and that key opens your site. I want to walk through it, because almost every instinct people have about WordPress security points the wrong way here.

What actually happened

UpdraftCentral is the remote-control side of UpdraftPlus, the backup plugin. You connect your sites to a dashboard with a key, and from then on that dashboard can act on those sites — take backups, run updates, install things. That is the entire point of it.

TeamUpdraft, who make it, say an attacker got into their own website and, they believe, reached a customer database holding UpdraftCentral Cloud connection keys. Patchstack reports the resulting attacks began on 18 October at 15:32 UTC, with attackers using stolen keys to install backdoor plugins. Patchstack has counted 99 different plugin names used as cover, including deliberately boring ones like "Site Health Cache."

Read that sequence again, because the direction matters: the breach happened at the vendor, and the consequence arrived at the customer. Nothing was done wrong on the sites that got hit.

Why your usual defences do not apply

This is the part that deserves attention. Three things most site owners rely on do nothing here.

Updating is necessary, but it is not the whole fix. TeamUpdraft's advisory names UpdraftPlus 1.26.13 (free) and 2.26.13 (Premium) as the release that revokes UpdraftCentral connections made before 22:00 BST on 18 October. Their own checklist still says 1.26.12 — an earlier release that reporting says revoked nothing — so treat 1.26.13 as the floor. Even then, the advisory tells you to delete the connection key by hand under Settings → UpdraftPlus → Advanced Tools → UpdraftCentral, and the update undoes nothing the attacker already did.

Two-factor authentication does not help. Patchstack reports the attacker can arrive with a persistent cookie that bypasses the login form entirely. If the login form never runs, neither does your 2FA, and neither does your login-protection plugin. Those tools guard a door this traffic does not use.

Removing the plugin may not clean up after it. Some variants create a user account with a hard-coded password, set it to Editor, and then grant it the capabilities to manage options and install plugins — which is administrator access wearing an Editor label. Delete the plugin and that account can remain. Revoking a key stops the same connection being reused; it does not remove something already installed.

What to do, in this order

  1. Revoke your UpdraftCentral keys now. Do not wait for a plugin update. If you do not use the remote dashboard, you may still have a key from when you set the plugin up.
  2. Look for users you did not create. Check every account, not just administrators — an Editor with extra capabilities is the pattern here, and it is easy to skim past.
  3. Read your plugin list properly. Not "does anything look suspicious," but "do I know why each one of these is here." The disguises are chosen to survive a glance.
  4. Check capabilities, not just roles. A role name tells you less than what the account can actually do.
  5. Then change the passwords for any account you keep, and rotate other integration keys while you are in there.

If you find something installed, you are past cleanup and into incident response: assume anything stored on that site was readable, and restore from a backup predating 18 October if you have one you have actually tested.

The thing worth changing afterwards

Patchstack notes that keys issued in November 2025 still worked in October 2026. They do not expire. So a key you created once, for a dashboard you may have stopped using, stayed valid for a year with full privileges on your site.

That is the general lesson, and it is bigger than one plugin. A remote-management key is an administrator credential. It is usually created once during setup, never rotated, never reviewed, and — the part people miss — it lives at the vendor, not with you. Which means the security of your site is partly the security of their company, and you will find out how good that is at the same time everyone else does.

Patchstack also points out this is the second incident on this same remote-command channel in roughly five months, following a vulnerability fixed in June. One incident is bad luck. Two in five months on the same channel is a pattern worth weighing when you decide what gets standing access to your site.

I am not telling anyone to stop using managed backups; the convenience is real and backups matter more than most things. But every always-on connection into your site is a door you are trusting someone else to guard. Keep a list of them. Revoke the ones you are not using. That list takes twenty minutes to write and is the cheapest security work available to a small site.

Frequently asked questions

I use UpdraftPlus for backups but never set up the dashboard. Am I affected? Probably not, but check rather than assume — a connection key can exist from an initial setup you do not remember completing. If no key was ever issued for your site, this campaign has nothing to use against it, and your backups keep working normally after you revoke keys.

My site looks completely normal. Does that mean it is fine? Not on its own. The accounts and plugins used here are built to look unremarkable, and a persistent-cookie login leaves nothing visible on the front end. "Nothing looks wrong" and "nothing is wrong" are different statements, and only the checklist above tells them apart.

Is this the same thing as the critical PHP flaws patched in October? No, and they should not be confused. Those were vulnerabilities in PHP that you fix by patching. This is a stolen credential at a vendor that you fix by revoking the key. They happened in the same week and the remedies have nothing in common.