Correction releases for PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 have been published, along with patches for unsupported branches PHP 7.4, PHP 8.0, and PHP 8.1 (vulnerable versions from 5.4 to 7.3 remain unpatched), addressing two critical vulnerabilities:
- CVE-2026-109618 — remote code execution due to the exhaustion of available free memory for the process. The memory shortage handler, through the execution of the longjmp() function, may interrupt the PHP interpreter while only part of the internal structures related to request processing have been initialized. Subsequently, the request handling termination function accesses these structures as if they were already initialized, although memory for them has not been allocated.
The primary attack vector involves manipulating multipart requests to create conditions for exhausting the available process memory. To bypass the post_max_size limit, the Content-Length header may be omitted, and a large number of HTTP headers can be sent. Targeted attacks on specific operations in PHP applications that excessively consume memory are also possible. Exploit availability has been confirmed for mod_php, as it invokes the shutdown() function even upon failure. PHP-FPM will terminate the child process upon failure, making the attack more challenging but theoretically not impossible.
- CVE-2026-109619 — remote code execution due to access to memory after it has been freed, resulting from improper cleanup of the global state linked to a specific request. If a request is interrupted due to a fatal error, timeout, or memory shortage, the global state may not be reset, and pointers will remain active despite the memory they reference being freed. When the next request is processed in the same process, accessing the stale pointer can lead to referencing the old global state.
Exploitation can involve creating conditions that deplete available memory when processing a multipart request in the code for upload progress indication (session.upload_progress). In this context, the main and confirmed attack vector mentioned is the fatal_error_backtraces handler in PHP 8.5, which does not reset the backtrace state upon termination. In the first case, the attack is possible on both mod_php and PHP-FPM, while in the second case, only on mod_php. An unconfirmed possibility of attack is also mentioned in configurations where directives lead to warning outputs at an early stage of request processing (for instance, warnings about deprecated parameters).
It is claimed that complete blocking of vulnerabilities is only possible through the installation of an update. The following measures can reduce the likelihood of successful attacks but do not make the system completely secure:
- Setting the php.ini parameter "memory_limit=-1", which makes it difficult for an attacker to control the exhaustion of memory limits.
- Setting the parameter "post_max_size = 8M" if there is no need to upload large files. The value of the "upload_max_filesize" parameter should be less than that of the "post_max_size" parameter.
- Setting a limit on permissible memory consumption at the system level through cgroup memory.max or container memory consumption parameters, but not through system limits RLIMIT_AS and RLIMIT_DATA, which only provoke the problematic longjmp() call.
- If performance is not critical, the number of requests processed by a single worker process can be limited via pm.max_requests=1 in PHP-FPM and MaxRequestsPerChild in Apache httpd.
- Setting at the php.ini level or configuration server (not via ini_set() or FPM .user.ini, since the parameter must take effect before the request handling begins) the parameter "session.upload_progress.enabled=0.
- When using PHP 8.5, the parameter "fatal_error_backtraces=0" should be set.
- Removing legacy or erroneous settings tied to individual requests (such as assert.* and incorrect paths in open_basedir) that lead to diagnostic message output before initialization.
- Eliminating situations in PHP code that lead to timeouts and fatal errors, for instance, those related to failures in callback handlers and upload processing.
- To block the first vulnerability in the code of older PHP versions, you can replace the longjmp() call in the out-of-memory handler with _exit().
- Additionally, you can lower the max_input_nesting_level parameter in php.ini and block multipart requests, as demonstrated in the preliminary announcement.
The status of vulnerability remediation in distributions can be assessed on these pages: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Addendum 1: Vulnerabilities were identified using AI models GPT‑5.6 and Gemini 4 Argon. OpenAI has released the php2shell-checker utility to check website and local executable file vulnerability exposure, but this utility only checks the PHP version returned by the HTTP server or the command 'php -v', without detailed analysis.
Addendum 2: The author of the exploit prototype that uses the vulnerability caused by double-free memory reported that the issue remains unpatched in the PHP 8.5.12 release and the exploit continues to work. Previously, PHP representatives stated that this vulnerability is not related to the upcoming fixes and is not a real issue. However, the exploit author claimed that this is a completely different vulnerability.
Source: opennet.ru
