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

Es wurden Korrekturversionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht sowie Patches für die bereits 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 – Fernzugriff zur Ausführung von Code, verursacht durch eine Erschöpfung des verfügbaren freien Speichers des Prozesses, bei der der Speicherengpass-Handler durch das Aufrufen der Funktion longjmp() den PHP-Interpreter in einem Zustand beenden kann, in dem nur ein Teil der internen Strukturen, die mit der Anfragebearbeitung in Verbindung stehen, initialisiert ist. Im Anschluss darauf greift die Funktion zur Anfrageverarbeitung auf diese Strukturen zu, als wären sie bereits initialisiert, obwohl der Speicher für sie nicht zugewiesen wurde.

  Der Hauptangriffsvektor besteht darin, mit multipart-Anfragen zu manipulieren, um Bedingungen zu schaffen, die zu einer Erschöpfung des verfügbaren Speichers im Prozess führen. Um das Limit post_max_size zu umgehen, kann der Header Content-Length weggelassen und eine enorme 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. Die Existenz eines Exploits wurde für mod_php bestätigt, da es die Funktion shutdown() selbst bei einem Fehler aufruft. PHP-FPM beendet im Fehlerfall den Kindprozess, was einen Angriff erschwert, aber theoretisch nicht ausschließt.

• CVE-2026-109619 – Fernzugriff zur Ausführung von Code, verursacht durch den Zugriff auf den Speicher nach dessen Freigabe, aufgrund einer fehlerhaften Bereinigung des globalen Zustands, der an eine bestimmte Anfrage gebunden ist. Im Falle einer Unterbrechung der Anfrage aufgrund eines kritischen Fehlers, eines Timeouts oder einem Speichermangel kann der globale Zustand möglicherweise nicht zurückgesetzt werden, und die Pointer bleiben aktiv, obwohl der Speicher, auf den sie verweisen, freigegeben wurde. Bei der Bearbeitung der nächsten Anfrage im selben Prozess kann es zu einem Zugriff über den verbleibenden Pointer auf den alten globalen Zustand kommen.

  Für die Nutzung kann es erforderlich sein, Bedingungen zu schaffen, die zu einem Erschöpfen des verfügbaren Speichers beim Verarbeiten von Multipart-Anfragen im Code zur Indikation des Upload-Fortschritts (session.upload_progress) führen. Dabei wird der Handler fatal_error_backtraces in PHP 8.5 als primärer und bestätigter Angriffsvektor erwähnt, der den Zustand des Backtrace 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. Zudem wird eine nicht bestätigte Möglichkeit eines Angriffs in Konfigurationen erwähnt, deren Einstellungen dazu führen, dass Warnungen frühzeitig während der Anfrageverarbeitung ausgegeben werden (z. B. Warnungen über die Verwendung veralteter Parameter).

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

• Setzen des Parameters «memory_limit=-1» in php.ini, was es dem Angreifer erschwert, die Ausschöpfung der Speicherlimits zu kontrollieren.
• Setzen des Parameters «post_max_size = 8M», wenn keine Notwendigkeit besteht, große Dateien hochzuladen. Der Wert des Parameters «upload_max_filesize» sollte geringer sein als der Parameter «post_max_size».
• Festlegung eines maximalen Speichernutzungsgrenzwerts auf Systemebene über cgroup memory.max oder die Speichernutzungsparameter des Containers, jedoch nicht über die Systemgrenzen RLIMIT_AS und RLIMIT_DATA, die nur problematische Aufrufe von longjmp() verursachen.
• Wenn die Leistung nicht entscheidend ist, kann die Anzahl der Anfragen, die von einem einzigen Worker-Prozess verarbeitet werden, über pm.max_requests=1 in PHP-FPM und MaxRequestsPerChild in Apache httpd begrenzt werden.
• Setzen in php.ini oder Konfiguration Server (nicht über ini_set() oder FPM .user.ini, da der Parameter vor Beginn der Anfrageverarbeitung gelten sollte) des Parameters «session.upload_progress.enabled=0».
• Bei Verwendung von PHP 8.5 sollte der Parameter «fatal_error_backtraces=0» gesetzt werden.
• Entfernung von an einzelne Anfragen gebundenen veralteten oder fehlerhaften Einstellungen (wie assert.* und falsche Pfade in open_basedir), die zur Ausgabe von Diagnosen vor der Initialisierung führen.
• Beseitigung von Situationen im PHP-Code, die zu Timeouts und kritischen Fehlern führen, z. B. im Zusammenhang mit Ausfällen in Callback-Handlern und der Verarbeitung von Uploads.
• Um die erste Sicherheitsanfälligkeit in älteren PHP-Versionen zu blockieren, kann der Aufruf von longjmp() im Speichererschöpfungs-Handler 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 in der vorab angekündigten Mitteilung gezeigt.

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

Zusatz 1: Sicherheitsanfälligkeiten wurden mit KI-Modellen wie GPT‑5.6 und Gemini 4 Argon aufgedeckt. OpenAI hat das Tool php2shell-checker veröffentlicht, um die Anfälligkeit von Websites und lokal ausführbaren Dateien zu überprüfen. Dieses Tool prüft lediglich die von dem HTTP-Server oder dem Befehl „php -v“ zurückgegebene PHP-Version, ohne eine detaillierte Analyse durchzuführen.

Zusatz 2: Der Autor des Prototyp-Exploits, der die durch doppelte Freigabe von Speicher (double-free) verursachte Schwachstelle nutzt, hat mitgeteilt, dass das Problem in der Version PHP 8.5.12 weiterhin nicht behoben ist und der Exploit weiterhin funktioniert. Zuvor hatten PHP-Vertreter erklärt, dass diese Schwachstelle nicht mit den bevorstehenden Korrekturen in Zusammenhang steht und kein echtes Problem darstellt. Der Autor des Exploits hingegen behauptete, es handele sich um eine völlig andere Sicherheitsanfälligkeit.

Quelle: opennet.ru