PHP schließt zwei kritische Sicherheitslücken in vier neuen Releases

Von Nokka (นก-กา) | Faktenprüfung 24. Oktober 2026

Dieser Artikel wurde von einer KI verfasst (deepseek-v4.1-flash · Modellanbieter: ollama-cloud) über den Hermes Agent, unter menschlicher Kontrolle und Qualitätssicherung durch Nokka (นก-กา).

Am 21. Oktober 2026 veröffentlichte das PHP-Team vier neue Versionen, um zwei kritische Sicherheitslücken zu schließen, durch die Angreifer unter bestimmten Bedingungen Code auf Servern ausführen konnten.

Mich interessierte weniger die Schwachstelle selbst als vielmehr der 20. Oktober, also zwei Tage vor dem ursprünglich geplanten Termin und einen Tag vor der tatsächlichen Veröffentlichung, an dem der Ankündigungsplan nach und nach auseinanderfiel.

Dieser Fall ist eine gute Fallstudie zur koordinierten Offenlegung in einer Zeit, in der KI-Werkzeuge es Menschen ermöglichen, Schwachstellen viel schneller zu finden, sodass die bisherigen Zeitrahmen nicht mehr ausreichen.

Beide Schwachstellen haben einen CVSS-Score von 9.2 und wurden als kritisch eingestuft.

CVE-2026-109618 entsteht durch einen Speichermangel im ungünstigsten Moment. Trifft eine Anfrage exakt auf die memory_limit-Grenze, kann PHP unvollständig initialisierte interne Daten verwerfen und sie später dennoch als gültig behandeln.

Die Folge ist eine Speicherkorruption, und auf Apache mit mod_php kann ein nicht authentifizierter Angreifer dies auslösen, noch bevor der Anwendungscode überhaupt startet; eine vollständige Codeausführung wurde bereits mit Standardeinstellungen demonstriert.

CVE-2026-109619 beruht auf einem verbleibenden globalen Zustand. Tritt ein fatal error im falschen Moment auf, kann der interne Zustand noch auf den Speicher einer vorherigen Anfrage zeigen, und die nächste Anfrage, die derselbe Worker verarbeitet, nutzt dann bereits freigegebenen Speicher.

Dem Berichterstatter gelang die Demonstration einer Remote-Code-Ausführung an einer echten Anwendung auf Apache mod_php.

Das PHP-Team gab außerdem an, dass sich auch bei PHP-FPM eine Codeausführung bestätigen lässt, und zwar über einen Pfad auf Anwendungsebene, nicht nur bei mod_php.

Was diese beiden Schwachstellen so besorgniserregend macht, ist, dass sie sich in Bereichen befinden, die praktisch jede Anfrage berührt: der Speicherverwaltung und der Fehlerbehandlung, nicht in einem Plugin oder einer optionalen Bibliothek.

Ursprünglich war die Veröffentlichung für den 22. Oktober 2026 um 14:00 UTC geplant, was 21:00 Uhr unserer Ortszeit entspricht.

Am 20. Oktober gegen 15:00 UTC postete jemand die beiden CVE-Nummern in Foren und sozialen Medien, mit falschem Veröffentlichungszeitpunkt und einem falschen CVSS-Score von 10.0, tatsächlich liegt er bei 9.2.

Die gute Nachricht: In dieser Runde waren noch keine technischen Details durchgesickert.

Am 20. Oktober um 19:30 UTC entschied sich das PHP-Team, die Ankündigung vorzuziehen und den Veröffentlichungstermin vom 22. Oktober auf den 21. Oktober zur selben Uhrzeit zu verlegen.

Der Grund, nur um einen Tag zu verschieben und nicht sofort zu veröffentlichen: Die Distributoren hatten ihre Pakete noch nicht fertig. Bei einer sofortigen Veröffentlichung hätten viele Nutzer keine einfache Update-Möglichkeit gehabt.

Am 20. Oktober gegen 20:00 UTC veröffentlichte das Sicherheitsunternehmen Calif, eines der meldepflegenden Teams, versehentlich ein Video. Das Video zeigte ein funktionierendes PoC gegen mehrere Ziele und enthüllte einige zusätzliche Details.

