PHP Security Releases Fix Two Critical RCE Vulnerabilities

The PHP team just released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution. The team is asking everyone to update immediately, and it says there are no complete mitigations.

Every PHP install that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. That covers the way most Laravel apps run in production, so plan to update your servers today.

Note: This is a breaking story and we will be updating this as new information comes out.

# The Vulnerabilities

The PHP team rates the risk highest for mod_php, where it has a working exploit that triggers from an unauthenticated request before any application code runs. Here are the two CVEs:

RCE via OOM corruption , CVE-2026-109618 ( GHSA-w8hw-w9fx-j79w ): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup can then treat that invalid data as valid.

RCE via stale global state , CVE-2026-109619 ( GHSA-6wmf-4rv5-p3rp ): internal state owned by a request can survive after its memory is freed. A later request on the same worker can use that stale state before normal initialization resets it.

Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Source downloads are on the PHP downloads page , and Windows builds are there too.

Linux distributions and LTS vendors got the patches in advance, so check your vendor for updated packages.

PHP 8.1 and older no longer get updates from the PHP project. Some distributions and LTS vendors backport fixes, so check with yours or upgrade to a supported version.

If you use the volunteer-maintained rpms.remirepo.net repo, it won't have updates today. The PHP team recommends switching to distribution packages or building from source.

Because of the severity, the PHP security team also published minimal source backports for PHP 7.4 , PHP 8.0 , and PHP 8.1 for anyone building from source without an LTS vendor.

# What Laravel Cloud, Forge, and Vapor?

Laravel reported the following:

Laravel Cloud customers: we will begin automatically patching your applications as soon as the patch is released. No manual action is required. Laravel Forge customers: you will need to manually update your server’s PHP version via the server’s Forge dashboard. If you are unable to update your server, it should be powered down. Laravel Vapor customers: we will begin automatically re-deploying applications running on PHP 8 as soon as the patch is released. No patch is being released for PHP 7 -- immediately update all applications to PHP 8.

Laravel Cloud customers: we will begin automatically patching your applications as soon as the patch is released. No manual action is required.

Laravel Forge customers: you will need to manually update your server’s PHP version via the server’s Forge dashboard. If you are unable to update your server, it should be powered down.

Laravel Vapor customers: we will begin automatically re-deploying applications running on PHP 8 as soon as the patch is released. No patch is being released for PHP 7 -- immediately update all applications to PHP 8.

# If You Can't Update Right Away

Updating is the only complete fix. The advisory lists settings that reduce exposure to specific attack paths, but the PHP team is clear that they don't make an install safe.

For CVE-2026-109618 (OOM corruption):

Set memory_limit=-1 somewhere apps can't override it, such as php_admin_value in the FPM pool or Apache config. Check that no pool, directory, or app setting puts a finite limit back.

Lower post_max_size . The advisory suggests 8M for apps without file uploads and 32M for apps that need them. Keep upload_max_filesize below post_max_size .

Enforce request limits at the web server or proxy for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits also need to cover requests without a usable Content-Length .

Use a container or cgroup memory limit, ideally one that kills only the affected worker. Don't use RLIMIT_AS or RLIMIT_DATA instead, because they can cause the vulnerable allocation failure.

For CVE-2026-109619 (stale global state):

Set session.upload_progress.enabled=0 in php.ini , an FPM pool, or server config, then restart every worker. ini_set() and FPM .user.ini files don't apply early enough.

On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.

Remove invalid or deprecated per-request settings that emit diagnostics before initialization. Hiding them with error_reporting , display_errors , or @ doesn't help.

Fix fatal errors and execution timeouts an attacker can reach, including failures in callbacks, upload or import processing, and cleanup.

The full details are in the PHP security advisory and the two GitHub advisories linked above. Update your servers as soon as you can.