PHP RCE vulnerabilities CVE-2026-109618 and CVE-2026-109619: what to check and how to update

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 vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can lead to unauthenticated remote code execution. They carry a CVSS v4.0 score of 9.2 (Critical) from the PHP Group, with attack complexity listed as High, and CISA added both to its Known Exploited Vulnerabilities catalog on 26 October 2026. The advisories do not state whether exploit code is publicly available.

What was found

CVE-2026-109618 (RCE via OOM corruption). PHP uses longjmp() to abort a request when it runs out of memory. If that happens while internal request data is only partly initialized, the cleanup at the end of the request can treat invalid data as valid. The advisory lists several ways to exhaust memory with a multipart request that still looks within PHP's limits.

CVE-2026-109619 (RCE via stale global state). Some internal state points to memory owned by a single request. If a fatal error, such as a timeout, interrupts the request before that state is reset, a later request handled by the same worker can read freed memory (a use-after-free). The attack needs two requests: one leaves the stale state and the next uses it.

Who is affected

Every release before 8.5.12, 8.4.27, 8.3.36 and 8.2.35 in their branches. According to the PHP announcement, any installation serving web requests is in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers the risk highest for mod_php, where an unauthenticated attack has been demonstrated that runs before any application code. For CVE-2026-109618 a complete FPM exploit has not been demonstrated, while for CVE-2026-109619 the advisory reports a validated attack against both mod_php and FPM.

PHP 8.1 and older no longer receive project updates. The security team prepared minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide their own fixes.

Check your PHP version

php -v
php-fpm -v   # the binary name varies: php-fpm8.3, php83-fpm...

The command-line binary can differ from the one serving your site. To see the web version, use a temporary page that prints it, and delete it afterwards:

<?php echo PHP_VERSION;

If PHP comes from a distribution or LTS vendor, check their advisory for the fixed package: a backported fix does not always change the version number.

How to update

Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release of the same branch. Source and Windows binaries are on php.net; on Linux, use your distribution's updates. Then restart every PHP worker (the FPM service, or Apache with mod_php). Both advisories say that updating is the only complete mitigation.

If you cannot update today

These measures only reduce exposure to specific attack paths; they do not make an installation safe. The same checklist is in my original article in Spanish.

For CVE-2026-109618:

• Set memory_limit=-1 administratively, so the application cannot change it. It removes the controllable limit used by the confirmed attack, but it is not complete.
• Set post_max_size to 8M if the application needs no uploads, or 32M if it does, and keep upload_max_filesize below it.
• Enforce limits at the web server or proxy for decoded request size, fields, multipart parts, headers and nesting depth, including requests without a usable Content-Length.
• Use a container or cgroup limit as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA: they can trigger the vulnerable failure.

For CVE-2026-109619:

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, and restart every worker. Do not rely on ini_set() or FPM's .user.ini. It does not cover other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart.
• Remove invalid or deprecated settings applied per request that emit warnings before initialization. Hiding warnings with error_reporting, display_errors or @ does not help.
• Fix fatal errors and timeouts that an attacker can trigger.

On 23 October the project also recommended session.upload_progress.enabled=0 until the next bugfix release, for a separate and unlikely vector (CVE-2026-115560).

Sources

PHP announcement, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, NVD CVE-2026-109618, NVD CVE-2026-109619 and the CISA KEV catalog.

I wrote a more detailed version in Spanish here: PHP: vulnerabilidades críticas RCE (CVE-2026-109618 y 109619)

Comments

[Stefano Franco]

Great contribution, Marius.

One practical addition for anyone on sury/ondrej packages (Debian/Ubuntu), since you mention that backports may not change the version number: that's exactly the case there. php -v reports 7.2.34 or 8.1.34 both before and after the fix — only the Debian revision changes. For example, on Debian bullseye, PHP version 8.1.34-8 is still vulnerable while 8.1.34-9 has the fix. A quick way to check what you actually run:

zcat /usr/share/doc/php8.1-common/changelog.Debian.gz | grep -m1 -E '109618|109619'

(adjust the PHP version), and remember to restart FPM afterwards: running workers keep the old binary in memory.

If you're on a distro sury no longer builds for (for example, Debian 8 or 9), I wrote up how we rebuilt sury's patched 7.2 source for stretch and jessie, including an ICU trap that silently changed localized output: dev.to/sphranko/php2shell-on-a-dea...

Thank you for your article.

[Marius Podar]

Thanks, this is exactly the case I had in mind with that note. Good tip on checking the Debian changelog and restarting FPM afterwards. I'll add a pointer to it in the article.