PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Fix Two Exploited RCE Flaws

Fixed PHP Releases for Each Supported Line #

Both CVE records list the same ranges: every 8.2 release before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP says all installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Linux distributions and LTS vendors received the patches in advance, so PHP points their users to the vendor's updated packages.

PHP 8.1 and older receive no updates from the PHP project. For them, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1, meant for people who build from source or have no LTS vendor. On the 8.6 line, 8.6.0 RC4 already contained both fixes, and 8.6.0 RC7 on November 12 names November 19 as the planned date for the 8.6.0 release.

CVE-2026-109618: Out-of-Memory Handling Leaves Request Memory Invalid #

PHP leaves a context with longjmp() when it runs out of memory. GHSA-w8hw-w9fx-j79w explains that request memory is sometimes reachable before it is fully initialized, and an allocation failure at that moment leaves it invalid. Request shutdown then reads or branches on that memory. The failed allocation does not need to be related to the invalid memory.

An attacker reaches the memory limit through multipart parsing while staying inside the limits PHP appears to enforce:

• A multipart request without a usable declared content length can pass the first post_max_size check and keep sending body data.
• A multipart part can carry any number of headers, which take far more memory inside PHP than on the wire.
• Empty file controls do not count toward max_file_uploads but still create file metadata arrays, and nested field names multiply that work.

The server API decides how far this goes. Apache mod_php always runs request shutdown, even when request startup failed, so the corrupted state is processed before any application code runs. FPM exits the child when startup fails, but the advisory treats it as susceptible after normal startup, although no complete FPM exploit has been shown. Source analysis makes FrankenPHP likely susceptible to the same application-independent attack, and LSAPI works like FPM, with application-specific exploits likely but not validated. The advisory reports complete remote code execution as the web worker account against mod_php with default PHP input and memory limits.

The patch removes longjmp() for out-of-memory errors. PHP now raises a soft out-of-memory error at the next VM safe point and exits the process with _exit() only when memory use reaches a second, higher threshold.

CVE-2026-109619: Stale Global State Reused by the Next Request #

GHSA-6wmf-4rv5-p3rp describes global state, such as error, session, object and extension state, that a worker keeps while it points into one request's memory. Exploitation needs a producer and a consumer in two requests handled by the same worker. The producer leaves that state behind: a fatal error abandons an operation before its reset, through a parse failure, an uncaught error, a failed require, Maximum execution time exceeded or running out of memory. The consumer then uses the freed memory before the next request is initialized.

The advisory confirms two consumers. The first is a warning, notice or deprecation raised while applying invalid or deprecated INI settings before initialization. It does not have to be displayed or logged, so error_reporting, @ and display_errors do not protect. With mod_php, .htaccess values and Apache php_value or php_admin_* directives are applied at that early point. For this consumer, FPM is exposed only when nginx or another frontend sends PHP_VALUE or PHP_ADMIN_VALUE parameters that raise such a diagnostic. The second consumer is session upload progress. It is enabled by default and needs no call to session_start() in the application.

On PHP 8.5, fatal_error_backtraces stores request-owned backtrace state that shutdown always fails to reset. The advisory calls this the strongest demonstrated case and the basis of the confirmed mod_php exploit. On FPM, a validated path uses an application operation that hits a fatal error after normal startup and then session upload progress as the consumer.

CVE-2026-115560: A Session Upload Progress Case Left for the Next Bugfix Release #

On October 23, PHP published an informational advisory about a further remote code execution vector, CVE-2026-115560. It needs three conditions together: session.serialize_handler configured as php_binary or php_serialize, application code that switches it to php with ini_set() before session_start(), and session upload progress still enabled. PHP is fixing it in the regular release cycle and will publish the full advisory with the next regular bugfix release. Until then, it suggests setting session.upload_progress.enabled=0, the same measure the October 21 advisory gives for CVE-2026-109619.

Brotli CVE-2026-111497 in the PHP Windows Builds #

On October 26, PHP rebuilt its Windows packages as 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 with Brotli 1.2.1. That version fixes CVE-2026-111497, an out-of-bounds write in the Brotli decoder. Google scores it 9.2 under CVSS 4.0, and CISA's SSVC assessment of October 23 rates exploitation as active. In the Windows builds, the decoder is reached through the cURL extension when automatic HTTP response decompression is on. cURL keeps it off by default, but applications and HTTP client libraries can turn it on. The rebuilds use the same PHP source, so php -v still prints 8.5.12 or 8.4.27. The CVE record lists Brotli 1.0.3 through 1.2.0 as affected, with fixes in 1.0.10, 1.1.1 and 1.2.1.

Updating PHP and Reducing Exposure Before the Update #

1. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the distribution package that carries the backport, then restart every PHP-FPM pool and Apache process so no worker keeps the old binary. Rebuild container images that pin an older PHP.
2. On Windows, install the -1 build of the same version to pick up Brotli 1.2.1.
3. On 8.1 or older, ask the LTS vendor for its backport or build from PHP's source backport, and plan the move to a supported line; 8.2 also stops receiving fixes after 31 December 2026.
4. Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration and restart the workers. ini_set() and FPM .user.ini apply too late. Keep it until the bugfix release that fixes CVE-2026-115560.
5. If an update has to wait, set memory_limit=-1 with php_admin_value so applications cannot lower it again, set post_max_size = 8M without uploads or 32M with them, and keep upload_max_filesize below it. Use a per-worker container or cgroup memory limit, never RLIMIT_AS or RLIMIT_DATA, which trigger the vulnerable path.
6. On PHP 8.5, set fatal_error_backtraces=0 and restart the workers. Remove invalid or deprecated INI values applied per directory or per request.
7. Enforce request size, input field count, multipart part count, header count and nesting depth at the web server or proxy, including for requests without a usable Content-Length. Keep these limits after updating: the advisory says they reduce denial-of-service risk even with the patch.

PHP stresses that none of these measures makes an unpatched installation safe; each one blocks only specific attack paths.

Checking a PHP Server: Version, SAPI and Exposed Settings #

The CLI and FPM can load different php.ini files, so the settings check runs once for each. php-fpm -i prints FPM's own configuration (on Debian and Ubuntu the binary carries the version, such as php-fpm8.4), and apachectl -M shows whether Apache loads mod_php. The last two searches find the application code behind CVE-2026-115560 and the cURL option that turns on automatic decompression.

php -v
php-fpm -v
apachectl -M 2>/dev/null | grep -i php
php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|session.upload_progress.enabled|session.serialize_handler|fatal_error_backtraces) "
php-fpm -i | grep -E "^(memory_limit|post_max_size|session.upload_progress.enabled|fatal_error_backtraces) "
grep -rn "session.serialize_handler" --include="*.php" .
grep -rnE "CURLOPT_ACCEPT_ENCODING|CURLOPT_ENCODING" --include="*.php" .