PHP emergency release: two critical core RCEs fixed in 8.2.35 through 8.5.12
PHP has shipped an out-of-band security release for two critical use-after-free vulnerabilities in the language core, both exploitable for unauthenticated remote code execution and both rated 9.2 on the CVSS v4.0 scale. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, published today and listed in the project's release archive. Minimal source backports for the long-unmaintained 7.4, 8.0 and 8.1 branches exist on GitHub only - there are no official binaries for those.
The release followed an unusually messy pre-disclosure window. On October 20 the project announced an emergency release for 14:00 UTC today without naming affected versions or functions; as OX Security documented, screenshots of an exploit tool circulated before the patches were out, and the project itself warned that proof-of-concept code circulating in that window is often malware in disguise. With the patches and advisories now public, the technical picture is clearer than the teaser cycle suggested.An out-of-memory path to code execution
CVE-2026-109618, tracked as GHSA-w8hw-w9fx-j79w, abuses how PHP handles memory exhaustion. When an allocation fails, the engine unwinds the request with a longjmp() - and if that happens while request memory is only partially initialized, the shutdown phase later reads or branches on memory in an invalid state. The advisory describes a family of allocation-pressure tricks that make this reachable from an ordinary HTTP request: multipart bodies without a usable content-length that slip past post_max_size, parts padded with thousands of headers whose in-memory representation dwarfs their wire size, and empty file controls that allocate metadata arrays without ever counting against max_file_uploads. The Apache mod_php SAPI is confirmed exploitable: researchers validated unauthenticated remote code execution as the web worker account over plain HTTP against default prefork configurations, though with high attack complexity and possibly multiple attempts. PHP-FPM is considered susceptible through application-specific allocation paths, with FrankenPHP and LiteSpeed likely in the same boat. The patch replaces the raw longjmp with a soft out-of-memory trap at the next VM safe point, plus a hard failure that kills the worker outright.Stale state in worker processes
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) is the quieter sibling: worker processes carry global state - error handlers, session data, object and extension bookkeeping - that can end up pointing at memory owned by a single request. If a fatal error, an out-of-memory abort or a late diagnostic writes such state and nothing resets it before the request memory is freed, the worker's globals dangle. Whatever touches them before a fresh request initializes reads freed memory. Two production paths are confirmed: the fatal-error backtraces introduced in PHP 8.5 under mod_php, and the session upload progress mechanism under both mod_php and FPM. Producer and consumer must land on the same worker process, which makes FPM pools with many workers harder - but not impossible - to hit.A strategically crafted heap layout can produce full remote code execution (RCE). - PHP security advisory, GHSA-6wmf-4rv5-p3rp
What administrators should do now
Updating is the only complete mitigation, and this is not a patch-and-forget case: both advisories stress restarting all PHP workers after upgrading, because stale state can survive in long-lived processes. Supported branches get release binaries; sites pinned to EOL branches must apply the source backports themselves.- Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or apply the GitHub backports for 7.4/8.0/8.1), then restart every worker process.
- If updating today is not possible: set session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0, and restart the workers.
- For the OOM bug, enforce memory_limit=-1 centrally and verify that no pool or .htaccess override restores a finite limit.
- Keep post_max_size conservative, block multipart requests at the frontend if the application does not use them, and bound input variables, headers and uploads.
- Use container or cgroup memory limits instead of RLIMIT_AS or RLIMIT_DATA - the advisory explicitly warns the RLIMIT mechanisms push allocation failures onto the vulnerable path.
- Optionally cap worker recycling with pm.max_requests to shorten the window for state carry-over.