Details zu kritischen Sicherheitsanfälligkeiten in PHP wurden offengelegt und Korrektur-Updates veröffentlicht.

Es wurden die Korrekturausgaben PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, sowie Patches für die nicht mehr unterstützten Versionen PHP 7.4, PHP 8.0 und PHP 8.1 (anfällige Versionen von 5.4 bis 7.3 bleiben ohne Patches), in denen zwei kritische Sicherheitsanfälligkeiten behoben wurden:

• CVE-2026-109618 — Fernaufruf von Code, verursacht durch das Erschöpfen des verfügbaren Speichers für den Prozess, wobei der Speicherengpasshandler durch die Ausführung der Funktion longjmp() den PHP-Interpreter in einen Zustand bringen kann, in dem nur ein Teil der internen Strukturen, die mit der Anfrageverarbeitung verbunden sind, initialisiert wurde. Danach greift die Funktion zur Beendigung der Anfrageverarbeitung auf diese Strukturen zu, als wären sie bereits initialisiert, obwohl kein Speicher für sie zugewiesen wurde.

  Der Hauptangriffsvektor besteht darin, multipart-Anfragen zu manipulieren, um Bedingungen zu schaffen, die das verfügbare Speicherlimit für den Prozess erschöpfen. Um das Limit von post_max_size zu umgehen, kann der Header Content-Length weggelassen und eine riesige Anzahl von HTTP-Headern übermittelt werden. Es sind auch gezielte Angriffe auf bestimmte Operationen in PHP-Anwendungen möglich, die übermäßig viel Speicher verbrauchen. Ein Exploit wurde für mod_php bestätigt, 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ßt.

• CVE-2026-109619 — Fernaufruf von Code, verursacht durch den Zugriff auf Speicher nach dessen Freigabe aufgrund unzureichender Bereinigung des globalen Zustands, der an eine spezifische Anfrage gebunden ist. Im Falle einer Unterbrechung der Anfrage durch einen fatalen Fehler, eine Zeitüberschreitung oder unzureichenden Speicher kann der globale Zustand möglicherweise nicht zurückgesetzt werden, und Zeiger bleiben aktiv, obwohl der Speicher, auf den sie verweisen, freigegeben wurde. Bei der Verarbeitung der nächsten Anfrage im selben Prozess kann ein Zugriff über den verbliebenen Zeiger auf den alten globalen Zustand stattfinden.

  Für den Betrieb kann die Erzeugung von Bedingungen verwendet werden, die zu einem Erschöpfungszustand des verfügbaren Speichers bei der Verarbeitung von Multipart-Anfragen im Code zur Anzeige des Upload-Fortschritts (session.upload_progress) führen. Dabei wird der Fehlerhandler fatal_error_backtraces in PHP 8.5 als primärer und bestätigter Angriffsvektor erwähnt, der den Zustand der Rückverfolgung beim Abschluss nicht zurücksetzt. Im ersten Fall ist ein Angriff auf mod_php und PHP-FPM möglich, im zweiten nur auf mod_php. Es wird auch die unbestätigte Möglichkeit eines Angriffs in Konfigurationen erwähnt, bei denen es Direktiven gibt, die dazu führen, dass Warnungen in der frühen Phase der Anfragebearbeitung ausgegeben werden (z. B. Warnungen über die Verwendung veralteter Parameter).

Es wird behauptet, dass eine vollständige Blockierung der Schwachstellen nur durch die Installation eines Updates möglich ist. Die folgenden Maßnahmen können die Wahrscheinlichkeit erfolgreicher Angriffe verringern, machen das System jedoch nicht vollständig sicher:

• Festlegung des Parameters „memory_limit=-1” in php.ini, was es dem Angreifer erschwert, die Erschöpfung der Speicherlimits zu kontrollieren.
• Festlegung des Parameters „post_max_size = 8M”, wenn es nicht erforderlich ist, große Dateien hochzuladen. Der Wert des Parameters „upload_max_filesize” sollte kleiner sein als der Parameter „post_max_size”.
• Festlegung einer Obergrenze für den zulässigen Speicherverbrauch auf Systemebene über cgroup memory.max oder Container-Speicherverbrauchsparameter, jedoch nicht über die Systemlimits RLIMIT_AS und RLIMIT_DATA, die lediglich den problematischen Aufruf von longjmp() hervorrufen.
• 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.
• Festlegung auf Ebene der php.ini oder Konfiguration, Server nicht über ini_set() oder FPM .user.ini, da der Parameter vor Beginn der Anfragebearbeitung wirksam sein muss; „session.upload_progress.enabled=0”.
• Bei Verwendung von PHP 8.5 sollte der Parameter „fatal_error_backtraces=0” festgelegt werden.
• Entfernung von an einzelnen Anfragen gebundenen veralteten oder fehlerhaften Einstellungen (wie assert.* und falsche Pfade in open_basedir), die dazu führen, dass diagnostische Nachrichten vor der Initialisierung ausgegeben werden.
• Beseitigung von Situationen im PHP-Code, die zu Timeouts und fatalen Fehlern führen, z. B. im Zusammenhang mit Fehlern in Callback-Handlern und der Verarbeitung von Uploads.
• Um die erste Schwachstelle im Code alter PHP-Versionen zu blockieren, kann der Aufruf von longjmp() im Handler für den Speicherüberlauf durch _exit() ersetzt werden.
• Zusätzlich kann der Wert des Parameters max_input_nesting_level in der php.ini verringert und multipart-Anfragen blockiert werden, wie im vorherigen Ankündigung gezeigt.

Der Status der Behebung von Schwachstellen in den Distributionen kann auf den folgenden Seiten bewertet werden: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

Zusatz 1: Schwachstellen wurden mit Hilfe von AI-Modellen GPT‑5.6 und Gemini 4 Argon identifiziert. OpenAI hat ein Tool namens php2shell-checker veröffentlicht, um die Anfälligkeit von Websites und lokal ausführbaren Dateien gegenüber Schwachstellen zu überprüfen. Dieses Tool überprüft jedoch lediglich die PHP-Version, die vom HTTP-Server oder dem Befehl „php -v“ zurückgegeben wird, ohne eine detaillierte Analyse.

Zusatz 2: Der Autor des Prototypen eines Exploits, der eine durch doppelte Speicherfreigabe (double-free) verursachte Schwachstelle nutzt, hat berichtet, dass das Problem in der Version PHP 8.5.12 weiterhin nicht behoben ist und der Exploit weiterhin funktioniert. Zuvor hatten Vertreter von PHP erklärt, dass diese Schwachstelle nicht mit den bevorstehenden Korrekturen zusammenhängt und kein echtes Problem darstellt. Der Autor des Exploits behauptete jedoch, dass es sich um eine ganz andere Schwachstelle handelt.

Quelle: opennet.ru