What happened
On 21 October 2026 at 14:00 UTC, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, two runtime flaws capable of unauthenticated remote code execution. CVE-2026-109618 concerns out-of-memory corruption during request cleanup, while CVE-2026-109619 concerns stale request-owned state reused by a later request; both can lead to unauthenticated remote code execution. The conditions arise in the PHP runtime and can be reached before normal application logic provides a meaningful security boundary.
Amazon Threat Intelligence identified a PHP2Shell exploitation attempt on 17 October 2026, four days before public disclosure, and subsequently described the vulnerabilities as broadly exploited in the wild. Amazon published 103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 as observed addresses, while warning that shared anonymisation infrastructure makes them investigation leads rather than block-only indicators. Different payloads and anonymisation services led Amazon to assess that multiple operators were involved, although the attempts do not establish successful compromise of production victims.
Supported fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP 5.4 through 8.1 have no upstream fix and require migration or vendor backports. AWS’s temporary detection and mitigation pattern looks for POST requests containing PHP_SESSION_UPLOAD_PROGRESS together with PHPSESSID in a cookie or request body. AWS states that compensating controls are incomplete and that immediate upgrade to a fixed runtime is the complete remediation for supported branches.
On 22 October 2026, New Zealand’s NCSC advised immediate patching and said organisations unable to patch should consider disabling public-facing web services. The UK NCSC separately advised organisations that cannot update immediately to assess systems for evidence of compromise before upgrading or applying mitigations and to look for attacker-installed backdoors rather than treating maintenance completion as incident closure. Attribution posture: Amazon Threat Intelligence assessed that the pre-disclosure honeypot targeting suggested threat-actor activity, but no actor has been identified.
Why this matters now
The exposure is unusually broad because the vulnerable component is the PHP runtime rather than a single application. Internet-facing websites, APIs, content platforms and commercial products may inherit the risk even when application teams did not install PHP directly or control the underlying hosting environment. The highest-risk estate therefore includes supplier-managed systems and forgotten web services, not merely applications already recorded in the vulnerability scanner.
Amazon’s telemetry changes the response model. Organisations that began monitoring only when the advisory became public may have excluded four days of relevant activity. A clean vulnerability scan or successful update does not determine whether an attacker reached the service before remediation, and a restarted or rebuilt worker can erase volatile evidence while leaving attacker-created files, credentials or downstream access paths untouched.
Unsupported runtimes create an executive exception rather than a routine maintenance backlog. Several end-of-life branches have no upstream fix, making application migration, vendor backports, temporary isolation or service withdrawal necessary. Security leaders should require named owners and expiry dates for every compensating control because web application firewalls reduce reachable conditions but do not provide equivalent remediation.
The operational decision spans vulnerability management, application ownership, hosting operations and incident response. The relevant completion measure is not the percentage of servers patched; it is the percentage of reachable PHP services with a known version, confirmed worker restart, reviewed pre-disclosure telemetry and an approved disposition for unsupported systems.
The decision for security leaders
Declare a single enterprise PHP response led jointly by vulnerability management and incident response. Application owners must not close findings solely because package managers report a fixed version; closure also requires confirmation that persistent workers restarted and that relevant telemetry was reviewed from the earliest observed exploitation date.
Separate the estate into supported, unsupported and supplier-controlled services. Supported branches require immediate updates; unsupported branches require isolation or a documented migration and backport decision; supplier-controlled services require written assurance covering runtime version, exposure, restart completion and compromise assessment.
Preserve evidence before destructive remediation where suspicious activity exists. If telemetry shows PHP workers launching shells, interpreters or network utilities, or writing executable files into web roots, move the system into incident handling rather than continuing a standard patch workflow.
Evidence of closure
- Asset inventory identifies every reachable PHP runtime and its accountable owner.
- Version evidence confirms each supported runtime is on a fixed release.
- Process evidence confirms PHP workers restarted after remediation.
- Hunt results cover telemetry beginning 17 October 2026 with documented findings disposition by incident response.
The Security.io assessment
The evidence supports confirmed exploitation attempts and broad scanning, but it does not prove that every vulnerable installation was successfully compromised. The observed addresses include shared infrastructure, so detections should correlate request patterns, worker behaviour, file creation, outbound connections and credential use rather than treating an IP match as dispositive.
The decisive change is the pre-disclosure window. Patching remains urgent, but compromise assessment must begin on 17 October rather than the public advisory date. Environments with incomplete web logs or short retention should document that assurance limitation and compensate with endpoint, network, cloud and application telemetry.
The cited sources did not publish malware file hashes or filenames for the observed PHP2Shell web-request activity. Detection therefore depends on request structure and post-exploitation behaviour, including unexpected child processes, web-root modifications, outbound connections and use of credentials accessible to the affected worker.
Questions for the morning meeting
- Can the asset inventory identify every PHP runtime, including supplier-managed and embedded deployments?
- Which internet-facing PHP services remain on unsupported branches without a complete upstream fix?
- Has incident response reviewed the full period beginning 17 October 2026?
- Can hosting and application suppliers prove both patching and worker restart completion?
- Which business services must be disabled if remediation or compromise assessment cannot finish today?