Executive summary
The US Cybersecurity and Infrastructure Security Agency (CISA) added PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalogue on 26 October 2026. PHP had released fixes on 21 October for defects involving out-of-memory handling and request state retained across worker reuse. The PHP project urges all users serving web requests to update, while identifying Apache mod_php as the highest-risk demonstrated configuration. We assess that verifying the running web workers, distribution packages and deployment images is likely (B2) to be essential to reliable remediation, because PHP documents multiple serving environments and Ubuntu supplies fixes under backported package versions.
What changed this week
The Canadian Centre for Cyber Security's updated PHP alert records the move into CISA's catalogue. This changes the operational framing from a severe disclosed vulnerability to a vulnerability with evidence of exploitation. The catalogue does not establish that every deployment configuration has been exploited, nor does its inclusion identify an actor or campaign for an individual organisation's incident.
PHP's 21 October announcement names PHP FastCGI Process Manager (PHP-FPM), Apache mod_php, PHP Common Gateway Interface (php-cgi), FrankenPHP and LiteSpeed among web-serving environments that should update. It describes the strongest demonstrated exposure in mod_php, where an unauthenticated request can trigger exploitation before application code executes. An application authentication check should therefore not be treated as a complete substitute for the runtime update.
For vulnerability-management records, distinguish the two Common Vulnerabilities and Exposures (CVE) entries. They share a release train but affect different aspects of request processing. A configuration workaround targeting one path cannot be assumed to close the other.
The two failure modes
CVE-2026-109618: interrupted request initialisation
PHP's out-of-memory advisory describes a failure in which an allocation error interrupts processing while request data is not yet fully initialised. Cleanup can subsequently operate on that invalid state. The advisory reports complete remote code execution against mod_php with ordinary input and memory limits; it also makes clear that build, extension and frontend differences affect exploit reliability.
The patch changes how PHP handles allocation failures so that incomplete state is not exposed to the same cleanup sequence. This is a runtime memory-safety issue. A web application need not contain its own SQL injection or file-upload code execution flaw for the demonstrated mod_php path to matter.
The same advisory explains that PHP-FPM terminates a worker when request startup fails, which interrupts the demonstrated startup sequence. It does not call FPM immune: application-specific allocation failures after startup remain a concern. Keep the demonstrated result and the conditional concern separate in incident reporting.
CVE-2026-109619: state crossing a request boundary
The stale-global-state advisory, also identified in the National Vulnerability Database (NVD) record for CVE-2026-109619, describes request-owned memory that is freed while a persistent worker still retains a reference. A later request reaching that worker can encounter the stale state before normal initialisation replaces it. The advisory requires both an operation that leaves state behind and a later operation that consumes it; a generic error message alone does not demonstrate the full chain.
PHP reports validated session-lifecycle remote code execution against both mod_php and FPM. For the FPM case, the producing operation occurs during application execution after successful startup and depends on a suitable application operation. Session upload progress supplies an early consumer and does not require the application to call session_start(). This is why the narrower FPM behaviour in the out-of-memory advisory must not be expanded into a claim that FPM is safe from the overall release's vulnerabilities.
Fixed releases and distribution packages
The PHP announcement identifies these upstream fixes:
| Maintained branch | Fixed upstream release |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
PHP notes that older upstream branches no longer receive its normal updates and directs users to their distribution or long-term-support (LTS) vendor for backported fixes. An upstream version comparison alone is therefore insufficient for distribution packages.
For example, Ubuntu USN-8948-1 publishes the following package fixes, including its Common Gateway Interface (CGI), command-line, FPM and Apache module packages:
| Ubuntu release | PHP package version in the notice |
|---|---|
| 26.10 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | 8.1.2-1ubuntu2.28 |
These are vendor-specific package versions, not alternative upstream PHP releases. Match the operating-system release and package provenance to the notice. Conversely, a binary displaying the same short upstream number without the distribution patch level does not prove it contains a vendor backport.
Our recommended change record should include the service owner, serving interface, package or image identity, vendor advisory, fixed-version comparison, restart time and validation result. Include independently deployed pools and containers rather than relying on the version returned by a single administrator shell.
Temporary controls and their limits
Both PHP technical advisories make the complete patch the remediation target. Their temporary controls remove particular attack paths; they are not a generic safe configuration.
For stale session state, PHP recommends setting session.upload_progress.enabled=0 administratively and restarting every worker. For PHP 8.5's fatal-backtrace path, it also identifies fatal_error_backtraces=0. The stale-state advisory says neither control covers every producer and consumer of request-owned state. Disabling error display or logging does not remove the vulnerable operation.
The out-of-memory advisory discusses removing PHP's finite per-request memory limit as an emergency measure. That recommendation has substantial qualifications: underlying allocation failures remain possible, request-size controls are still needed and container or cgroup limits are not a complete mitigation. Teams considering it should follow the full vendor instructions, assess availability consequences and assign a short review period. A copied one-line setting without those controls is not an adequate remediation plan.
Where an update cannot be deployed promptly, our recommendation is to assess whether the affected service can be restricted or temporarily removed from exposure while its owner implements the vendor's scoped controls. Record the residual risk explicitly and keep the update scheduled.
Verify deployment and investigate separately
A successful package installation is one piece of evidence. Our recommended completion procedure is to confirm the patched version in the environment serving requests, restart or replace all relevant workers, exercise normal application functions and check that deployment templates will not restore an older runtime. Preserve the package or image identity in the incident or change record.
The stale-state advisory warns that no predictable log entry covers every vulnerable path. It recommends auditing configuration, application flow and available logs together. Absence of crashes or errors therefore cannot close the vulnerability ticket in place of patch verification.
As a precaution, investigate unexpected worker failures, unusual child processes, new files in application directories and unexplained outbound connections in their full context. These are general incident-response leads, not signatures established for exploitation of these vulnerabilities. Retain request and process telemetry where available, and avoid turning an exposed version into an unsupported assertion of compromise.
If evidence indicates code execution, determine what the web worker could access, preserve relevant evidence and scope containment accordingly. Patching addresses future exploitation of the vulnerability; it does not by itself establish that an already compromised service has been restored to a trusted state.
Separate follow-up notices
PHP's 23 October session notice describes a separate issue under a narrower configuration involving a runtime change of session serialisation handler. Its 26 October Windows notice concerns rebuilt packages with a Brotli fix. Neither should be silently folded into the two PHP2Shell CVE entries or used to claim that the 21 October fixes cover every later dependency issue.
Our separate article covers Brotli across runtimes. Use the vendor notices as the evidence for each remediation decision.
