PHP fixes two critical remote code execution flaws: update now

On 21 October 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws that can let an attacker run code on a server without signing in. Both are rated 9.2 under CVSS v4.0. If you run or look after anything on PHP that answers web requests, the project's advice is to update now.

What the two flaws do

Both bugs are in PHP itself, so a fully updated application on an affected PHP build is still exposed.

• CVE-2026-109618, remote code execution via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialised, and request cleanup may then treat that invalid data as valid. The GitHub advisory says several multipart parsing problems can push a request out of memory while it stays within its apparent PHP limits.
• CVE-2026-109619, remote code execution via stale global state. Internal state that belongs to one request can survive after its memory has been freed, and a later request handled by the same worker may use it before normal initialisation resets it. The confirmed paths run through diagnostics raised before a request initialises and through session upload progress handling.

Neither the PHP project nor the GitHub advisories say the flaws are being exploited in the wild. They do say an exploit has been demonstrated, and the technical details are now public.

Which servers are exposed

The advisory puts every PHP installation that serves web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project rates the risk highest for mod_php, where a demonstrated exploit needs no authentication and triggers before any application code runs. On that path, nothing in the application, such as a login screen or a security plugin, stands in the way.

PHP-FPM is not a safe harbour either. A session path of CVE-2026-109619 was validated against both mod_php and PHP-FPM. For CVE-2026-109618, the advisory's analysis of the source finds FPM susceptible, although no complete FPM exploit has been shown.

Fixed versions, and PHP 8.1 and older

Linux distributions and long-term support (LTS) vendors received the patches in advance, so check your vendor for updated packages. A patched distribution package can keep an older-looking version number, so look for the two CVE numbers in its security notice.

PHP 8.1 and older get no updates from the PHP project, though some distributions and LTS vendors backport fixes. Given the severity, the PHP security team also provided minimal source backports for PHP 7.4, 8.0 and 8.1, as branches in the php-src repository, for people who build from source or have no LTS vendor.

PHP 8.2 reaches end of life on 31 December 2026, with no security fixes after that date. PHP 8.6.0 RC4, a test build not meant for production, also includes the fixes, so anyone testing an earlier 8.6.0 build should move to it.

If you cannot update today

Updating is the only complete fix. These measures from the advisory narrow specific attack paths but do not make a server safe.

• Set memory_limit=-1 where applications cannot override it, such as php_admin_value in the FPM pool or Apache configuration, and check nothing sets a finite limit back.
• Set post_max_size to 8M if the site takes no uploads, or 32M if it does, with upload_max_filesize below it. Limit request size, field count, multipart parts, headers and nesting depth at the web server or proxy, including for requests without a usable Content-Length.
• Use a container or cgroup memory limit as the availability boundary, not RLIMIT_AS or RLIMIT_DATA, which can cause the very allocation failure the bug needs.
• Set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration, not with ini_set() or .user.ini, and restart every worker.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• Remove invalid or deprecated per-request settings that emit diagnostics before initialisation. Hiding them with error_reporting, display_errors or @ does not help.
• Fix fatal errors and execution timeouts an attacker can reach, including in upload and import handling.

Where Stacklumen sites stand

Nothing in Stacklumen's platform runs PHP, so pages published from Terminal are not exposed to these flaws. A form handler, API or old site you run on a PHP server elsewhere is.

One case to check: a Terminal form normally sends to the site's Forms inbox, but an imported form can keep posting to its own outside service, with a copy in the inbox. If that service is a PHP script on another server, that server needs the update.

What to do now

1. List every server, client site and script you are responsible for that runs PHP, including the forgotten ones.
2. Check the PHP version that serves web requests, not only php -v on the command line, which can be a different build. On shared hosting, check the control panel or ask the host.
3. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your vendor's patched packages, then restart PHP-FPM or the web server so the new build is the one answering requests.
4. Where an update has to wait, apply the mitigations today and book the update.
5. Move anything on PHP 8.1 or older to a supported version, and plan for 8.2's end of life on 31 December.

Sources

• PHP security advisory: critical remote code execution vulnerabilities, 21 October 2026
• PHP news archive for 2026: the 20 October notice and the 21 October releases
• PHP 8.6.0 RC4 available for testing, 21 October 2026
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• PHP downloads