About this briefing

This is RiverSafe’s read on the two critical PHP vulnerabilities patched on 21 October, drawn from the NCSC alert, the vendor advisories and public reporting. It is written for security leadership rather than the engineers already doing the patching.

In brief

• Two flaws in the PHP engine itself allow an unauthenticated attacker to run code on a web server. The application running on top of PHP does not need a defect of its own.
• Details leaked before the coordinated disclosure and exploitation attempts were reported before the fix shipped, so there was a live exposure window that patching does not close retrospectively.
• The challenging part is in knowing every place PHP runs, including inside products that never mention it.

What happened

Where most guidance stops short

Almost everything published restates the NCSC’s first three actions: find your PHP, watch for vendor updates, apply the fix. The seventh action the NCSC recommends is harder. If you cannot update or disable a system immediately, assess it for evidence of compromise and look for attacker-installed backdoors before you upgrade or mitigate.

That exists because of a specific failure mode. Patching removes the vulnerability but it does not remove an attacker who already used it. The scanner turns green, the ticket closes, and persistence established during the exposure window survives in an environment where nobody is looking for it any more.

Questions to ask

1. Do we know everywhere PHP runs? The NCSC is explicit that because all versions may be affected, discovery must not be scoped to outdated PHP. It sits beneath content management systems, shared hosting, control panels and third-party appliances that never mention it. NCSC-NL has published an inventory of affected products carrying a PHP dependency.
2. If we cannot fix something today, who is authorised to take it offline? National government services and local authorities across Europe did exactly that this week. That is a continuity decision, not a technical one. If it has to climb three levels to be made, you have an escalation path, not a control.
3. If we were exploited before we patched, how would we know? Exploitation happens inside the engine, below the application, so application logs carry little context. The signals are unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, unexpectedly large or malformed PHPSESSID response cookies, and unexplained worker churn. No retention across the exposure window is itself a finding.

The wider picture

This is a vulnerability management event with an exposure management lesson. The vulnerable code had been in PHP for over a decade. It was impractical to weaponise and that impracticality was doing the work of a control. Frontier AI models removed it: the research team reports compressing work that would once have taken a world-class team months into roughly a week.

So every finding accepted on the grounds that exploitation was theoretical or too complex rests on an assumption that no longer holds. Severity describes a defect; exposure describes what an attacker can reach and what it would cost them to try. Only the second number moved this week.

Worth checking now

• Complete PHP discovery across the estate, including bundled, inherited and supplier-hosted instances, before counting remediation progress.
• For internet-facing systems unpatched after 20 October, look for persistence before closing the ticket rather than after.
• Ask hosting providers and vendors directly which PHP version they run and when they patched. Standard assurance questionnaires do not cover this.
• Confirm WAF coverage as an interim measure: whether your provider has released rules, whether they are in blocking mode, and whether every PHP-facing service sits behind it. This buys time; it does not replace the upgrade.
• Re-open risk acceptances that relied on exploitation being impractical.

A closing thought

For years, “too complex to exploit” was a reasonable basis for accepting a risk, and many organisations have accepted risks on that basis. These flaws show it can no longer be relied on.
Patching PHP will take days. Reviewing the risk acceptances, scoring and reporting built on that assumption will take longer, and now is a good time to start, while there is a recent example to point to.

Primary sources: NCSC alert Critical security issue affecting PHP; NCSC-NL PHP2Shell software inventory; Wiz Research PHP2Shell disclosure; CERT-EU Security Advisory 2026-018. All 21 October 2026.