PHP2Shell: the patch is out, the inventory is the hard part

Two critical flaws in the PHP runtime can be used to take control of a web server without logging in. The PHP project shipped fixes on 21 October 2026, and national cyber agencies say any system that cannot be fixed should be considered for taking offline. Here is what is confirmed, what is still disputed, and why the first job is knowing where PHP runs.

What happened

At 14:00 UTC on 21 October, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These releases fix two vulnerabilities that “can allow unauthenticated remote code execution”, and the project told all users to “update immediately”.

The flaws are tracked as CVE-2026-109618 and CVE-2026-109619. Each carries a CVSS v4.0 base score of 9.2, rated Critical. Researchers have nicknamed them “PHP2Shell”. The PHP project does not use that name.

The release followed a short and disorderly lead-up. Claims about the flaws spread on social media on Monday 19 October, ahead of a coordinated disclosure that had been planned for later in the week, according to Upwind and The Next Web. On Tuesday 20 October, PHP gave advance notice of a security release and reserved the right to ship earlier “should details of either vulnerability become public, or should evidence of active exploitation appear in the wild”. CERT-EU, which protects EU institutions, published advisory 2026-018 the same day.

What the flaws are

Both flaws sit in the PHP interpreter, not in any one application. Updating WordPress, Drupal, Magento, Laravel or a plugin does not fix them, as Cloudflare and Patchstack both point out.

• CVE-2026-109618 (RCE via out-of-memory corruption). Out-of-memory handling can interrupt PHP while internal request data is only partly initialised. Request cleanup may then treat that invalid data as valid.
• CVE-2026-109619 (RCE via stale global state). Internal state that belongs to one request can survive after its memory has been freed. A later request handled by the same worker may then use it.

PHP says every installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where “an unauthenticated request can trigger the attack before any application code runs”. The GitHub advisories credit researchers including teams from Wiz and OpenAI. Cloudflare also credits Calif.io and Quarkslab.

The CVSS vector marks attack complexity as high and lists attack requirements as present. That is one reason the score is 9.2 and not 10. It is no reason to wait. Exploit material was circulating before the patch existed.

Who is saying what

Government guidance has been unusually blunt.

• UK NCSC: Organisations should identify all PHP installations, “prioritising internet-facing systems”. Where updates or mitigations cannot be applied quickly, they should “consider taking the system offline until it is fully mitigated”.
• CERT-EU: “CERT-EU strongly recommends identifying PHP-based applications and preparing to patch.” Where that is not feasible, organisations should “consider isolating internet-facing applications from public networks until a fix can be applied”.
• Australia’s ACSC: Said it was “not aware of active exploitation” at the time, according to The Next Web.

Industry accounts of exploitation do not agree:

• Patchstack reported “multiple active exploitation incidents confirmed” at 07:34 UTC on 21 October, before the patch shipped.
• Cloudflare said it “observed attack traffic”, with attackers “mutating the attack payload to try to bypass our protections”. It switched on WAF rules for all plans, including free accounts, at 03:02 UTC. Its chief technology officer, Dane Knecht, called these rules “a STOPGAP only”, as quoted by Tenable.
• watchTowr said no exploitation in the wild had been reported, and noted that neither CVE was in CISA’s Known Exploited Vulnerabilities catalogue when it last updated its analysis.

A fair reading is that targeted attack attempts began before the fix. Mass exploitation has not been confirmed by a government agency. History suggests it will follow. Three earlier PHP flaws are already in the KEV catalogue: CVE-2012-1823, CVE-2019-11043 and CVE-2024-4577. Two of these have been linked to ransomware, according to Tenable.

Why this one is broad

PHP is used by 69.3% of websites whose server-side language is known. That figure counts websites. It does not count the PHP that has no website of its own, bundled inside appliances, vendor products and management consoles.

Hal Pomeranz, a computer forensics expert, said there are “so many embedded installations out there that will never be patched”, as quoted by Help Net Security. The NCSC tells organisations to track vendor updates for any software with a PHP dependency. It points to an inventory of potentially affected products published by NCSC-NL.

Then there are older versions. PHP 8.1 and earlier receive no updates from the PHP project. The project has published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and long-term support (LTS) vendors provide their own fixes. PHP 8.2 itself reaches end of life on 31 December 2026, so patching 8.2 now buys about ten weeks.

What to do

PHP’s guidance is clear that “only an update is a complete solution”. In order:

1. Find it. List every internet-facing system running PHP, including those run by suppliers on your domains and appliances that bundle it.
2. Update it. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a vendor-backported package.
3. Reduce exposure where you cannot update yet. Apply PHP’s interim measures: an administratively enforced memory_limit=-1, a conservative post_max_size, and session.upload_progress.enabled=0, with every worker restarted. PHP states that these “do not make an installation safe”.
4. Isolate what you cannot fix. Follow NCSC and CERT-EU advice and take those systems off the public internet.
5. Assume earlier contact. Exploit material circulated before the fix. Check unpatched systems for signs of compromise and backdoors.

