PHP2Shell: the patch is available; the running service still needs proof

On 21 October 2026, the PHP project released emergency fixes for CVE-2026-109618 and CVE-2026-109619. Both can allow remote code execution without authentication under the conditions described in the advisories. The corrected versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says installations serving web requests across PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed should be assessed. It identifies mod_php as the highest-risk configuration because a demonstrated attack can be triggered before application code runs.

Two faults in the runtime, not in WordPress

The first flaw concerns out-of-memory handling. PHP may interrupt a request while internal data is only partly initialised, then treat that data as valid during cleanup. The second concerns request-owned state that survives after its backing memory has been freed. A later request handled by the same worker can encounter that stale state. These are different failure paths with a shared consequence: specially crafted requests may move the server beyond a simple crash into code execution or data exposure.

The vulnerable component is PHP itself. A site built with WordPress, a custom portal or another framework is not automatically proven exploitable merely because it uses PHP; its runtime version, deployment mode and reachable paths matter. Conversely, a secure application review does not substitute for checking the PHP worker beneath it.

What the attack reports establish

Cloudflare says it observed attack traffic aimed at the vulnerabilities and changed its WAF protections as payloads evolved. That establishes attempted exploitation against its customers, not successful compromise of each target. Service outages reported by news organisations may reflect precautionary isolation. They should not be described as confirmed intrusions without evidence from the operator.

A WAF can reduce exposure while teams deploy fixes. PHP says no temporary measure is complete. The UK NCSC advises identifying PHP across infrastructure, prioritising Internet-facing services, updating, and considering a service outage when a safe update or temporary control cannot be applied in time. Such a decision needs the service owner and its continuity plan.

The operational decision for industrial organisations

A PHP-backed supplier portal, maintenance interface or operational dashboard can become relevant to an industrial workflow if it carries credentials, maintenance instructions or access to other systems. That is a dependency to inventory and test, not evidence that a controller or production line has been affected by these CVEs.

For each service, record the deployed PHP branch and package provenance, the server integration, Internet reachability, the owner and the function that would be lost during isolation. Apply the corrected version or a vendor-confirmed backport, then restart or redeploy the affected workers and verify the version they actually load. Confirm that critical authentication, uploads and operational workflows still function. A planned update, package installation record or WAF rule alone does not prove that the running service is fixed.

If compromise is suspected, preserve relevant server, identity and edge records before disruptive recovery. The response then becomes an investigation into what the service could access and what happened during the exposure window. Do not infer a breach solely from a vulnerable version or from Cloudflare's aggregate attack observations.

Related context. CUP's BeyondTrust analysis separates present remediation from retrospective investigation. The SiteGuard analysis addresses evidence preservation alongside emergency patching. Both involve different products, flaws and evidence; neither establishes exploitation of PHP.

Next review event. Revise this analysis if PHP changes the affected or fixed-version guidance, or if an authoritative source reports a verified compromise or a materially different attack condition.