Das Video wurde gelöscht, doch Kopien verbreiteten sich in den sozialen Medien und beschleunigten die Entwicklung weiterer PoCs durch andere bis zum 21. Oktober.

Am 20. Oktober gegen 23:00 UTC gelangten möglicherweise auch die Abhilfeempfehlungen an die Öffentlichkeit, die das PHP-Team an einige kritische Infrastrukturbetreiber verschickt hatte.

Am 21. Oktober um 07:41 UTC veröffentlichte Chainguard bereits gepatchte Images öffentlich, mehr als sechs Stunden vor der offiziellen Ankündigung.

Chainguard hatte wie andere Distributoren vorab Patches erhalten, damit seine Nutzer sofort bei der Ankündigung aktualisieren konnten.

Doch die vorzeitige Veröffentlichung der Images bedeutete, dass jeder die gepatchten Binärdateien untersuchen und den Patch analysieren konnte, während andere PHP-Nutzer noch auf den Ankündigungstermin warteten.

Die PHP Foundation erklärte, dieses Vorgehen stelle eine einseitige Brechung der Embargofrist dar und missachte die Arbeit mehrerer Wochen aller Beteiligten.

Aus meiner Sicht ist das der klassische Weg, wie eine Timeline durchsickert: Es braucht gar keine technischen Details, es genügt etwas bereits Gepatchtes zum Vergleich.

Das PHP-Team erklärte, dass es zum Zeitpunkt der Ankündigung noch kein aus den durchgesickerten PoCs funktionierendes, echtes Exploit gefunden habe.

Doch das Wort "noch nicht gefunden" bedeutet nicht, dass es niemandem gelingen kann, und sollte nicht als Vorwand dienen, das Update aufschieben.

Dieser Abschnitt ist aus meiner Sicht der mutigste Teil der Ankündigung, denn das PHP-Team schrieb selbst, dass "die Verzögerung ein strukturelles Versagen war".

Zurück ins Jahr 2024: Damals gab es die erste externe Sicherheitsprüfung seit vielen Jahren, finanziert von der Sovereign Tech Agency, organisiert über OSTIF und durchgeführt von Quarkslab.

Bei der Behebung eines der von Quarkslab gemeldeten Probleme entdeckte ein von der Foundation finanzierte Hauptentwickler erste Anzeichen des OOM-Problems, das später zu CVE-2026-109618 wurde.

2024 ging man von der Hypothese aus, dass dieses Problem angreifbar sei, doch es gab noch keinen realen Angriffspfad, und andere, deutlichere Probleme verdeckten es.

Die Behebung erforderte eine Wahl zwischen einem Weg mit Einbußen bei der Abwärtskompatibilität, dem Öffnen einer neuen Denial-of-Service-Lücke oder dem Zwang, dass Drittanbieter-Erweiterungen ihren Code anpassen, was praktisch unmöglich zu koordinieren war.

Das Sicherheitsteam entschied sich im Konsens für keine der Optionen richtig, und die Arbeit stockte über Monate hinweg.

Die Wende kam, als fast zeitgleich mehrere Berichte eingingen.

Seit dem 11. August wurde die Behebung des OOM-Problems zur wichtigsten Aufgabe aller Mitglieder des Sicherheitsteams der Foundation.

Wiz gab dem Skript, das beide Schwachstellen kombiniert, den Namen php2root und wies darauf hin, dass PHP rund 70 Prozent des Webs weltweit betreibt und jede Version des letzten Jahrzehnts mindestens eine solche Schwachstelle aufwies, bis zurück zu 5.4.

Wiz schrieb, dass diese Gruppe von Schwachstellen seit über einem Jahrzehnt im PHP-Code verborgen liegt, doch der Nachweis der Angreifbarkeit erforderte eine so komplexe Abfolge von Schritten, dass sie am Rand dessen lag, was menschliche Forscher real leisten konnten.

Führende KI-Modelle haben diese Hürde gesenkt, sodass aus einem alten Problem ein funktionierendes Exploit wurde.

Auch PHP nutzt selbst KI, sowohl beim Scannen mit Claude Mythos gemeinsam mit Alpha-Omega als auch mit dem Werkzeug Daybreak Red von OpenAI zur Prüfung von Berichten gegen PoCs.

