When CISA, the FBI and the UK NCSC issued guidance on PHP2Shell, all three told organizations to find where PHP runs. CISA's alert opened by urging immediate patching, but the first item on its action list was to identify and inventory every system running any version of PHP. That ordering says something. You cannot patch what you have not found, and CISA warned that PHP is often a component of other software whose presence may not be directly observable.
The question sounds trivial until you try it. Your web team knows which servers host the marketing site. Nobody on that team is likely to know which appliances, consoles and vendor portals ship their own copy of the runtime. A copy bundled by a vendor may not show up in your centrally managed package inventory, and a given vulnerability scanner may not identify it either. Whether you can see it depends on the product and how it is deployed. A vendor's software bill of materials can help identify bundled runtimes, if you have asked for one, but you still have to check how complete it is, which versions it covers and how deep its dependency list goes.
This post argues that knowing which runtimes live inside the products you buy is a security operations capability. It is built before the emergency, owned by someone, and tested like any other response procedure. What follows is what the advisories said, where exploitation actually landed, and how to build an inventory that answers in hours rather than weeks.
What PHP2Shell Actually Was
CISA's alert urged organizations to immediately patch the recently disclosed critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, known as "php2shell." According to the alert, they allow unauthenticated remote code execution and affect all PHP installations serving web requests. CERT-EU, the cybersecurity service for the EU institutions, reported that the PHP team released the fixes on October 21, 2026, in PHP versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and that both vulnerabilities can allow unauthenticated remote code execution. In plain terms, someone with network access to a vulnerable PHP service, and no credentials, could run commands on the machine.
Two measures matter here, and they answer different questions. The first is CVSS, the Common Vulnerability Scoring System, which rates severity from 0 to 10. Palo Alto Networks' advisory covers both flaws and rates CVE-2026-109618 critical, with a score of 9.2 under version 4.0 of that system. The second is CISA's KEV catalog, short for Known Exploited Vulnerabilities. An entry there means exploitation has been observed in the wild, which is a different claim from a high score. On October 26 CISA added both vulnerabilities to the catalog.
The PHP release notes were unusually blunt. "There are no complete mitigations, updating is the only safe choice." CERT-EU said the same thing in its advisory, that only an update fully fixes these vulnerabilities. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older are end of life, so the answer there is to move to a supported release.
We are not going to describe how the flaws work. You do not need that to do your job.
The First Action Item Was Find Your PHP
CISA, the FBI and the UK NCSC all made inventory part of their guidance. CISA told organizations to inventory all systems running any PHP version, including PHP embedded in other software, and to patch internet-facing systems first. Its alert covered every common way PHP serves web requests, including Apache with mod_php, PHP-FPM (the FastCGI Process Manager), php-cgi, FrankenPHP and LiteSpeed. The FBI asked for the same inventory, prioritizing internet-facing systems and vendor products that bundle PHP. The UK NCSC made identifying PHP systems the first of its priority actions, starting with internet-facing systems, and said not to limit discovery to outdated PHP versions.
Why is this harder than it sounds? Three reasons.
First, ownership is split. Web servers belong to one team, network gear to another, and appliances to whoever signed the purchase order. Nobody holds the whole map.
Second, the tooling answers a different question. A vulnerability scanner reports what it can fingerprint from the network or from an agent. An asset database reports what someone registered. Neither reliably says which products carry a language runtime inside them.
Third, the clock. The advisories called for immediate action. If your process is to email vendors and wait, you are working at the speed of their support queues while the vulnerability is already on the KEV list.
Where the Exploitation Showed Up
The most instructive confirmed case was not a website. Palo Alto Networks' own advisory, last updated October 29, says active exploitation has been observed targeting its management interface where that interface is exposed to the internet. The affected product is PAN-OS, the operating system of Palo Alto Networks firewalls.
To be fair to the vendor, Palo Alto Networks says the management interface is not exposed to the internet by default. It states that approximately 0.02 percent of its global installed base had internet-facing management interfaces and was impacted, and that customers who applied the available patches are not affected.
The lesson is not about one vendor. It is that a security product, bought to reduce risk, carried a general purpose web runtime in its management plane. Few buyers would have listed that firewall as PHP exposure, because nothing told them it belonged there.
A useful test for your own inventory. Ask it for every system where the runtime is present, then sort the answer by whether the system is reachable from the internet and by who can patch the runtime. A good result is a short table with a product name, a version, an exposure flag, a named owner and the vendor advisory link. An illustrative row would read firewall management interface, runtime present through vendor, management port reachable from outside, owner network engineering, fix pending vendor release. If your query cannot produce that row, the gap is in the data, not the analyst.
Websites Are the Easy Part
If you run PHP applications on servers you control, you can find them and patch them. It is work, but it is your work. The harder population is everything else.
NCSC-NL, the Dutch government's national cybersecurity agency, publishes a repository that tracks this directly. It describes PHP as embedded in appliances, network devices, management interfaces and other vendor products, where administrators may not be able to patch it themselves. As of November 2, 2026 it tracks 930 products. Of those, 215 are vulnerable, 167 are fixed, 93 are under investigation, 240 are runtime-dependent, 214 are not affected and 1 is unknown. Those figures change as vendors respond, so date any number you quote from it.
Look at the shape of that list. The vulnerable bucket is not the only one that matters. Ninety-three products were still under investigation, and 240 depend on how the runtime is supplied and configured. CERT-EU made the same point, that products using PHP as a backend could be affected even if they do not directly expose a PHP installation.
For these systems, your control is not a patch. Your control is what you know, how fast you know it, and where the device sits on your network.
Building an Inventory That Answers Where a Runtime Lives
The goal is one query. Name a component, get every system carrying it, with an owner. Four layers get you there.
Start with hosts and containers you run. Scan servers for installed runtimes and their web server integrations, and scan container images in your registry, not only the ones currently running. Images that are not deployed today may be deployed next week.
Then ask vendors for SBOMs. An SBOM, or software bill of materials, is a machine-readable list of the components inside a product. SPDX, the Software Package Data Exchange, is one standard format for it, and NCSC-NL itself maintains its product inventory as SPDX files. Request an SBOM for every appliance and bundled product, and store them where you can search them.
Third, assign an owner per product. Not per team, per product. When an advisory lands, the owner is the person who calls the vendor, checks exposure and reports status. A product without an owner is a product nobody is checking.
Fourth, record exposure. For each system, note whether any management or web interface is reachable from the internet, from the corporate network only, or from a dedicated management segment.
The discipline that makes this work is the join. SBOM component data, host scan results and your asset database need a shared product identifier, so that one component query returns every system carrying it. Build that join once, and the next runtime vulnerability is a query instead of a project.
Management Interfaces Belong Off the Internet
The PAN-OS exploitation comes down to reachability. It targeted management interfaces that were exposed to the internet, and the vendor's own numbers say that was a small fraction of devices.
A management interface should be reachable only from a dedicated management network or through a controlled access path, with an allow list of administrator sources. That is a standing architecture decision and a security engineering task, not an incident step. Run an external scan of your own address space on a schedule, and treat any administrative service that answers as a finding with an owner and a due date.
The sharpest risk is the appliance whose runtime you cannot see and cannot patch, sitting on a management port that answers from the internet. You have no scanner finding, no package to update and no vendor fix on your timeline. Decide now who has authority to take that device offline, because the advisories said to do exactly that when you cannot update immediately.
When You Cannot Patch, Assume You Need to Look
CISA and the FBI both said to take PHP systems offline if you cannot update right away, and CISA said the same for anything running PHP 8.1 or earlier. The UK NCSC added that if you cannot update or disable a system immediately, you should check it for signs of compromise and backdoors.
So plan for the case where the vendor fix is not ready. Taking a firewall management plane or an appliance offline has a business cost, and that decision belongs to a named person before the day arrives.
For detection, CISA's guidance was to monitor for PHP worker processes launching shells or downloading tools, and it added a Sigma detection rule to its alert on October 23. Sigma is an open, shareable format for describing suspicious log events, and its rules can be converted to run in many SIEM (security information and event management) products. The FBI asked for the same process monitoring on web servers. Appliances are harder. Some give you limited process telemetry and some give you none, so what evidence you can collect depends on the product. Often it comes down to network logs and whatever the device retains.
If you do find compromise, the FBI's instruction is to isolate the system, preserve web server and PHP logs, and report to your local FBI field office or ic3.gov. Preserve before you rebuild. Collecting those logs before anyone reimages the device is where forensic triage earns its place.
What to Ask Your Vendors Before the Next One
Much of the scramble was decided at procurement. Put these questions into contracts and security questionnaires.
Ask the vendor to disclose the runtimes and major components inside the product, and to notify you when that list changes. Ask for an SBOM at delivery and at each major release, in a format such as SPDX. Ask for a stated timeline for security advisories on third-party components, including whether they will contact you or you must go looking. Ask whether the management interface is off the internet by default and what it takes to keep it that way.
The answers also tell you which vendors to worry about. One that cannot say what is inside its product has told you something.
If you want a second pair of hands, we help teams develop incident response programs, and an emergency patch procedure fits inside one. Our engineers handle detection engineering and network security design. Our network penetration testing can show which of your systems are reachable from outside and what an attacker could do with them. When you suspect a compromise, we offer compromise assessments and forensic evidence collection.
Related Service
Learn more about how we can help with Security Operations.
Explore Security Operations Services →There will be another runtime vulnerability, and its advisory will probably ask the same first question. Make sure your answer takes an afternoon, not a month.
