Michael JohnsonAm 21. Oktober 2026 meldete PHP zwei kritische Schwachstellen, die eine nicht authentifizierte Remote-Code-Ausführung ermöglichen könnten. Noch am selben Tag veröffentlichte das Projekt Korrekturen für die Zweige 8.5, 8.4, 8.3 und 8.2 und empfahl den Nutzern, unverzüglich zu aktualisieren. Betroffen sein können Installationen, die Webanfragen verarbeiten, darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed, teilt PHP mit.
Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Releases beheben CVE-2026-109618, die mit einer Beschädigung des Zustands bei Speichermangel zusammenhängt, sowie CVE-2026-109619 – einen Fehler, durch den der Zustand einer Anfrage im Worker-Prozess verbleiben und bei der Verarbeitung der nächsten Anfrage verwendet werden konnte. Ältere Versionen als die aufgeführten sind betroffen. Für PHP 8.1 und ältere Zweige veröffentlicht das Projekt keine eigenen Updates mehr. Administratoren solcher Systeme sollten daher prüfen, ob der Distributor oder ein LTS-Anbieter Korrekturen bereitstellt.
Zwei Fehler im Lebenszyklus von Webanfragen
Bei CVE-2026-109618 kann die Verarbeitung einer Anfrage wegen Speichermangels abgebrochen werden, bevor interne Daten vollständig initialisiert wurden. Beim Beenden kann PHP anschließend auf einen ungültigen Zustand zugreifen. In der Sicherheitsmeldung beschreiben die Entwickler unter anderem Szenarien mit Multipart-Anfragen und ausgeschöpftem Speicherlimit. Für Apache mod_php ist ein Szenario bestätigt, bei dem das Problem noch vor dem Start des Anwendungscodes auftritt; PHP weist außerdem darauf hin, dass das Risiko bei dieser Konfiguration höher ist.
CVE-2026-109619 betrifft den Zustand, den ein Worker-Prozess zwischen Anfragen beibehält. Wird ein Vorgang vor der Bereinigung der Daten mit einem Fehler beendet, wird der Speicher der vorherigen Anfrage freigegeben, während ein Verweis darauf bestehen bleibt. Die nächste Anfrage, die im selben Prozess landet, kann vor der regulären Initialisierung auf diesen veralteten Zustand zugreifen. In der Sicherheitsmeldung des Projekts beschreibt PHP bestätigte Angriffspfade über frühe Diagnosevorgänge und die Verarbeitung des Upload-Fortschritts. Ob ein bestimmter Pfad anwendbar ist, hängt von der Konfiguration, der Anwendung und den verwendeten Erweiterungen ab.
Beide Schwachstellen erhielten eine Bewertung von 9,2 nach CVSS 4.0. PHP zufolge umfasst die bestätigte Auswirkung die Ausführung von Code mit den Berechtigungen des Web-Workers. Für den Speichermangel-Fehler bestätigt die Sicherheitsmeldung ein vollständiges HTTP-Szenario gegen mod_php. Für PHP-FPM beschreibt die Quelle eine Codeanalyse und Bedingungen, unter denen die Konfiguration anfällig ist. Bei der Bewertung einer konkreten Bereitstellung ist dieser Unterschied wichtig.
Was Administratoren prüfen sollten
Ermitteln Sie zunächst die PHP-Versionen, die tatsächlich Webverkehr verarbeiten: Auf einem Server können separate CLI-, FPM- und Apache-Builds laufen, während Container und Clusterknoten unabhängig voneinander aktualisiert werden. Installieren Sie für jeden unterstützten Zweig das entsprechende korrigierte Release oder ein Anbieterpaket mit bestätigtem Patch. Starten Sie anschließend alle PHP-Worker neu und prüfen Sie ihre Version nach dem Neustart – werden lediglich Dateien ersetzt, laufen die alten Prozesse ohne Neustart weiter.
Prüfen Sie für PHP 8.1 und ältere Versionen den Supportstatus und ob der Distributor oder ein LTS-Anbieter ein Backport bereitstellt. Gibt es kein solches Paket, planen Sie den Wechsel zu einem unterstützten Zweig. PHP zufolge haben Linux-Distributoren die Patches im Voraus erhalten. Die Paketversionsnummer kann von der offiziellen PHP-Version abweichen; prüfen Sie daher gezielt, ob die Korrektur enthalten ist.
Übergangseinstellungen und das Filtern von Anfragen können einzelne Angriffswege einschränken, doch das Projekt bezeichnet ein Update als einzige vollständige Lösung für beide Probleme. Für Teams hat daher die Bestandsaufnahme aller Web-Worker, die Installation des korrigierten Pakets, der Neustart der Prozesse und die Überprüfung auf jedem Knoten praktische Priorität. So werden die bestätigten Schwachstellen behoben, statt sich allein auf die Konfiguration des Webservers zu verlassen.