MONDOO-CVE-2026-109618

PHP uses longjmp() to abort the handling of a request when it runs out of memory. Some code paths do not account for this and leave internal request data only partially initialized. The request cleanup that follows may then treat that invalid data as valid. Several out-of-memory strategies trigger this reliably and can lead to unauthenticated remote code execution.

Every PHP installation that serves web requests is exposed, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php: a demonstrated exploit triggers the attack with an unauthenticated request before any application code runs.

Affected / Fixed Versions

• Fixed upstream in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
• PHP 8.1 and earlier (last releases 8.1.34, 8.0.30 and 7.4.33) receive no new releases. The PHP security team published minimal source patches for 7.4, 8.0 and 8.1 for people who build PHP themselves; packaged and Windows builds of these branches stay vulnerable. Vendor backports show that the 5.x code base is affected as well.
• Distribution packages are fixed in the vendor's updated PHP packages. Distribution releases that no longer receive updates, and PHP packages without a published vendor fix, remain affected.

Remediation

Install the updated PHP packages from your distribution, or update to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later. If your distribution or PHP branch has no fix, move to a supported PHP branch or build from source with the published patch.

Mitigation

Only an update fixes this. Until you can update, these measures reduce exposure to specific attack paths but do not make an installation safe:

• Set memory_limit=-1 in a way applications cannot override, for example with php_admin_value in the FPM pool or the Apache configuration, and check that no pool, directory or application setting puts a finite limit back. An underlying allocation failure can still reach the vulnerable path.
• Set a low...