{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Details of critical vulnerabilities in PHP have been revealed, and corrective updates have been published.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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:<\/p>\n
\n
CVE-2026-109618 \u2014 remote code execution, caused by the exhaustion of available free memory for the process. The memory shortage handler, through executing the longjmp() function, can interrupt the PHP interpreter while only part of the internal structures related to request processing is initialized. Consequently, the request processing completion function accesses these structures as if they were already initialized, although memory for them has not been allocated.\n
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. <\/p>\n
CVE-2026-109619 \u2014 remote code execution, caused by accessing memory after it has been freed due to improper cleanup of global state associated with a specific request. If the 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 refer to being freed. During the processing of the next request in the same process, access may occur via the residual pointer to the old global state.\n
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).<\/p>\n<\/ul>\n
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:<\/p>\n
\n
Setting the parameter in php.ini «memory_limit=-1», which complicates the attacker's ability to control memory limit exhaustion.\n
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.\n
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.\n
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.\n