PHP patches two critical RCE flaws: mod_php highest risk, FPM needs attention too

The fix is out. Find the PHP process that serves the request

PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws that can lead to unauthenticated remote code execution. The 21 October security announcement identifies CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. The project says to update immediately. For a UK operator, the urgent question is not what php -v prints in one shell. It is which PHP build is running behind each public site, upload endpoint, container, managed host and bundled product, and whether its workers actually restart on a fixed build.

PHP says all installations serving web requests are in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It calls mod_php the highest-risk case because an unauthenticated request has been demonstrated to reach an exploit before application code runs. The two PHP-maintained technical advisories make important distinctions: the first has a complete HTTP remote-code-execution demonstration against mod_php but no complete FPM exploit demonstrated for that same flaw; the second has validated session-lifecycle RCE against both mod_php and FPM. These are reasons to prioritise exposure, not to treat another web SAPI as safe.

Two defects, two different failure boundaries

Source and scope: PHP security team and php/php-src advisories, published 21 October 2026. Both flaws are Critical and scored 9.2 under CVSS v4.0. The cards separate the demonstrated exploit paths; the mechanisms and further caveats follow.

For CVE-2026-109618, PHP uses longjmp() on out-of-memory failure. The advisory explains that multipart parsing can use much more memory than the apparent request size, and that a failure at the wrong moment leaves partially initialised request data for shutdown to process. The validated mod_php case reaches that condition before any application-specific code executes. PHP says its patch changes the out-of-memory path to avoid leaving shutdown with that invalid state. The advisory describes FPM as potentially susceptible after successful request startup, while being explicit that the demonstrated mod_php chain cannot simply be assumed to work unchanged in FPM.

CVE-2026-109619 crosses a different boundary: PHP reuses a web worker across requests, but some global fields point to memory owned by only one request. An interrupted operation can leave a stale reference after that request is freed. A later request on the same worker may encounter it before normal initialisation resets the state. The advisory identifies early configuration diagnostics and session upload-progress handling as confirmed consumers. It reports validated session-lifecycle RCE against mod_php and FPM; the confirmed PHP 8.5 fatal-backtrace path is a mod_php case. Other application, extension and configuration paths are conditional and should not be represented as universally exploitable.

A 9.2 score does not mean every PHP site has an identical one-request exploit. Both advisories show network attack vector, no prior privileges and no user interaction, but mark attack complexity high and attack requirements present. Exploitability varies with the web SAPI, frontend behaviour, request parsing, configuration, allocator, extensions and whether the necessary operations are reachable. The defensible priority remains an internet-facing runtime that has not yet received its vendor fix, especially mod_php.

What a UK operator should do this afternoon

The UK NCSC alert calls for identifying PHP across the estate, prioritising internet-facing systems, monitoring for malicious activity, following PHP and third-party vendor guidance, and applying updates as they arrive. It says to consider taking a system offline where immediate remediation is not feasible. That is a risk decision for the affected service, not a blanket assertion that every PHP site has been compromised.

PHP says Linux distributions and LTS vendors received patches in advance. Its release warning is unusually specific about the volunteer-maintained rpms.remirepo.net repository: it will not have these updates today, so dependent operators should use distribution packages or build from source to apply the fix immediately. The project also supplied minimal source backports for PHP 7.4, 8.0 and 8.1 to help source builders and those without an LTS vendor; that is not a resumption of ordinary upstream support for those branches. PHP 8.2 itself is scheduled to reach end of life on 31 December 2026.

If the update is delayed, controls reduce only parts of the risk

The PHP announcement says updating is the only complete solution. It provides interim controls for specific paths, with caveats. For CVE-2026-109618, administrators can enforce memory_limit=-1 at a level an application cannot override, keep post_max_size conservative, and constrain decoded request size and multipart complexity at the frontend. This removes a predictable PHP memory-limit failure in the demonstrated route, but an underlying allocation failure can still reach vulnerable handling. PHP explicitly warns against using RLIMIT_AS or RLIMIT_DATA as substitutes because those can trigger that failure. Test any availability and resource effect before applying the setting across production.

For CVE-2026-109619, PHP advises disabling session.upload_progress.enabled administratively and restarting workers to block the confirmed session paths. On PHP 8.5, turning off fatal_error_backtraces and restarting workers blocks the confirmed fatal-backtrace producer. Neither covers every stale-state path. Early invalid or deprecated per-request settings that emit diagnostics should be removed; hiding messages with error_reporting, display_errors or @ does not prevent the state access. These measures buy limited time for a specific configuration, not a patch exemption. Read the full stale-state advisory before changing settings.

Exploitation reports are a separate evidential question

Patchstack reported that hosting partners had told it of active exploitation before disclosure. That is a first-hand account of reports it received, but its public material does not provide a verified case count, host logs or a complete incident chain. The PHP security announcement says a mod_php exploit was demonstrated, which establishes technical exploitability; it does not by itself quantify exploitation in the wild or UK compromises. The NCSC notice provides operator advice but no UK victim count. We have not independently established the scale of real-world exploitation from those sources.

Investigators should distinguish an attack request from successful code execution, and a vulnerable runtime from a confirmed compromise. Preserve relevant web and worker logs, process trees, outbound-network records and deployment details if there are signs of intrusion. A clean update stops the vulnerable code path going forward, but it does not answer whether an earlier request succeeded. Where that question matters, investigate the service as an incident rather than treating package installation as a retrospective clearance.

The practical boundary

The PHP release changes the immediate task from waiting for technical scope to proving a corrected interpreter is handling web requests. The four supported-branch fixes and both CVEs are now public. What remains deployment-specific is the exact package a distributor ships, the SAPI and configuration that a given application uses, and whether any attempted attack reached a particular worker. Patch every affected runtime, verify the running process, and keep those unresolved incident questions separate from the confirmed vulnerability facts.