Critical PHP bugs allow remote code execution

On 21 October 2026, PHP shipped emergency releases for two critical bugs. Either one can let an unauthenticated web request execute code. Every install that serves HTTP is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP rates mod_php as the highest risk, because a request can hit the bug before any application code runs.

The bugs

CVE-2026-109618, out-of-memory handling. If PHP runs out of memory while request data is only partly set up, request cleanup can treat that incomplete data as valid.

CVE-2026-109619, stale worker state. Internal state from one request can remain reachable after its memory has been freed. A later request on the same worker can then use that stale state.

On 23 October, PHP also described CVE-2026-115560, an unlikely extra path through session upload progress. That one is not fixed in these security releases. It is scheduled for the next regular bugfix release.

Windows packages rebuilt on 26 October (the -1 builds, such as 8.5.12-1) keep the same PHP source and add Brotli 1.2.1. That fixes CVE-2026-111497, an out-of-bounds write in Brotli decompression. On those Windows builds it can be reached through cURL when automatic HTTP decompression is turned on.

The remedy

Updating is the only complete fix. Install one of these, or anything newer on the same branch, then restart every PHP worker:

• PHP 8.5.12 or later
• PHP 8.4.27 or later
• PHP 8.3.36 or later
• PHP 8.2.35 or later

On Linux, take the package from your distribution or LTS vendor. Those vendors received the patches before the public advisory. On Windows, download the builds from php.net and prefer the -1 packages if you are still on the first 21 October files.

PHP 8.1 and older are end of life. Move to a supported release, or ask your vendor for a backport. People building from source can use the minimal backports PHP published for 7.4, 8.0, and 8.1.

After the restart, confirm the version that is actually serving traffic. php -v on the command line can be a different binary from the one behind the site.

If you cannot update today

No setting makes a vulnerable install safe. If a patch will take time, PHP's own temporary measures only close specific paths. Put them in php.ini or the FPM or Apache config, not in ini_set(), and restart the workers:

• Set memory_limit=-1 so the application cannot put a finite limit back. An operating-system allocation failure can still reach the vulnerable path.
• Set session.upload_progress.enabled=0. Keep this in place until the next bugfix release, including after you patch, so the 23 October follow-up is covered.
• On PHP 8.5, set fatal_error_backtraces=0.

If the host is exposed and you cannot patch, take it offline until you can. The full list of temporary limits is in the PHP advisory.