PHP patches two critical RCE flaws in four maintained branches

On October 21, the PHP team released security updates for two critical vulnerabilities that can permit unauthenticated remote code execution under specific request and worker conditions. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The advisories rate both issues CVSS 9.2. PHP lists all web-request installations as potentially affected, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers risk highest for mod_php, where an unauthenticated request can trigger the issue before application code runs. (PHP release archive; CVE-2026-109618 advisory; CVE-2026-109619 advisory)

The two CVEs describe different memory-management failures. CVE-2026-109618 involves request state left inconsistent when an out-of-memory condition interrupts handling. PHP's advisory confirms remote code execution over HTTP against Apache mod_php in the described conditions. It says source analysis supports possible FPM susceptibility, although the same startup-failure path is handled differently and a complete FPM exploit for this CVE was not demonstrated. CVE-2026-109619 concerns request-owned global state that can remain stale across requests handled by the same worker. PHP documents validated remote code execution conditions for both mod_php and FPM. The configuration and application paths that make each issue reachable differ, so a PHP version number alone does not describe every deployment's exposure.

What the attack reports establish

Cloudflare says it observed attack traffic targeting customers and mutated payloads while its WAF mitigations were active. Separately, watchTowr says its Attacker Eye global honeypot network observed exploitation attempts as of October 21. That is evidence of exploit traffic reaching honeypots, not confirmation that requests succeeded on customer systems or that any PHP deployment was compromised. The PHP advisories describe researcher-validated exploitability under specified conditions. The reviewed public reports do not establish successful exploitation of customer sites. A WAF rule can block observed patterns and reduce risk, but it does not install the PHP fixes or cover every request path. (watchTowr PHP2Shell FAQ; Cloudflare analysis)

Patch first, treat workarounds as partial

Update each maintained upstream branch to its fixed release:

• PHP 8.5: 8.5.12.
• PHP 8.4: 8.4.27.
• PHP 8.3: 8.3.36.
• PHP 8.2: 8.2.35.

PHP 8.2 is scheduled to reach end of life on December 31, 2026. PHP says 8.1 and older no longer receive normal upstream updates, while noting that it provided minimal source backports for PHP 7.4, 8.0, and 8.1 for people building from source or without an LTS vendor. Those limited patches do not restore the branches to normal upstream support. For older distribution packages, check the operating-system or LTS vendor's exact backport status instead of inferring safety from the upstream version string.

PHP says there are no complete generic mitigations and that updating is the only complete fix. Its CVE-2026-109618 advisory lists memory_limit=-1 as a primary configuration mitigation for the predictable PHP-level out-of-memory path. This removes PHP's per-request memory cap for that path, while an underlying allocation failure can still reach vulnerable handling. For CVE-2026-109619, the advisory lists disabling fatal_error_backtraces in PHP 8.5 and disabling session upload progress to close specific demonstrated paths. It says these controls do not address all stale-state cases. Treat such settings as temporary risk reduction under the official advisories, not patch substitutes.

Prioritize internet-facing PHP request services, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed, and verify the version each worker actually loaded after updating. For a service that cannot be patched promptly, use the official advisory and your incident-response process to limit exposure while you prepare the update. Review logs and investigate indicators of compromise when attack traffic reached a vulnerable service. Do not treat the presence of attack traffic alone as proof of compromise.