How Do You Know What to Patch When the World’s on Fire? Lessons from php2shell

What is php2shell?

php2shell is the name given to two critical remote code execution flaws in the PHP runtime itself, tracked as CVE-2026-109618 and CVE-2026-109619.[1] The first turns PHP’s handling of out-of-memory conditions into code execution. The second abuses internal state that survives after the memory behind it has been freed. Neither needs the attacker to log in.[3]

The PHP project released fixes on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published minimal backports for the unsupported 7.4, 8.0 and 8.1 branches, and urged all users to update immediately.[1][4] CISA called for immediate patching the same day.[2] Every PHP installation serving web requests is in scope, whether it runs PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed.[4] Details leaked the day before the scheduled release, and Cloudflare reported early attacks before the patches had even shipped.[3][5] PHP’s own developers have been clear that configuration workarounds only partly reduce the risk, and that patching is the only permanent fix.[3]

PHP is everywhere: your website, your CMS, half the appliances in the rack, and things you’ve forgotten are even running it. So “just patch everything with this CVE, now” sounds right until you actually try to do it.

Why patching everything at once isn’t the safe option

Patching isn’t free. A serious patch usually means downtime, and downtime usually means lost revenue, or your clients can’t work, or something that was quietly holding the business together falls over. So the instinct to hit every affected system at once isn’t the safe choice it feels like. It’s just a different risk, and sometimes a worse one.

The real skill in vulnerability prioritisation is working out what to do first, and you can’t do that well in the middle of the fire if you haven’t done some thinking beforehand. Four things help.
 

Four ways to decide what to patch first

1. Know what actually matters to the business

Sit down, while nothing’s on fire, and map what’s genuinely critical to operations, and be prepared to make some uncomfortable calls about what isn’t. When the fire comes, this is what tells you where to point the hose first. Without it you’re just patching in the order things appear on a scanner, which has nothing to do with what would actually hurt you.

2. Get the business to back the groundwork, and to fund visibility

None of this works without buy-in, both to spend the time on point one and to invest in actually knowing what you’ve got. If you don’t know what’s on your network, you can’t be sure you patched all of it. I regularly see “forgotten firewalls” turn up as the way in, some box nobody was looking after, running something years out of date, because it fell off everyone’s list. You can’t patch what you don’t know is there.

3. Look at your external attack surface, but don’t write off the inside

Review your external attack surface regularly, because reachability is a huge factor in how serious a vulnerability actually is. A critical flaw on something exposed to the internet is a more immediate problem than the same flaw sitting deeper in, and seeing yourself the way an attacker sees you tells you which fires are genuinely urgent.

But internal doesn’t mean untouchable. All it takes is a set of stolen VPN credentials or one compromised laptop and the attacker is inside, and that “internal” vulnerable asset is exactly what they pivot to next. So external-facing systems go to the front of the queue, but the internal ones are a “soon”, not a “never”. Plenty of bad days have started with someone getting a foothold and then finding the unpatched box nobody worried about because it wasn’t exposed.

4. Build threat context

Context is king. If you have some sense of who might come after you and what they tend to exploit, you have a real basis for deciding what’s critical to patch, rather than just reacting to whatever’s loudest in the news that week. Context comes from inside too, which loops back to point one, because knowing your own environment is half of knowing what matters.

The patching decision is made before the vulnerability lands

None of that is dramatic, and none of it is the thing anyone wants to spend money on, because it’s the quiet work that just sits there until the day it’s the only thing that helps. But the choice of what to patch first, when everything’s marked critical and the clock’s running, is really made long before the vulnerability drops.

The organisations that handle something like php2shell well aren’t the ones who patch fastest in a panic. They’re the ones who already knew what mattered, knew what they had, and knew where they were exposed. When the world caught fire, they could answer the simple question everyone else was still staring at.
 

Next steps

Thomas Murray helps organisations understand and manage cyber risk across their own estate and their wider ecosystem, from external attack surface visibility to threat intelligence and tabletop exercises. To discuss how prepared your organisation would be for the next php2shell, book a 30-minute call with one of our consultants.
 

• Cyber risk consulting
• Threat intelligence: shining a light on the dark web

• Tabletop exercises: where to start
   

  ---

  Sources

• [1] PHP project, security advisory, 21 October 2026, php2shell (CVE-2026-109618, CVE-2026-109619)
• [2] Cybersecurity and Infrastructure Security Agency (CISA), 21 October 2026, Critical Vulnerabilities in PHP Require Immediate Patching
• [3] BleepingComputer, 21 October 2026, PHP ships emergency patches for critical PHP2Shell flaws
• [4] Help Net Security, 21 October 2026, PHP2Shell: Critical PHP vulnerabilities patched, update now
• [5] SOCRadar, October 2026, PHP2Shell: CVE-2026-109618 and CVE-2026-109619