Where Are We Exposed, and Who Owns It?

On 21 October 2026 the PHP project released fixes for two critical remote code execution vulnerabilities. This paper looks at the first hours of that response from the perspective of enterprise IT leadership, and at what separated the organizations that could act immediately from those that could not.

Key findings

• Two flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619 (known as “PHP2Shell”), allowed an unauthenticated attacker to run code on a server with a crafted web request. The PHP project rated both 9.2 under CVSS v4.0 and stated that updating was the only complete fix.¹
• CISA’s first recommended action was to identify and inventory every system running any version of PHP. It also warned that PHP’s presence “may not be directly observable” because it is often embedded in other software.³
• Vulnerability scanners could not help in the first hours. The CVE identifiers leaked roughly a day before any technical details or affected version ranges were published, so there was nothing for scanners to match.²
• PHP 8.1 and older received no official patched release. Organizations on those versions faced a vendor dependency or a migration rather than a routine update.¹
• Organizations that already maintained a current inventory with named application owners could identify their exposure before the details were public, and began the response by prioritizing work rather than gathering data.

Recommendations

CIOs and the leaders responsible for infrastructure and security should:

• Confirm that every PHP runtime serving web traffic is on 8.2.35, 8.3.36, 8.4.27, 8.5.12, or a vendor-supplied equivalent, starting with internet-facing systems.¹³
• Identify every instance of PHP 8.1 or older and obtain a vendor fix or a migration plan. Where neither is available, follow CISA’s guidance to take the system offline until it can be remediated.³
• Measure how long it takes to produce a complete list of applications and owners for a widely used runtime, and set a target for that number.
• Make application ownership a required and maintained field in the system of record, not an attribute collected during an incident.
• Reconcile data from security scanners, IT asset management, source control, and cloud platforms against the system of record on a continuous basis rather than at attestation time.

1. What happened

On 20 October 2026, two vulnerability identifiers began circulating online with no technical details attached. Within hours the PHP project confirmed that a critical security release was coming and brought it forward by a day. The fixes were published at approximately 14:00 UTC on 21 October.

The flaws, CVE-2026-109618 and CVE-2026-109619, are widely referred to as “PHP2Shell.” Both affect parts of the PHP engine that nearly every request touches: memory management and error handling.² The PHP project listed every installation serving web requests as at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed, and identified mod_php as the highest-risk configuration.¹

At the time of release, the PHP security team had not identified a functional public exploit and CISA had not observed exploitation.²³ The guidance was nonetheless direct. CISA advised organizations that could not update immediately, or that were running PHP 8.1 or earlier, to take PHP-based systems offline until they could be patched.³

PHP runs a large share of the web. Inside a large enterprise it also turns up in places few people remember: an internal portal, a vendor product, a marketing site, a tool someone stood up years ago and left running. For most IT leaders, the engineering problem belonged to the PHP project. Their own problem started with a simpler question.

2. The first question: where are we exposed, and who owns it?

Before an organization can patch, isolate, or brief its board, it needs to know which applications run PHP, which versions, whether they face the internet, and which team is accountable for each one. CISA’s first recommended action was exactly that. It also cautioned that PHP “is often a component of other software and prevalence may not be directly observable.”³ The EU joint statement made the same point, noting that some products may be affected “even if they do not appear to use PHP directly.”⁴

In many organizations, nobody can answer that question quickly. The usual sequence is familiar. Security sends a note to a broad distribution list. Someone exports a CMDB report and someone else pulls scanner results. Application teams are asked to complete a spreadsheet. Answers arrive over Teams and email in different formats and with different levels of confidence, and ownership fields point to people who changed roles two reorganizations ago.

This time there was little room for that. According to the PHP Foundation, coordinated disclosure held until two days before the planned release, when the leak forced the schedule forward and proof-of-concept work accelerated.² Teams still running PHP 8.1 or earlier had a harder problem still: no official release, only source-level backports or a vendor’s own fix, and in most cases a migration.¹

The people doing this work are rarely short of effort. What they lack is a current picture of their own estate, so they assemble one by hand during the emergency itself.

3. Why scanners are the last to know

