PHP2Shell: Am I Affected? A Practical Guide for Product Producers and Asset Owners

On October 21, 2026, the PHP project shipped emergency fixes for PHP2Shell, two critical flaws that let an unauthenticated attacker run code on almost any PHP web server. Within hours, two questions were landing in security inboxes everywhere: Are we affected? and Are our suppliers affected?

Patching is the fix. But you can only patch what you know you have, and PHP rarely sits in plain sight. It ships inside appliances, device web consoles, management portals, container images and third-party software. This article explains what PHP2Shell is, why its impact reaches far beyond public websites, and how a Software Bill of Materials (SBOM) and VEX workflow turns "are we affected?" from a days-long hunt into a question you can answer in minutes, whether you build products or operate them.

What is PHP2Shell?

PHP2Shell is the name for two vulnerabilities in the PHP runtime itself, not in any application built on it. Both are rated 9.2 on CVSS v4.0 and both can lead to unauthenticated remote code execution. They were found by Wiz Research, Calif and OpenAI, and the underlying code had been in PHP for more than a decade (The Hacker News).

Because the flaw is in the engine, even a "Hello World" page on a vulnerable version can be attacked. Every PHP installation that serves web requests is in scope: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache mod_php carries the highest risk: a demonstrated exploit fires on a single unauthenticated request before any application code runs (PHP advisory).

Two details matter for anyone checking exposure. First, Linux distributions and LTS vendors received patches early and backport the fix into the PHP version they already ship. The upstream version number stays the same, but the distributions usually add their own patch-level revisions to the package versions. A check against upstream version numbers alone would flag these patched packages as vulnerable. Second, updating WordPress, Laravel or any application does not update the PHP runtime underneath it.

Why the impact is so wide

PHP2Shell combines a huge install base, no authentication and a fix that only works once the runtime itself is replaced. The consequences are already visible:

The hardest part is the long tail. As forensics expert Hal Pomeranz put it, there are "so many embedded installations out there that will never be patched." PHP runs the web interfaces of network appliances, test and measurement equipment, industrial HMIs, building controllers and on-premises management software. Many of these bundle an old PHP branch that will never get an official release, and the people who operate them often cannot see inside them.

The real problem: "Are we affected?"

The patch is public; the hard part is knowing where PHP lives. That question looks different depending on which side of the supply chain you are on.

Both sides need the same two things. An SBOM lists every component and version inside a piece of software, so "do we contain PHP 8.3.30?" becomes a search. A VEX (Vulnerability Exploitability eXchange) statement says whether a known vulnerability actually affects a product, with a status of Not affected, Affected, Fixed or Under investigation. It is what producers send so customers do not have to guess.

The sections below show how teams can run this workflow in Keysight SBOM Manager. The same steps apply to any mature SBOM practice; the value of a platform is doing them in minutes rather than days.

producer and asset owner workflows · joined by VEX

Producers turn SBOMs into a product-level VEX; asset owners check independently and import that VEX to confirm real exposure.

If you build products: find the blast radius, report, then publish VEX

When customers start asking about PHP2Shell, a producer's goal is a clear, evidence-backed answer for every product, sent before the questions pile up.

For producers selling in the EU, PHP2Shell also starts a regulatory clock. Since September 11, 2026, Article 14 of the EU Cyber Resilience Act (CRA) requires manufacturers to report any actively exploited vulnerability in their products once they become aware of it. This includes flaws in third-party and open-source components such as PHP, and products already on the market. Exploitation attempts are already reported, and both CVEs are expected to be added to CISA's Known Exploited Vulnerabilities (KEV) catalog and the EU's exploited-vulnerability list (EU KEV), which removes any doubt that they count as actively exploited.

