2 min Security

PHP patches critical vulnerabilities: immediate update required

PHP patches critical vulnerabilities: immediate update required

The PHP project has released security updates for two critical vulnerabilities that allow unauthenticated remote code execution. All PHP installations that handle web requests are at risk. It is recommended to update immediately to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35.

The vulnerabilities are in the core of PHP. They affect PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. According to the PHP security team, the risk is greatest with mod_php. There is a working exploit for mod_php where an unauthenticated request can trigger the attack before even a single line of application code is executed.

Two ways to execute code

The first vulnerability, CVE-2026-109618, revolves around out-of-memory handling. A memory shortage can cause PHP to terminate while internal request data is only partially initialized. When cleaning up the request, PHP then treats that invalid data as valid.

CVE-2026-109619 involves residual global state. Internal data from a request may persist after the underlying memory has already been freed. A subsequent request on the same worker can use that stale state, even before the normal initialization resets everything.

Backports for older versions are also available

Linux distributions and LTS vendors received the patches in advance, so updated packages should be available there. PHP 8.1 and older versions no longer receive updates. However, because of the issue’s severity, the security team created minimal source backports for PHP 7.4, 8.0, and 8.1. Users of the volunteer-maintained repository rpms.remirepo.net will not receive updates today. The PHP project recommends switching to distribution packages or compiling from source.

Can’t update right away? There are mitigations, but according to the PHP project, they do not make an installation secure. For the OOM vulnerability, it helps to set `memory_limit` to -1 using, for example, `php_admin_value`, and to lower `post_max_size` to 8M, or 32M if uploads are required. A container or cgroup limit can serve as a boundary. `RLIMIT_AS` or `RLIMIT_DATA`, on the other hand, are not recommended, as they can cause the vulnerable allocation error.

For the second vulnerability, the team recommends setting `session.upload_progress.enabled=0` in `php.ini` or the FPM pool, followed by a restart of all workers. On PHP 8.5, the same applies to `fatal_error_backtraces=0`. Hiding error messages with `error_reporting` or `display_errors` does not help. The full technical details are available in the PHP project’s advisories.

Tip: PHP brings the internet to a standstill: why PHP2Shell affects every company