Scanners have a timing problem of their own. A scanner can only find what it has been told to look for, and three things have to happen before it knows:

1. The vulnerability details have to be published. On 20 October the identifiers were circulating, but there were no technical details, no affected version ranges, and nothing to match against.
2. Scanner vendors have to add detection. Each vendor writes, tests, and ships detection logic for the new CVE on its own schedule.
3. The scan has to run. A full cycle has to complete across applications, servers, containers, and code, and someone has to triage the results.

Between “a critical vulnerability exists” and “the scanners report where we are exposed,” organizations should expect hours at best and sometimes days. A scan run on the first day simply comes back clean.

Attackers are working through that same gap. An additional scanner would be silent during it too. What helps is an existing record of what the organization runs and where, assembled from its scanners, code repositories, infrastructure, and system of record. An organization that already knows every application running PHP, its version, and its owner can begin acting on the day the identifiers leak.

4. What a current inventory changed

Some organizations started from a different position. DevGrid customers, including a top-25 U.S. bank, already had a reconciled view of their technology estate. When word of the PHP release spread, and before the vulnerability details were public, they could answer the first question directly.

At the bank, the answer took a small number of lookups. DevGrid already consolidates data from the bank’s security scanners and IT asset management (ITAM) tools into a single inventory, so those lookups returned every PHP instance across the estate in one place. Nobody had to circulate a spreadsheet, merge exports from different tools, or wait for a scanner update.

“

We were able to just ask the system for the data and get it back in seconds. I don’t even know where we would have started before. This is why we procured DevGrid as part of our Mythos response strategy.

Technology leader, top-25 U.S. bank

“Mythos” refers to Claude Mythos Preview, the AI model Anthropic announced in April 2026. Anthropic reported that it had found thousands of high-severity vulnerabilities, including some in every major operating system and web browser.⁶ Reuters reported expert warnings that AI-assisted attacks could have serious consequences for banks running legacy technology.⁷ If AI continues to shorten the time between a flaw being found and being exploited, a manual inventory exercise will become more costly with each incident.

Source: DevGrid. Illustrative example from a demonstration environment.

When the affected versions were published, those teams already had the inventory and only needed to filter it. The first meeting could begin with the order of work: internet-facing applications first, then a plan for end-of-life instances, with a named owner for each.

PHP rarely appears in a single record

A runtime such as PHP can appear as an installed runtime detected by asset tools, as an operating system package on a Linux server, inside a container image, bundled within a vendor product, or as a similarly named entry in a code dependency list that is not the language at all. Each source sees part of the picture, and the sources often disagree. A list of software names from any single tool will be both incomplete and noisy. The useful version ties each signal to an actual application, an actual version, and the person responsible for it.

5. Preparing for the next one

The organizations that answered quickly in October had done most of the work months earlier. Three practices mattered most:

1. The inventory was kept current. Records changed when code shipped and infrastructure changed, not once a year during an attestation cycle.
2. Every application had an accountable owner, so the question of whom to call already had an answer.
3. Vulnerability and end-of-life data sat alongside the inventory. Teams on PHP 8.1 or older learned in October that no official release was coming for them. Those versions are a migration project, which is far easier to plan before an emergency than during one.

Where that information lives also matters. In most large enterprises, the CMDB is the system of record, and it should remain so. A separate inventory that nobody reconciles would add to the problem. The objective is to keep the system of record accurate, with application, version, and owner data flowing back into it.

Questions for leadership teams

• If a critical vulnerability were disclosed in a common runtime tomorrow, how long would it take to list every affected application and its owner?
• How reliable is that list? Where does it come from, and when was it last verified?
• Which applications run end-of-life software with no vendor fix available?
• Does the CMDB match what is actually running in production?

If the honest answer to the first question is measured in days, that is the gap to close before the next disclosure.

About DevGrid

DevGrid builds and maintains a live map of an organization’s technology estate. It connects to existing tools, including source control, security scanners, ITAM platforms, cloud providers, and the CMDB, reconciles them into a single model, and ties technology, vulnerability, and end-of-life data to each application and its owner. The CMDB remains the system of record; DevGrid keeps it accurate.

To see what this looks like for your own estate, request a walkthrough.