COMMENTARY: When a big bug like PHP2Shell hits the industry we tend not to focus on what happens next.
Discovering a critical vulnerability in a core technology only represents the beginning: it’s much harder to find every affected system and secure it before attackers arrive.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
PHP2Shell sends that message home like a 10# sledgehammer. It’s bad folks, in ways we may not see just yet.
On October 21, 2026, PHP disclosed two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS 4.0. An unauthenticated attacker can execute code through a vulnerable PHP runtime handling web requests. And both are confirmed exploited in the wild.
The PHP project says only an update can safely fix the issue.
For security teams, there’s a preordained response: identify affected systems, patch urgently, and investigate for IOCs. But, the immediate question is not the whole question. We must start thinking about residual effect, and whether our inventory includes every place PHP actually runs or is vulnerable.
The PHP we don't know we’re running
PHP most often gets associated with web servers and content management systems, but it’s also possible to compile it from source, installed in custom directories, or bundled inside applications and even firmware. Multiple copies can coexist on one machine. A command-line version check may not reflect the runtime processing web requests.
This creates a vulnerability management gap between familiar and unknown. There’s no shame in it, if a chip gets discovered as vulnerable, it’s completely reasonable that we may not know which devices have it soldered to a PCB somewhere. The inventory says one thing, while the system does another under the hood. Updating an operating system package may leave a bundled runtime untouched. Version numbers are also misleading when a vendor backports a fix without changing to the upstream release number. And “Standard” updates, can render a system unusable.
Finding PHP requires way more than ‘What’s installed?’ Teams will likely need to inspect executables, processes, services, containers, application bundles, and vendor-managed devices. They may even need to probe vendors for assurances, or ultimately replace equipment because no determination can be made. Even the most thorough search cannot guarantee they will find every embedded copy.
Beyond the conventional server
Corporate networks contain more than managed servers and employee workstations. NAS appliances, printers, routers, switches, cameras, and other devices may run web components internally. Not all will use PHP, many will, and any device that embeds an affected runtime must be considered. Including IoT in some cases.
Worse still, enterprises often have adequate visibility into endpoints and servers while knowing little about software inside its networked equipment. A scanner might identify an appliance without identifying the vulnerable component in its firmware. Remediation may depend on the manufacturer releasing an update, which we know only if/when notified.
This turns a software flaw into an asset management and supply chain problem. The device remains in service, the vulnerable component remains present, and the organization may have little immediate control over the fix.
The long tail of exposure
Enterprises are used to this, and better equipped to deal with it. Consumers on the other hand seldom are. Someone buys a router or storage device and expects it to keep working.
Even if an update becomes available, the owner must learn about it and install it. Some devices will get updated; others are often forgotten, abandoned, or unsupported. The vulnerability does not simply disappear when media attention moves on. Exposure persists wherever affected software remains deployed and reachable.
What organizations should do right now
Here’s a list of priority items for today:
- Find the runtime: Search beyond package inventories, including containers, application bundles, and appliances.
- Prioritize exposure: Patch public-facing PHP services first, then assess other reachable systems.
- Fix every copy: Update the actual runtime or apply the vendor's fix. Do not assume an application or operating system update covers bundled PHP.
- Limit risk while waiting: Restrict access or isolate systems when patching gets delayed. The project maintainers state there's no complete mitigation substitutes for updating.
- Verify and investigate: Confirm the runtime serving requests are fixed, review telemetry for suspicious activity, and track systems awaiting vendor updates. Attack the system yourself, TEST!
Team need to know what’s affected, what has been fixed, and what remains exposed. The inventory is a guide, not a shield.
PHP2Shell represents the latest example of how widely-embedded foundational components can complicate discovery and remediation. Start by securing known systems. Then find systems missing from conventional inventories, including devices that may remain vulnerable long after the initial response ends.
Patching the systems we know about is the job on the surface – but finding the systems we don't know about makes vulnerability management a continuing discipline.
Gene Moody, Field CTO, Action1
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
