Die Geschichte von CVE-2026-109618 reicht laut der Stiftung bis 2024 zurück, als PHP erstmals seit mehreren Jahren wieder ein externes Sicherheitsaudit durchlief. Damals wurde keine Maßnahme ergriffen. Intern führte das Problem zu Kontroversen: Entwickler stritten über den richtigen Weg, wobei Bedenken von Brüchen der Rückwärtskompatibilität über neues Potenzial für Denial-of-Service bis zu Änderungen an zahlreichen Drittanbieter-Erweiterungen reichten, deren Koordination unmöglich erschien.
„Das PHP-Sicherheitsteam, das im Konsens arbeitet, tat sich schwer mit der Wahl zwischen diesen Optionen und fürchtete die Folgen, die falsche Entscheidung auszuliefern", erklärte die gemeinnützige Stiftung. „Zusammen mit dem Fehlen eines bekannten Wegs zur Remote-Code-Ausführung und dem kleinen Kreis an Kernentwicklern mit dem nötigen tiefen Wissen über die Engine, die mit vielen Aufgaben ausgelastet waren, führte dieser Entscheidungsprozess dazu, dass die Arbeit an einem Fix über Monate hinweg immer wieder ins Stocken geriet und neu anlief."
Am Mittwoch nahmen Unternehmen und Behörden Hunderte Websites wegen CVE-2026-109618 und der verwandten Lücke CVE-2026-109619 vom Netz. Teilweise werden beide gemeinsam als PHP2Shell bezeichnet. Nach manchen Schätzungen setzen mehr als 70 Prozent aller Websites im Internet PHP ein. Der Internet-Infrastrukturanbieter Cloudflare berichtete von beobachteten Ausnutzungsversuchen.
„Ihre zentrale Stellung in PHP ist es, was beide Schwachstellen so ernst machte — und zugleich so schwer zu beheben, ohne Kompatibilität zu brechen, die Performance zu beeinträchtigen oder dem großen Ökosystem an Drittanbieter-Erweiterungen Änderungen aufzuzwingen", so die Stiftung.
Eine Analyse von VirusTotal identifizierte 5,1 Millionen IP-Adressen, auf denen PHP läuft. Mindestens 758.000 IP-Adressen wiesen PHP-Versionen auf, die das Ende ihres Lebenszyklus erreicht haben, 85.000 IP-Adressen liefen mit den aktuellsten PHP-Releases, die vor den Notfall-Patches am Mittwochmorgen verfügbar waren. Diese Zahlen beschreiben die zum Internet hin sichtbare Verbreitung von PHP, nicht bestätigt verwundbare Systeme. Die Patches decken nur Versionen ab PHP 8.2 zurück ab; ältere Versionen erhalten vom PHP-Projekt keine Updates mehr. Cisco Talos veröffentlichte Schätzungen, wonach rund 50 Prozent der verwundbaren PHP-Systeme möglicherweise keinen Patch erhalten werden.
KI-Audits rücken die Fehler ins Licht
Nachdem man sich 2024 gegen eine Reaktion entschieden hatte, wurde die PHP Foundation mit dem Aufkommen leistungsfähiger KI-gestützter Code-Review-Werkzeuge erneut mit dem Problem konfrontiert. Dienste von Anthropic und OpenAI wurden im Lauf dieses Jahres eingesetzt, um PHP-Plattformen zu durchsuchen. Am 11. August meldete schließlich ein Forscher der Sicherheitsfirma Calif die Fehler. In sozialen Medien schrieb Calif die ursprüngliche Entdeckung der Schwachstelle und die Entwicklung eines Exploits zudem einem weiteren Forscher zu. Auch OpenAI sowie die Sicherheitsunternehmen Wiz und Trail of Bits fanden dieselben Schwachstellen bei Audits von PHP.
Diese Meldungen hätten „das volle Ausmaß des Problems deutlich gemacht, und ab dem 11. August wurde dessen Behebung zur obersten Priorität für das gesamte mit Sicherheit befasste Team der PHP Foundation", erklärte die Stiftung.
Der Prozess der koordinierten Offenlegung sei reibungslos verlaufen, bis vor zwei Tagen in sozialen Medien Gerüchte über die Fehler aufkamen. Die Stiftung zog die Veröffentlichung um einen Tag vor, betonte aber, dass eine sofortige Freigabe nicht möglich gewesen sei, weil der Fix noch paketiert wurde.
Calif habe „versehentlich ein Video veröffentlicht", das den Proof of Concept gegen mehrere Ziele in Aktion zeigte und weitere Details zu den Schwachstellen preisgab. Das Video kursierte auch nach seiner Löschung weiter und „beschleunigte die Entwicklung" von Exploit-Proof-of-Concepts. Die PHP Foundation beobachtete im Lauf des Dienstagabends mehrere der kursierenden PoCs, konnte darunter aber keinen funktionsfähigen Exploit ausmachen.
Im Blogbeitrag heißt es weiter, das Sicherheitsunternehmen Chainguard habe am frühen Mittwoch eigenmächtig das Embargo gebrochen und Images mit dem Fix veröffentlicht. Chainguard reagierte nicht auf Anfragen zu diesen Vorwürfen. „Wie andere Distributoren hatte Chainguard den Patch vorab erhalten, damit seine Nutzer im Moment der Offenlegung aktualisieren können", so die Stiftung. „Jeder Angreifer konnte den Fix nun in Binärform studieren, während alle anderen PHP-Nutzer noch auf das Release warteten. Das setzte sich über wochenlange Arbeit vieler Beteiligter an einer koordinierten Offenlegung hinweg."
Die PHP Foundation listete Dutzende Änderungen an ihren internen Strukturen auf, die eine Wiederholung einer solchen Situation verhindern sollen. Eine schwerwiegende Schwachstelle, deren Fix an schwierigen Abwägungen hängt, würde die Führung der PHP Foundation künftig „deutlich früher" erreichen.