Reports go through ENISA's Single Reporting Platform to the coordinating national CSIRT and ENISA. The CRA also requires informing affected users, which is where VEX comes in. The 24-hour window is the reason the steps below have to take minutes, not days.

  1. Get an SBOM into the platform. If you already produce SBOMs (CycloneDX or SPDX), import them. If you don't, upload the firmware or software binaries and SBOM Manager generates the SBOM for you, identifying embedded components such as PHP and their exact versions, even when no source code or build manifest is available.
  2. Let the vulnerability mapping run automatically. On ingestion, every component is matched against known vulnerabilities. For projects already in the platform, there is nothing to start: when CVE-2026-109618 and CVE-2026-109619 were published, affected projects were flagged and you were notified. Keysight SBOM Manager detects the full distribution package version, including this patch-level information, not just the upstream version, so backported fixes are recognized correctly.
  3. Search the CVE and see the blast radius. Search for either CVE ID and, in seconds, see every project and version that contains a vulnerable PHP. This replaces the spreadsheet round of asking each engineering team "do you use PHP?"

  1. Assess and record your verdict. For each hit, decide whether it is exploitable in your product. A component can be present but not reachable, for example PHP used only by an offline build tool rather than a web-facing interface. Record the status and justification.
  2. Generate VEX once, at project or product level. A product is often made of several projects: firmware, a web UI, a management service. You can generate VEX for a single project, and it is automatically applied to every product that includes that project. Or you can generate it at product level if it’s applied to specific products only. Either way, there is no need to repeat it for each version of a project or product, so one assessment scales to the whole portfolio your customers actually buy.
  3. Report actively exploited vulnerabilities under the CRA. For affected products, start the actively exploited vulnerability reporting workflow in SBOM Manager. It carries the product, component and CVE context from your assessment into the 24-hour early warning, the 72-hour notification and the final report, and tracks each deadline so none is missed.

  1. Share VEX with customers through the platform. In SBOM Manager, you can invite your customers into the platform and link them to the products they bought. From then on, whenever you commit a product SBOM or generate VEX, those customers get access to it automatically, with no files to send to each one. Access follows the product, so only the customers who bought it see its VEX, not your whole customer base. Because sharing happens inside the platform rather than by email or another tool, there is no middleman handling the data. Customers get a machine-readable answer they can import into their own tools, it supports the CRA duty to inform affected users, and your support team gives one consistent answer instead of dozens of ad-hoc replies.

As you release patched versions or mitigations, submit the CRA final report within 14 days of the fixes becoming available, update the status of fixed versions to Fixed, and reissue the VEX so customers can track remediation progress without having to ask again.

If you operate assets: check independently, then ask your vendors

Asset owners should not have to wait for every supplier to respond before knowing their exposure. The aim is to form your own view first, then confirm it with the vendor.

  1. Generate SBOMs for what you run. Upload the binaries or firmware of the products in your environment and SBOM Manager produces an SBOM for each. This works for vendor products you have no source for, which is exactly where embedded PHP hides.
  2. Bring in vendor SBOMs. Use vendor management to request SBOMs from suppliers and let them upload directly. Each SBOM is stored and tracked against the supplier and product it belongs to.
  3. Map vulnerabilities independently. Once SBOMs are in, the same automatic mapping runs on your side. Search CVE-2026-109618 or CVE-2026-109619 to see which of your assets contain a vulnerable PHP, without waiting on anyone.
  4. Send a VEX inquiry. For each flagged product, ask the vendor for a VEX statement through vendor management.
  5. Import VEX and prioritize. Imported VEX shows components that are present but not exploitable, so your team can focus on assets that are truly affected: patch, isolate, or take offline.

This combination matters. Your own SBOM-based check tells you where PHP is; the vendor's VEX tells you whether it is exploitable. Together they give a defensible answer for auditors and leadership.

Quick-start checklist

Whatever tools you use, these steps get you from headline to answer:

PHP2Shell is not the last vulnerability of this scale. It is not even the last one this month. Within days of its release, more critical flaws surfaced in components buried deep inside other software:

The pattern is the same each time: a flaw in a shared component, inherited by thousands of products that never chose to expose it. Researchers note that AI tools helped turn PHP2Shell's decades-old flaw into a working exploit in about a week, so this pace is likely to continue. Teams that already know what is inside their software will answer "are we affected?" in minutes. Keysight SBOM Manager is built to make that the normal case for both producers and asset owners.

Sources

Related Content

SBOM Manager
What the Best SBOM Solution Should Deliver
How to Ensure SBOM, Accuracy, Quality, and Compliance
limit
3