Two critical PHP RCE flaws fixed: what to patch and why mod_php is the worry

PHP maintainers have shipped fixes for two critical vulnerabilities, as reported by Bruce Schneier. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Per the maintainers' notice, both flaws can allow unauthenticated remote code execution, and all PHP users are strongly encouraged to update immediately.

The two vulnerabilities

Both bugs concern how PHP manages internal per-request state, not a specific extension or framework. That is why application-level hardening is unlikely to help.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE via out-of-memory corruption: out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup may then treat the invalid data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE via stale global state: request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it.

The first is an error-path bug: cleanup code runs against data that was never fully built. The second is a cross-request lifetime bug: state outlives its memory and leaks into the next request served by the same worker. Both are classic memory-safety patterns in a long-running C runtime.

Who is exposed

The maintainers state that all PHP installations serving web requests are at risk. They list PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. They consider the risk highest for mod_php, where there is a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs.

That last point matters for defenders. If exploitation happens before application code executes, controls that live in your application, such as authentication, input validation and framework-level WAF rules, never get a chance to intervene. Network-layer filtering and the runtime version are what remain.

What to do

1. 1Inventory every PHP runtime. Include containers, base images, shared hosting, legacy VMs and vendor appliances that bundle PHP, not only the servers you consider primary.
2. 2Upgrade to the matching fixed release: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. The maintainers say updating is the only way to regain security, and the notice gives no workaround.
3. 3Rebuild and redeploy, then verify. Confirm the running version with php -v or your SAPI's version output after restart. A patched package on disk does not help if a long-lived worker is still running the old binary.
4. 4Prioritise mod_php and internet-facing hosts first, since that is where the maintainers rate the risk highest.
5. 5Review logs for anomalies. Look for unusual crashes or out-of-memory events on PHP workers from before the patch, as a precaution.

What we do not yet know

The notice we reviewed does not list which earlier versions are affected beyond the fixed releases, and it does not state whether either flaw has been exploited in the wild. It also gives no severity scores. Treat any claim on those points as unverified until it appears in the CVE-2026-109618 and CVE-2026-109619 advisories. Where your PHP version is end-of-life and has no fixed release in this set, plan a migration rather than waiting for a backport.