What PHP2Shell Showed Us About Patch SLAs

On October 20, an anonymous person posted the CVE numbers for two unpatched PHP bugs on Hacker News. The post came down, but not fast enough. PHP pulled its release forward and shipped fixes the next afternoon, and watchTowr's honeypots saw exploitation attempts that same day.

The bugs, CVE-2026-109618 and CVE-2026-109619 (now going by PHP2Shell), give an unauthenticated attacker code execution on a PHP server. Both are rated 9.2. They affect PHP-FPM, mod_php, php-cgi, LiteSpeed and FrankenPHP, so if you serve PHP on the web, you're in scope. PHP calls mod_php the worst case, since the attack can land before your application code even runs.

A few things stand out from this one.

A 30-Day SLA Doesn't Mean Much Here

Most programs still give criticals 15 days and highs 30. Those windows were set back when building a working exploit took a while. 

SLAs still have a job. They're how you keep the long tail moving. But for something like PHP2Shell, the SLA clock isn't what decides whether you get hit.

The Patch Is the Easy Part (if You Can Patch)

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you're on one of those branches, update.

The harder part is everything else:

• PHP 7.4, 8.0 and 8.1 don't get an official release, so you're relying on your distro, an LTS vendor or PHP's source backports. 7.3 and older get nothing. VirusTotal counted roughly 758,000 internet-facing hosts advertising end-of-life PHP, and that's only the ones that advertise a version at all.
• PHP turns up in places nobody thinks of as "a PHP server": vendor appliances, old marketing microsites, a container image someone built two years ago. Qualys also noted that some hosts carry more than one PHP binary, so patching the main one can leave another exposed.
• Updating the package does nothing until the workers restart. It's an easy step to miss when you're moving fast. Check what's actually answering requests, not just php -v.

Deciding What to Fix First

Once you have a list, every PHP2Shell finding carries the same 9.2. That number won't help you choose between an internal staging box and an internet-facing server with no EDR agent and a service account that can reach your customer database.

The second server is the one an attacker wants. Each problem on it (the CVE, the missing agent, the over-privileged account) might sit in a different team's backlog with a different severity. Put together, they're a way in.

This is the slow part to do by hand, because the answer is spread across tools. The scanner has the CVE. The EDR console knows what isn't covered. The identity tool knows what that account can touch. Someone has to stitch it together, usually in a spreadsheet, usually late at night.

What We’d Recommend

If you're still working through it:

1. Build the inventory from more than one source. Your scanner, EDR, CMDB, and cloud assets will each miss something.
2. Start with internet-facing hosts, and mod_php before the rest. Then look at what each host can reach and whether your controls actually cover it.
3. Where you can't patch today, cut the risk down. Set session.upload_progress.enabled=0 at the server or pool level (not in .user.ini), tighten request size limits, block multipart requests at the edge where you don't need them, and take the host off the internet if you can. PHP is clear that none of this fully fixes the bug, so think of it as buying time.
4. Patch, then restart every worker.
5. Go back and check. Confirm the runtime version, confirm the settings stuck, and keep watching. Config changes have a habit of disappearing on the next redeploy.

Where Nagomi Fits

This is the work we built Nagomi to take off a team's plate. Our Agents connect to the tools you already run through read-only APIs. They pull scanner, EDR, identity and cloud data into one picture, work out which exposures actually connect into a path, recommend a fix (a patch, a config change or a compensating control), and then check that it held. Your team still approves every action.

There will be another one of these, probably sooner than anyone would like. When it comes, applying the patch won’t be the hard part. The hard part will be the same questions as this week: where does it run, what can it reach, and did the fix actually take place? Those are a lot easier to answer on a normal Tuesday than in the middle of an emergency release.

Want to see which of your PHP hosts sit on a real attack path? We're happy to walk through it with you on your own data. Request a Demo