PHP2Shell war seit 2024 bekannt. Was der Fall über Coordinated Disclosure, Zero-Days und modernes Schwachstellen- und Supply-Chain-Management lehrt.
Wenn Begriffe wie „CVSS 9.8“ und „kritische Software-Schwachstelle“ plötzlich in der Tagesschau statt nur in Dependabot oder Trivy auftauchen, weiß man: Deutschland ist im Ausnahmezustand. Nachdem am Mittwoch tausende Webseiten von Behörden, öffentlichen Einrichtungen und privaten Unternehmen zeitweise vom Netz gehen mussten, wird das gesamte Ausmaß erst jetzt klar.
Denn PHP2Shell war nicht nur ein massiver Vorfall für die IT-Sicherheit, sondern ein Lehrbuchbeispiel dafür, wie radikal sich die Sicherheit der Software-Lieferkette verändert hat.
Die zugrundeliegende Schwachstelle war seit 2024 bekannt, wurde vom PHP-Team jedoch ignoriert – bis KI-Modelle jüngst zeigten, wie sie sich praktisch ausnutzen lässt. Daraufhin wurde unter Hochdruck ein Patch entwickelt, mit dem Plan, das Update kontrolliert am Mittwoch zu veröffentlichen.
Wieso am Ende alles anders kam, was uns die Fehlerkette rund um PHP2Shell über moderne CVE-Disclosure lehrt und was die aktuelle Zero-Day-Flut für unser Schwachstellen-Management bedeutet, erklären wir in diesem Beitrag.
Zwei Jahre bekannt, erst durch KI als ausnutzbar nachgewiesen
Die ersten Anzeichen des Speicherfehlers hinter CVE-2026-109618 entdeckte ein PHP-Core-Entwickler bereits 2024 bei der Behebung eines anderen Befunds aus einem Quarkslab-Audit – finanziert worden war dieses Audit damals ausgerechnet durch die deutsche Sovereign Tech Agency.
Eine mögliche Ausnutzung wurde zwar diskutiert, ein konkreter Angriffsweg war jedoch nicht nachgewiesen. Lösungsversuche gab es durchaus, doch sie scheiterten immer wieder an Problemen mit der Abwärtskompatibilität, möglichen neuen Sicherheitsrisiken und notwendigen Anpassungen an PHP-Erweiterungen. Die Arbeiten gerieten in den Konsens-Prozessen wiederholt ins Stocken, sodass das bekannte Speicherproblem fast zwei Jahre lang ungelöst blieb – ein Umstand, den die PHP Foundation in ihrer Aufarbeitung heute selbst als „strukturelles Versagen“ bezeichnet.
Im August 2026 zeigte KI-gestützte Sicherheitsforschung schließlich, wie sich der Fehler praktisch ausnutzen lässt: Calif meldete am 11. August eine Remote Code Execution ohne vorherige Authentifizierung (Pre-Auth RCE). OpenAI stieß unabhängig davon auf dieselbe Ursache, während Wiz und OpenAI kurz darauf weitere Angriffsvektoren nachlieferten. Erst jetzt wurde das volle Schadenspotenzial deutlich und die Behebung zur höchsten Priorität.
Damit steht auch eine verbreitete Annahme im Schwachstellen-Management auf dem Prüfstand: Ein Fehler, dessen Ausnutzung heute noch unrealistisch erscheint, kann morgen mit besseren Werkzeugen zum konkreten Angriffspfad werden.
Warum das Modell der Coordinated Disclosure zerbricht
Um das Chaos vom Mittwoch zu verstehen, muss man sich den geplanten Ablauf einer Coordinated Disclosure vor Augen führen: Nach der Meldung entwickeln die Maintainer im Stillen ein Update, verteilen es vorab unter striktem Embargo an Distributoren und veröffentlichen Patch sowie Warnung zu einem exakt abgestimmten Zeitpunkt.
Wie ich bereits im Juli in meinem Gastbeitrag bei Security-Insider zum „bikini/exploitarium“-Repository ausführlich erklärt habe, bricht dieser koordinierte Prozess durch den massiven KI-Einsatz auf beiden Seiten der Barrikade gerade zusammen. Schon im Sommer tauchten über KI-gestützte Workflows plötzlich 23 fertige Exploits – unter anderem für PHP, libssh2 und FFmpeg – im Netz auf, noch bevor es überhaupt ein CVE oder ein Advisory gab.
Bei PHP2Shell kam zum technologischen Druck noch ein komplettes Versagen in der Abstimmung hinzu.
Das Problem der Zero-Days
Das Szenario einer Zero-Day-Vulnerability – also einer Schwachstelle, für die es noch keinen Patch gibt und die dafür sorgt, dass ganze Systeme vom Netz genommen werden müssen – ist zwar den meisten ITlern zumindest in der Theorie bekannt. In der Praxis und in solch einem Ausmaß haben es bisher aber nur die wenigsten real erlebt.
Schaut man sich aktuelle Zahlen an, lässt sich leider befürchten, dass ein Szenario wie PHP2Shell in Zukunft häufiger auftreten wird: Allein in den letzten 12 Monaten hat sich die Anzahl der monatlichen Zero-Day-Vulnerabilities mehr als vervierfacht. Wie wir in Zukunft mit dem Szenario einer Zero-Day-Vulnerability umgehen, wie sich die Prozesse rund um Meldung und Triage optimieren lassen und ob es wirklich nötig ist, immer gleich ganze Anwendungen vom Netz zu nehmen, wollen wir in diesem Blogpost beleuchten.
Wie Farion modernes Schwachstellen-Management unterstützt
Ein Vorfall wie PHP2Shell zeigt deutlich, dass punktuelle Scans in der Pipeline nicht mehr ausreichen, wenn zwischen Patch-Leak und ersten Angriffswellen nur Minuten liegen. Wir entwickeln Farion, um Entwicklungs- und Security-Teams genau für diese Dynamik im Schwachstellen- und Supply-Chain-Management auszurüsten:
- Kontinuierliche Echtzeit-Überwachung & Warnung: Anstatt auf den nächsten Build oder Commit zu warten, gleicht Farion die SBOM laufender Systeme permanent im Hintergrund mit aktuellen Schwachstellen-Datenbanken ab und schlägt sofort Alarm, sobald ein neues CVE veröffentlicht wird.
- KI-gestütztes Patching: Wenn wie bei PHP2Shell jede Minute zählt, unterstützt Farion Teams dabei, notwendige Updates und Patches KI-gestützt vorzubereiten und schnellstmöglich in den Code einzuspielen.
- Reachability-, Dataflow- und Ausnutzbarkeits-Analyse für Software-Schwachstellen: Farion prüft über Code- und Datenfluss-Analysen automatisch die Erreichbarkeit (dokumentiert über VEX). So lässt sich im Tagesgeschäft schnell trennen, welche Schwachstellen tatsächlich von Angreifern ausgenutzt werden können und welche das eigene System nicht betreffen.