What happened
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for CVE-2026-109618 and CVE-2026-109619. The PHP advisories rate both issues critical and state that they can permit unauthenticated remote code execution as the web-worker account. CVE-2026-109618 concerns remote code execution through out-of-memory corruption; CVE-2026-109619 concerns stale request-owned global state reused by a later request.
PHP states there are no complete mitigations and that updating is the only safe choice. The UK NCSC advises organisations unable to remediate immediately to consider taking affected systems offline. A public proof-of-concept repository identifies multipart/form-data requests as the delivery path and lists the same fixed versions. The cited authoritative sources did not report active exploitation.
Unsupported PHP 8.1 and older installations need distribution or long-term-support backports rather than a PHP Project release. Teams must also check appliances, containers and managed services that bundle PHP because updating a host runtime does not prove embedded copies are fixed. Attribution posture: The PHP and NCSC advisories name no actor, and no malicious campaign has been established in the cited sources. The cited source did not publish the specific operational detail described as Active exploitation was not reported by the cited authoritative sources.
Why this matters now
The decision changed from advance preparation to active emergency deployment when PHP published fixed releases and full technical advisories. These weaknesses operate in core request handling before normal application controls can provide reliable protection, so application authentication, plug-in hardening and ordinary code review do not remove the underlying runtime exposure.
PHP is present beyond conventional websites. It may be embedded in appliances, packaged applications, containers, hosting platforms and managed services where the enterprise cannot directly replace the runtime. Security leaders need parallel workstreams for assets they control and supplier-managed products, with explicit isolation decisions where neither a fixed package nor adequate assurance is available.
Public proof-of-concept material reduces the value of delaying until exploitation telemetry appears. However, patch completion alone cannot answer whether a previously exposed service was targeted. Internet-facing systems require log preservation, process and file review, and incident escalation when evidence shows unexpected child processes, outbound connections or altered web content.
The decision for security leaders
Separate directly controlled runtimes from supplier-managed exposure. Infrastructure teams can update known servers, while vendor management must obtain evidence for appliances, managed platforms and applications carrying private PHP builds.
Approve isolation or service withdrawal where neither a fixed release nor an authoritative backport is available. Temporary configuration changes should be documented as risk reduction, not accepted as complete remediation.
Require compromise assessment for materially exposed services. Prioritise systems with sensitive data, privileged service accounts, writable web roots or network paths into internal applications, even after successful patch deployment.
Evidence of closure
- Runtime inventory records fixed, isolated or approved-disposition status for every discovered PHP instance.
- Deployment evidence shows supported systems running only PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
- Supplier attestations identify fixed versions for each appliance, platform or packaged application containing PHP.
- Investigation records document a compromise disposition for every materially exposed pre-remediation system.
The Security.io assessment
The technical evidence establishes credible unauthenticated RCE and complete vendor fixes. Public proof-of-concept availability supports an accelerated response, but the cited authoritative sources do not yet establish active exploitation or a specific campaign.
The widest operational gap is likely to be embedded PHP rather than inventoried web servers. Appliance and SaaS owners may depend on supplier updates, and host-level package scans can miss runtimes packaged inside containers or application directories.
Closure requires two separate conclusions: every in-scope runtime is fixed or isolated, and every materially exposed system has an evidence-based compromise disposition. Reporting a high patch percentage without resolving unknown embedded copies is not decision-grade assurance.
Questions for the morning meeting
- Does the asset inventory identify every directly managed, containerised, embedded and provider-managed PHP runtime?
- Which internet-facing PHP services cannot receive a fixed release within the emergency window?
- Can owners prove that appliances and managed platforms updated their bundled PHP copies?
- Are response teams prepared to distinguish successful patching from evidence of pre-patch compromise?