php2shell: how we secured 300+ websites in only 24 hours

Last week there was a big RCE CVE announced on PHP. The recommendation was to close websites entirely, so this put pressure on every devops and sysadmin that day.

• What was the problem?
• Was it that bad?
• What was the fix?
• How having Unolia helped a lot
• How we upgraded an old fleet of websites
• What's next?
• TL;DR

#What was the problem?

Skip this part if you already know about it.

On October 20, a post about two critical PHP vulnerabilities leaked on Hacker News before the coordinated disclosure. The PHP team shipped an emergency release the next day. People quickly started calling it php2shell.

• CVE-2026-109618: RCE via out-of-memory corruption. If a request hits memory_limit at the wrong moment, PHP can keep half-initialized data and use it later. On Apache with mod_php, it can be triggered before any of your code runs, with default settings.
• CVE-2026-109619: RCE via stale global state. A fatal error at the wrong time can leave internal state pointing to memory from a previous request. The next request on the same worker then uses that freed memory.

Both are unauthenticated and rated 9.2 (the leaked report said 10.0). The official recommendation was to take websites down and wait for the patch, so yes, it caused a little panic.

#Was it that bad?

A researcher broke into an unpatched server baited with $2,000 in Bitcoin in about 19 hours and published a PoC right after.

Cloudflare was confident enough in their WAF rules to open a public capture the flag challenging anyone to bypass them with php2shell, and it got breached too.

#What was the fix?

Upgrade. There was no other real fix.

The fixed versions were 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything on 8.1 or older was unsupported, PHP only published minimal source backports for 7.4, 8.0 and 8.1.

To be safe, we also disabled session.upload_progress in php.ini, as PHP recommended until the next regular release. PHP was clear that these temporary mitigations were not complete fixes, they only bought time.

#How having Unolia helped a lot

Unolia helped for two reasons.

Having an inventory of my apps ready to be read. Which servers run which PHP version? Unolia already knew, no need to build a list that morning.

Having automations ready to upgrade my websites. Everything was already in place to upgrade my websites right after the new PHP packages were released. And the automation view makes it clear what has been upgraded and what hasn't.

#How we upgraded an old fleet of websites

For a client, it was another story. A lot of websites, some of them untouched for years, and no inventory we could trust.

It took 5 guys and 5 Claude subscriptions. Everyone took a batch of websites, and Claude Code did a lot of the heavy lifting: reading error logs, fixing deprecations, adapting old code to the new PHP version. We still reviewed and tested every website before switching it.

A lot of coordination went through an old but trusty Google Doc. One line per website: server, current PHP version, who's on it, status. Nothing fancy, but everybody knew what the others were doing.

And that's how we made 300+ websites ready to have PHP upgraded:

• ~100 were already good.
• ~100 needed an Ubuntu upgrade or a move to a different VPS.
• ~100 needed their code upgraded. Those old websites sit on managed hosting, so changing the PHP version was fast, but we had to upgrade and test them locally first.

Funny thing, Claude found some security issues in those old codebases along the way. So we didn't only patch PHP, we also secured the fleet a bit more.

#What's next?

First, improve Unolia. Everything we did manually for this client, probing servers over SSH to know what runs where, should be a feature. The day a CVE drops is not the day you want to build your inventory.

Second, I have a new idea. AI helped a lot during this security crisis. I'm thinking about fast and real-time protection of servers.

A lightweight daemon running on each server: web attack protection, malware scanning, suspicious activity detection, and mitigations applied fast. Plugged into a central dashboard to handle security alerts quickly. Connected to your AI agent (BYOK or MCP).

I believe my 20 years of experience on the subject could help people be more secure. Especially those who still host their own infrastructure and don't use the cloud, for many reasons: use cases, laws, prices...

I could write the prompts that help the AI build a PoC for each new vulnerability, test the affected servers in real time, and propose automated mitigation fixes.

More on that soon.

If you want to follow this, subscribe to the newsletter or follow me on /dev/null, Bluesky, Mastodon, LinkedIn or Twitter.

#TL;DR

• php2shell was two unauthenticated RCEs in PHP itself, already exploited in the wild.
• The only real fix was upgrading PHP.
• My personal websites were upgraded through Unolia, the inventory and automations were already in place.
• For a client, 5 people, 5 Claude subscriptions and a Google Doc made 300+ websites ready for the upgrade in 24 hours, and Claude found a few security issues along the way.
• Next idea: a lightweight security agent running 24/7 on each server, bring your own key or MCP.