{"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\/de\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Details zu kritischen Sicherheitsanf\u00e4lligkeiten in PHP wurden offengelegt und Korrektur-Updates ver\u00f6ffentlicht.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Es wurden die Korrekturausgaben PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 ver\u00f6ffentlicht, sowie Patches f\u00fcr die nicht mehr unterst\u00fctzten Versionen PHP 7.4, PHP 8.0 und PHP 8.1 (anf\u00e4llige Versionen von 5.4 bis 7.3 bleiben ohne Patches), in denen zwei kritische Sicherheitsanf\u00e4lligkeiten behoben wurden:<\/p>\n
\n
CVE-2026-109618 \u2014 Remote code execution caused by exhaustion of available process free memory. The out-of-memory handler, when called via the longjmp() function, can interrupt the PHP interpreter when only part of the internal structures related to request processing are initialized. Subsequently, the request handling function may access these structures as if they were already initialized, even though memory for them has not been allocated.\n
Der Hauptangriffsvektor besteht darin, multipart-Anfragen zu manipulieren, um Bedingungen zu schaffen, die das verf\u00fcgbare Speicherlimit f\u00fcr den Prozess ersch\u00f6pfen. Um das Limit von post_max_size zu umgehen, kann der Header Content-Length weggelassen und eine riesige Anzahl von HTTP-Headern \u00fcbermittelt werden. Es sind auch gezielte Angriffe auf bestimmte Operationen in PHP-Anwendungen m\u00f6glich, die \u00fcberm\u00e4\u00dfig viel Speicher verbrauchen. Ein Exploit wurde f\u00fcr mod_php best\u00e4tigt, da es die Funktion shutdown() auch bei einem Fehler aufruft. PHP-FPM beendet bei einem Fehler den Kindprozess, was einen Angriff erschwert, aber theoretisch nicht ausschlie\u00dft. <\/p>\n
CVE-2026-109619 \u2014 Remote code execution caused by accessing memory after it has been freed due to incorrect cleanup of global state tied to a specific request. If a request is interrupted due to a fatal error, timeout, or lack of memory, the global state may not be reset, leaving pointers active despite memory being freed. When handling the next request in the same process, there may be access to the old global state via the leftover pointer.\n
F\u00fcr den Betrieb kann die Erzeugung von Bedingungen verwendet werden, die zu einem Ersch\u00f6pfungszustand des verf\u00fcgbaren Speichers bei der Verarbeitung von Multipart-Anfragen im Code zur Anzeige des Upload-Fortschritts (session.upload_progress) f\u00fchren. Dabei wird der Fehlerhandler fatal_error_backtraces in PHP 8.5 als prim\u00e4rer und best\u00e4tigter Angriffsvektor erw\u00e4hnt, der den Zustand der R\u00fcckverfolgung beim Abschluss nicht zur\u00fccksetzt. Im ersten Fall ist ein Angriff auf mod_php und PHP-FPM m\u00f6glich, im zweiten nur auf mod_php. Es wird auch die unbest\u00e4tigte M\u00f6glichkeit eines Angriffs in Konfigurationen erw\u00e4hnt, bei denen es Direktiven gibt, die dazu f\u00fchren, dass Warnungen in der fr\u00fchen Phase der Anfragebearbeitung ausgegeben werden (z. B. Warnungen \u00fcber die Verwendung veralteter Parameter).<\/p>\n<\/ul>\n
Es wird behauptet, dass eine vollst\u00e4ndige Blockierung der Schwachstellen nur durch die Installation eines Updates m\u00f6glich ist. Die folgenden Ma\u00dfnahmen k\u00f6nnen die Wahrscheinlichkeit erfolgreicher Angriffe verringern, machen das System jedoch nicht vollst\u00e4ndig sicher:<\/p>\n
\n
Setting the parameter \u201ememory_limit=-1\u201c in php.ini, which complicates the ability of an attacker to control exhaustion of memory limits.\n
Setting the parameter \u201epost_max_size = 8M\u201c if there is no need to upload large files. The value of the \u201eupload_max_filesize\u201c parameter should be less than that of \u201epost_max_size\u201c.\n
Festlegung einer Obergrenze f\u00fcr den zul\u00e4ssigen Speicherverbrauch auf Systemebene \u00fcber cgroup memory.max oder Container-Speicherverbrauchsparameter, jedoch nicht \u00fcber die Systemlimits RLIMIT_AS und RLIMIT_DATA, die lediglich den problematischen Aufruf von longjmp() hervorrufen.\n
Wenn die Leistung nicht entscheidend ist, kann die Anzahl der Anfragen, die von einem Arbeitsprozess bearbeitet werden, auf 1 durch pm.max_requests=1 in PHP-FPM und MaxRequestsPerChild in Apache httpd begrenzt werden.\n