Ein Nebeneffekt ist die stark gestiegene Zahl eingehender Berichte. Das Team gab an, seit dem 1. Juli über 100 Berichte erhalten zu haben, die sich als Duplikate, nicht reproduzierbar oder als gar keine echten Schwachstellen herausstellten.

Die KI kann Berichte mit derselben Ursache gruppieren, aber Menschen entscheiden jedes Mal und Menschen schreiben jeden einzelnen Patch.

Das ist die Gleichung, die meines Erachtens alle großen Projekte derzeit erleben: Die Werkzeuge finden Bugs günstiger und schneller, aber die Zahl der Menschen, die Entscheidungen treffen, bleibt gleich.

Die Teams passen ihre Reaktionsprozesse an, damit die Leitung der Stiftung schneller in Entscheidungen einbezogen werden kann, wenn Schwachstellen auftreten, deren Behebung mit schwerwiegenden Trade-offs verbunden ist.

Davor hatte sich in diesem Jahr bereits einiges ereignet.

Die korrigierten Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

# Die tatsächlich laufende Version prüfen, einschließlich der genutzten SAPI php -v php -i | grep -i "server api" # Debian / Ubuntu apt list --installed 2>/dev/null | grep -E "^php[0-9.]+" # RHEL-Familie rpm -qa | grep -E "^php" Wenn das Ergebnis Apache 2.0 Handler lautet, verwenden Sie mod_php, also genau den Weg, über den der Meldende demonstriert hat, dass ein Angriff bereits vor dem Ausführen des Anwendungscodes möglich ist.

Am besten aktualisiert man das gesamte System und startet dann Apache oder PHP-FPM neu, damit die Worker den neuen Code laden, denn das bloße Patchen von Dateien ändert nichts an den bereits laufenden Prozessen.

Als ich diese Ankündigung las, dachte ich an eine Frage, über die oft gestritten wird: Ist ein Embargo eine Frage der Etikette oder eine Frage der Sicherheit?

Dieser Fall zeigt, dass es beides ist, und dass es viele verwundbare Stellen gibt, die sich schwer kontrollieren lassen.

Alle drei dieser Wege entstehen nicht aus Böswilligkeit, sondern aus den ganz normalen Anreizen jeder beteiligten Seite.

Die Frage, auf die ich noch keine Antwort habe, lautet: Wenn die KI es den Menschen jedes Jahr ermöglicht, Schwachstellen schneller zu finden und zu belegen, wird das bisherige Embargo-Modell dann noch genügen, oder müssen wir zu einem Verfahren übergehen, das akzeptiert, dass Informationen immer leaken, und so gestaltet wird, dass der Schaden beim Leaken möglichst gering ausfällt?

Das könnte bedeuten, Patches schneller an die Distributoren auszuliefern, vorher aber eine kurze Erklärung zu veröffentlichen, damit Nutzer informiert sind und ihre Aktualisierungswege vorbereiten können.

Oder es könnte bedeuten, nicht mehr davon auszugehen, dass gepatchte Binärdateien geheim sind, weil sie sich ohnehin rückrechnen lassen.

Ich habe noch niemanden gesehen, der diese Frage klar beantwortet, und ich glaube, dass dies eine der großen Aufgaben der kommenden Jahre sein wird.

The PHP Foundation (21. Okt. 2026) · Today's PHP Security Release, and How We're Strengthening PHP Security. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ NVD (21. Okt. 2026) · CVE-2026-109618 CVSS 4.0 base 9.2 critical. https://nvd.nist.gov/vuln/detail/CVE-2026-109618 Wiz Research (21. Okt.

2026) · PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. https://www.wiz.io/blog/php2shell-php-rce php.net (21. Okt. 2026) · Security advisory: Critical remote code execution vulnerabilities, update now (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35). https://www.php.net/archive/2026.php#2026-10-21-5 GitHub Security Advisory (21. Okt. 2026) · GHSA-w8hw-w9fx-j79w (RCE via OOM corruption). https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w GitHub Security Advisory (21. Okt.

2026) · GHSA-6wmf-4rv5-p3rp (RCE via stale global state). https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp NVD (21. Okt. 2026) · CVE-2026-109619 CVSS 4.0 base 9.2 critical. https://nvd.nist.gov/vuln/detail/CVE-2026-109619