Our view

Step 2 is where the attention goes. Step 1 is where organisations lose the time.

The main web estate is usually known, owned and patched first. The systems that stay vulnerable for months are the ones nobody owns, such as a 2019 campaign microsite, an agency-built portal, a supplier-hosted page on a forgotten subdomain, or an appliance console nobody logs into. An asset that is not in the inventory is not in the patch plan.

Earlier this year Ollie Whitehouse, the NCSC’s chief technology officer, warned that AI tools in skilled hands are making it more likely that vulnerabilities will be found and exploited at scale. He urged organisations to “prepare now for when a ‘patch wave’ arrives”, starting with systems exposed to the internet. PHP2Shell, two critical flaws in a runtime that much of the web relies on, is an early test of that readiness.

What this week looks like inside Namespace Command

An illustration, not a customer case study. It sets out how Namespace Command’s documented capabilities apply to this event.

Before the news broke. Namespace Command discovers an organisation’s internet-facing estate from the outside, with nothing to install, and keeps monitoring it. Its Technologies surface lists the technologies detected across that estate and tracks their versions. Domains, DNS zones, suppliers and their individual services can each have a named, verified owner. So the question “where do we run PHP?” already has a starting point before anyone asks it.

Tuesday 20 October: the advance notice. Technical details are not yet confirmed. A security team can still run Impact Search for PHP: one query across every discovery surface, with hits grouped by surface and type of evidence. An AI assistant can run the same search through Namespace Command’s MCP tools, and another agent can run it over A2A. The result is a working list of where PHP is visible on the estate. That list includes supplier-run services and assets the organisation never registered.

Wednesday 21 October: the CVEs are published. Dependency Signals matches newly published CVEs against the technologies actually detected in the estate. It adds exploitation context from KEV and EPSS as that context becomes available. The drill-down shows which products, vendors and domains are affected. The dependency lookup tool goes from CVE-2026-109618 straight to the affected assets and suppliers. Where a supplier runs the affected service, Vendor 360 shows how many of the organisation’s domains depend on that supplier and who owns the relationship.

The days after. Owners are already assigned at domain, zone and supplier level, so each affected item has an accountable name next to it. As patches go in, change monitoring and comparisons between assessments give a dated record of how the detected estate changed.

What it does not do. Namespace Command sees what the internet sees. It does not patch servers, look at internal systems that are not exposed, or detect compromise on a host. Its job is the step the NCSC and CERT-EU both put first: knowing where PHP runs, and who is accountable for it.

The takeaway

The useful measure this week is not how fast you patch. It is how long it takes to answer one question with evidence: where are we running PHP, and who owns each instance? If that answer takes days, the weakness is not in PHP. It is in what you can see of your own internet-facing estate. That inventory needs to exist before the next critical CVE lands, not during it.

Govern your namespace.

Sources

1. PHP Group, “PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Released” and security release advance notice, 20 to 21 October 2026. php.net
2. PHP Group, GitHub Security Advisory GHSA-w8hw-w9fx-j79w, “RCE via OOM corruption” (CVE-2026-109618), 21 October 2026. github.com
3. PHP Group, GitHub Security Advisory GHSA-6wmf-4rv5-p3rp, “RCE via stale global state” (CVE-2026-109619), 21 October 2026. github.com
4. Upwind, “PHP2Shell: Two Critical Unpatched PHP RCEs (CVE-2026-109618 & CVE-2026-109619)”, 21 October 2026. upwind.io
5. The Next Web, “EU cybersecurity team says unpatched PHP sites may need to go offline”, 21 October 2026. thenextweb.com
6. CERT-EU, Security Advisory 2026-018, “Critical Vulnerabilities in PHP”, 20 October 2026. cert.europa.eu
7. Cloudflare, “Cloudflare deploys protections against php2shell vulnerability”, 21 October 2026. blog.cloudflare.com
8. Patchstack, “Major security alert: PHP vulnerable to critical RCE, attacks ongoing”, 21 October 2026. patchstack.com
9. National Cyber Security Centre (UK), “Critical security issue affecting PHP”, 21 October 2026. ncsc.gov.uk
10. Tenable, “php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions”, 21 October 2026. tenable.com
11. watchTowr, “PHP RCE FAQ: PHP2Shell CVE-2026-109618 & CVE-2026-109619”, updated 21 October 2026. watchtowr.com
12. W3Techs, “Usage statistics of PHP for websites”, accessed 21 October 2026. w3techs.com
13. Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!”, 21 October 2026. helpnetsecurity.com
14. The Record, report on the NCSC’s “patch wave” guidance, 1 May 2026. therecord.media
15. Klarvant, Namespace Command product documentation.