
KI und Sicherheitslücken: Was PHP2Shell über das neue Tempo zeigt
Am 21.10.2026 schloss das PHP-Projekt zwei kritische Fehler, bekannt als PHP2Shell. Der Fall zeigt, wie KI Sicherheitslücken schneller sichtbar macht, für Forscher und für Angreifer. Die Entdecker von Wiz nennen KI-Modelle ein zentrales Werkzeug. Das BSI rechnete mit Angriffen wenige Stunden nach dem Update, weil Angreifer die Patches mit KI-Werkzeugen schnell auswerten können.
Stand: 22.10.2026, 01:00 MESZ. Die Lage zu PHP2Shell ändert sich noch. Die Quellen sind jeweils verlinkt.
Welche Rolle spielte KI bei der Entdeckung von PHP2Shell?
Bei Wiz Research eine große. Das Team nutzte nach eigener Angabe die Modelle Gemini 4 Argon und GPT-5.6 Sol sowie das eigene Werkzeug Wiz Atlas. Gemini 4 Argon habe wesentlich zum Finden der Lücke beigetragen. Auch der Melder Calif setzte bei seiner Analyse ein Sprachmodell und KI-Agenten ein.
PHP2Shell steht für zwei Fehler im Speicher von PHP. Über sie lässt sich ohne Login Code auf dem Webserver ausführen. Betroffen sind PHP-Versionen vor den Updates vom 21.10.2026, auch ältere Zweige wie 7.4 bis 8.1. Die Hintergründe und Prüfschritte zu PHP2Shell stehen auf einer eigenen Seite.
Laut Bericht von Wiz fand das Team den ersten Fehler am 19.08.2026. Einen Tag später lief ein Angriff ohne Login gegen Drupal, am 21.08.2026 gegen WordPress. Die Modelle seien entscheidend gewesen, um mehrere Fehler zu einem Exploit zu verketten und ihn an das Speicherlayout des jeweiligen Ziels anzupassen. Ohne KI wäre diese Handarbeit laut Wiz schwer umzusetzen und kaum zu skalieren.
Die Projektseite php2shell.com trägt den Titel "AI uncovers critical vulnerabilities in the backbone of the web". Laut ihren FAQ halfen die Modelle bei Entdeckung, Exploit-Entwicklung und Prüfung des Patches. Calif schreibt im eigenen Bericht zu PHP2Shell, für den ersten Fund seien nur allgemein verfügbare Modelle ohne spezielle Testumgebung genutzt worden. Bei einem früheren Fehler in PHPs unserialize() vom Mai 2026 schrieb laut Calif Claude beide Exploits.
Warum wird die Zeit zwischen Patch und Exploit kürzer?
Ein Update verrät, wo der Fehler lag. Lange brauchten Fachleute Tage oder Wochen, um aus dem Vergleich von alter und neuer Version einen Angriff zu bauen. KI-Modelle lesen den Unterschied, testen den Exploit, werten Fehler aus und passen ihn an. So sinkt der Aufwand für Angriffe auf frisch geschlossene Lücken.
Laut Auswertung von Google Mandiant lag diese Time-to-Exploit 2018 und 2019 im Schnitt bei 63 Tagen, 2021 und 2022 bei 32 Tagen. 2023 waren es nur noch fünf Tage ohne Ausreißer, mit ihnen 47 Tage. Im Bericht M-Trends 2026 vom März 2026 schätzt Mandiant den Mittelwert auf minus sieben Tage, Angriffe beginnen also regelmäßig schon vor dem Patch.
Wie schnell ein Modell aus veröffentlichten Patches Angriffe ableitet, hat Anthropic gemessen. Laut Bericht von Anthropic vom 08.06.2026 baute Claude Mythos Preview aus 18 Firefox-Patches acht funktionierende Exploits, der erste stand nach knapp einer Stunde. Bei 21 Fehlern im Windows-Kernel dauerte der schnellste Proof of Concept 31 Minuten. Die Tests liefen in einer Testumgebung mit Patches von Januar bis März 2026.
Was das BSI bei PHP2Shell erwartete
In seiner Pressemitteilung vom 21.10.2026 hielt das BSI breite Angriffe "innerhalb weniger Stunden nach Erscheinen der Sicherheitsupdates" für wahrscheinlich. Angreifer könnten die Updates "mittels KI-gestützter Werkzeuge innerhalb kurzer Zeit analysieren und entsprechende Exploits generieren". PHP ist Open Source, die Korrekturen sind mit dem Release für alle lesbar. Mit dem Release beginnt damit ein Wettlauf zwischen Angreifern und Betreibern.
Leak und Exploit-Video: Wissen vor dem Patch
Am 20.10.2026, einen Tag vor dem Release, kursierten Hinweise auf die Lücken, ein Screenshot des Werkzeugs PHP2Shell und ein kurzes Exploit-Video, das schnell wieder verschwand. Das beschreibt Alexandre Daubois aus dem PHP-Sicherheitsteam in seinem Blog. Am Abend kündigte das PHP-Projekt die Updates für den 21.10.2026, 14:00 UTC, an.
So wussten Angreifer von den Lücken, bevor Betreiber etwas einspielen konnten. Cloudflare schaltete laut eigenem Blog am 21.10.2026 um 03:02 UTC Filterregeln für alle Tarife mit WAF frei, auch den kostenlosen, etwa neun Stunden vor der Offenlegung. Der Anbieter sah, wie Angreifer ihre Anfragen veränderten, um die Regeln zu umgehen. In seiner Cybersicherheitswarnung nannte das BSI am Nachmittag des 21.10.2026 keine bestätigte Ausnutzung, aber unbestätigte Berichte über existierende Exploits.
Wie nutzen Verteidiger KI gegen Sicherheitslücken?
Verteidiger nutzen KI, um Fehler zu finden, zu beheben und Patches zu prüfen, bevor Angreifer zuschlagen. Bei PHP2Shell half laut Projektseite das Gemini-Team von Google bei der Prüfung der Patches. Laut Wiz trug Gemini auch zur Behebung bei. Im Wettbewerb AIxCC reichten KI-Systeme Korrekturen im Schnitt nach 45 Minuten ein.
Im AIxCC-Finale der DARPA vom August 2025 fanden die Systeme 86 Prozent der eingebauten Testlücken. Von den gefundenen behoben sie 68 Prozent. Dazu entdeckten sie 18 echte Fehler, die nicht für den Wettbewerb eingebaut waren.
Das BSI fordert in einem Blogbeitrag vom 08.05.2026, mit KI aktiv nach Fehlern im eigenen Code zu suchen. Gegen KI-gestützte Angriffe helfen laut BSI dieselben Grundlagen wie gegen andere Angriffe:
- regelmäßige Sicherheitsupdates
- robuste Zugriffskontrollen und Zwei-Faktor-Authentifizierung
- sichere Konfigurationen
- umfassendes Logging
KI im Betrieb einer Website
Für eine einzelne Website braucht es dafür meist kein eigenes KI-Modell. Wichtiger sind Abläufe, die auch nachts und am Wochenende greifen. Dazu zählen Meldungen zu neuen Updates, Auswertungen der Logs und Prüfungen, ob sich Dateien geändert haben. WordPress bringt dafür den Befehl wp core verify-checksums mit, der die Kerndateien mit Prüfsummen von WordPress.org vergleicht.
Wer Server-Logs von einem KI-Dienst auswerten lässt, gibt IP-Adressen und damit personenbezogene Daten weiter. Das berührt die DSGVO, besonders bei Anbietern außerhalb der EU. Werkzeuge im eigenen Betrieb oder mit Hosting in der EU halten die Daten bei Ihnen. Deshalb lohnt der Blick darauf, warum der Hosting-Standort eine Rolle spielt.
Macht KI-generierter PHP-Code Websites unsicherer?
Studien deuten darauf hin. Veracode ließ über 100 Sprachmodelle 80 Aufgaben lösen. In 45 Prozent der Fälle enthielt der Code eine Sicherheitslücke, gegen Cross-Site-Scripting sicherten die Modelle ihn in 86 Prozent der Fälle nicht ab. Ergebnisse für PHP nennt die Studie allerdings nicht.
Die Studie vom Juli 2025 nennt Ergebnisse für Java, Python, C# und JavaScript. Java fiel in über 70 Prozent der Fälle durch, die anderen Sprachen in 38 bis 45 Prozent. Bei der Sicherheit schnitten neuere Modelle nicht besser ab, größere kaum besser als kleinere. Für PHP-Websites zählt vor allem der Befund zu Cross-Site-Scripting, denn PHP gibt dort meist HTML mit Eingaben von Nutzern aus.
KI-Code braucht deshalb dieselbe Prüfung wie Code von Menschen, mit Review, Tests und automatischen Sicherheitsscans. Wer eine ganze Website einem Generator überlässt, stößt auf weitere Grenzen beim Erstellen einer Website mit KI. PHP2Shell steckte allerdings nicht im Code einzelner Websites, sondern in PHP selbst.
Was bedeutet das KI-Tempo für Betreiber von PHP-Websites?
Bei kritischen Updates zählen Stunden, nicht mehr Wochen. Entscheidend ist, wer ein PHP-Update einspielt, wenn es abends oder am Wochenende erscheint. Ebenso wichtig ist, wie schnell danach alle PHP-Prozesse neu starten. Ein Monitoring zeigt, ob die neue Version wirklich läuft.
Bei Shared und Managed Hosting spielt meist der Anbieter die Updates ein, auf eigenen Servern und in Containern Sie oder Ihr Dienstleister. Das PHP-Projekt nennt im Advisory das Update als einzige sichere Wahl. Danach müssen alle PHP-Worker neu starten. Selbst die offiziellen PHP-Images auf Docker Hub bekamen die ersten gepatchten Builds erst gut zwei Stunden nach dem Release.
Ältere Versionen verschärfen das Problem. Für PHP 7.4, 8.0 und 8.1 gab es bei PHP2Shell keine offiziellen Releases, nur Korrekturen im Quellcode. Die Übersicht, welche PHP-Versionen noch Sicherheitsupdates bekommen, hilft beim Einordnen.
Bei der Wahl von Hosting und Betreuung helfen wenige Fragen. Wer reagiert, wenn ein kritischer Patch nachts erscheint? Meldet ein Monitoring abstürzende Worker und auffällige Fehlerraten? Diese Punkte gehören zum Webdesign und Betrieb einer Unternehmenswebsite genauso wie Gestaltung und Inhalte.
Häufige Fragen zu KI und Sicherheitslücken
Hat eine KI PHP2Shell allein gefunden?
Nein. Laut Wiz nutzte das Forschungsteam die Modelle Gemini 4 Argon und GPT-5.6 Sol sowie das Werkzeug Wiz Atlas. Genannt werden vier Forscher von Wiz und weitere Melder von Calif und OpenAI. Calif betont, dass Kenntnis des Ziels und früherer PHP-Fehler auch mit KI wichtig bleibt.
Können Angreifer mit KI jede Lücke sofort ausnutzen?
Nein. Die Tests von Anthropic liefen im Labor, echte Täter müssen noch Ziele finden und den Schutz umgehen. Bei PHP2Shell hängt der Erfolg laut PHP-Advisory von Build, Erweiterungen und Speicherlayout ab. Am 21.10.2026 meldete das BSI keine bestätigte Ausnutzung.
Schützt eine Web Application Firewall vor KI-gestützten Angriffen?
Sie kann Angriffe bremsen, ersetzt aber kein Update. Bei PHP2Shell aktivierte Cloudflare Regeln schon vor der Offenlegung und beobachtete, wie Angreifer ihre Anfragen zur Umgehung veränderten. Das PHP-Projekt nennt das Update als einzige sichere Wahl. Eine selbst betriebene Firewall vor dem Server ist eine Option ohne US-Anbieter.
Darf ich Server-Logs von einer KI auswerten lassen?
Logs enthalten IP-Adressen und damit personenbezogene Daten. Ob die Auswertung durch einen KI-Dienst zulässig ist, hängt von Anbieter, Vertrag und Zweck ab. Werkzeuge mit Hosting in der EU oder im eigenen Betrieb vereinfachen die Lage. Klären Sie den Einzelfall mit Ihrem Datenschutzbeauftragten.
Wie schnell sollte ein kritisches PHP-Update eingespielt sein?
Möglichst schnell nach dem Release. Das BSI forderte bei PHP2Shell, den Patch unverzüglich zu installieren, und rechnete mit Angriffen binnen weniger Stunden. Legen Sie deshalb vorab fest, wer auch nachts oder am Wochenende Updates einspielt und die PHP-Prozesse neu startet.