UpdraftPlus and PHP2Shell: What We Found on Our Clients’ Sites

Two attacks in one week will make you look twice at a quiet WordPress dashboard. First came the UpdraftPlus connection-key breach. Then PHP2Shell, a pair of flaws in PHP itself. As the reports came in, we checked every site on our maintenance plan. I’m releived by what we found, but I don’t want to turn that relief into a claim that our sites can’t be hit. Some of our setup helped. Some of it was luck.

What happened that week

On 17-18 October, TeamUpdraft, the company behind UpdraftPlus, was breached. The attacker stole UpdraftCentral connection keys and used them to send commands to connected sites. TeamUpdraft now confirms that the attacker used those connections to create admin accounts and install malicious plugins. The full extent is still unknown.

UpdraftPlus released version 1.26.13 for free users and 2.26.13 for Premium users on 19 October. Those updates revoke the old UpdraftCentral keys. I covered the first warning in our post about the stolen UpdraftCentral keys. There’s a later detail worth repeating: on 21 October, TeamUpdraft said Premium users should check for unexpected plugins and new admins even if they never used UpdraftCentral.

Then, on 20-21 October, came PHP2Shell: two critical flaws in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. They’re fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This isn’t a WordPress plugin issue. You can’t fix it by clicking Update in wp-admin; your host needs to update PHP and restart it.

We checked our maintenance clients’ sites without changing them

We checked every site on our maintenance plan the same day and the next day. It was a read-only audit. We didn’t change anything on the sites during the check. We looked, wrote down what we found and reported it.

That kind of review is part of our WordPress maintenance. This week made it feel less routine than usual. A site can look normal from the front while an unfamiliar admin account sits in the back, so “the homepage loads” wasn’t much of a test.

• No maintenance client site was hit by the UpdraftPlus attack or PHP2Shell, and we found no signs of PHP2Shell exploitation.
• Every UpdraftPlus install on those sites was the free version. None was connected to UpdraftCentral or a TeamUpdraft account, so no stolen connection key could reach those sites.
• We found none of the unknown plugins or new admin accounts that the UpdraftCentral attack left behind on other sites since 17 October.
• Since then, every client copy of UpdraftPlus we found is on 1.26.13, including sites outside our maintenance plan.
• About 90% of the sites we checked were on hosts that patched PHP the same day. The rest run on old PHP branches, and we’re moving them to a supported PHP version.

That’s a good result. It isn’t a magic shield. In particular, the UpdraftPlus result owes a lot to a simple setup: no remote dashboard connection we didn’t need, and no keys for an attacker to use. The PHP result depended heavily on how quickly hosts patched.

---

The PHP2Shell picture is less simple than the headlines

There’s new information since our first PHP2Shell post. Wordfence’s lab got code execution for one flaw only on a specially configured PHP build. The same test crashed a standard PHP build instead. In its WordPress 7.1.3 tests, the other flaw caused PHP failures and restarts rather than code execution.

Does that mean an unpatched server is fine? No. Wordfence still warns against treating one as safe, because an attack may be adapted to a particular server. Patchstack reported that hosting partners confirmed multiple real exploitation incidents. Cloudflare said it was seeing millions of exploit attempts. Attempts, mind you, not millions of successful hacks.

My read: “everyone gets hacked tomorrow” is too loud, but “our site seems fine, we’ll leave PHP alone” is too casual. The sensible move is to confirm the patch and restart with your host, rather than guessing from the version number you can see in WordPress.

What you can check on your own site

You don’t need to understand PHP internals to do the useful bits. Give yourself ten minutes for the dashboard checks, then send your host a direct question. Keep the reply.

1. Update UpdraftPlus. Use 1.26.13 or later for the free plugin, or 2.26.13 or later for Premium. Open Settings > UpdraftPlus > Advanced Tools > UpdraftCentral and delete connection keys you don’t use.
2. Check accounts and plugins if you use Premium. Look in Users for admins you don’t recognise. Check Plugins, including Must-Use plugins, for anything unfamiliar. Do this even if you never used UpdraftCentral.
3. Ask about your PHP patch. Find your PHP version at Tools > Site Health > Info > Server. Ask your host whether PHP was patched for PHP2Shell and restarted. Don’t settle for “we keep servers updated” if they haven’t answered that question.
4. Plan a move if you’re on PHP 8.1 or older. Don’t put it off until the next scare. Ask whoever maintains your site to check compatibility and schedule the move to a supported version.
5. Keep backups from before 17 October. If an account or plugin looks odd, don’t just delete it and hope. Get help checking what happened; hacked site cleanup is about finding the cause as well as removing what shouldn’t be there.
6. Remove connections you don’t use. That includes remote management connections and plugins you installed for a task that ended months ago.

What I’d take from our result

I’m glad our check found no affected maintenance client sites. I’m also aware that a different set of connections, or a slower host response, could have given us a different week. Free UpdraftPlus installs with no UpdraftCentral connection weren’t exposed through those stolen keys. That’s a narrow finding, not a promise about every future attack.

If you do one thing today, ask your host this exact question: “Was the PHP version serving my site patched for PHP2Shell and restarted?” Then check your UpdraftPlus connections. Those two answers will tell you more than another alarming headline.