Aktuelles 24. Oktober 2026 7 Min. Lesezeit

PHP2Shell: Wie KI die größte PHP-Lücke seit Jahren aufgedeckt hat

KI-generiertes Beitragsbild — Bild generiert mit KI

Schwierigkeitsgrad: Einsteiger bis Fortgeschrittene

Enthält: Was PHP2Shell ist · Zeitachse · Rolle der KI · Was du jetzt tun solltest · Was das für Projekte bedeutet

Stand: 24. Oktober 2026

Diese Woche war eine harte Woche fürs Internet. Behördenseiten in den Niederlanden und Finnland gingen vom Netz, das Internet Archive war kurz offline, deutsche Kommunen, Kliniken und Hochschulen schalteten Server ab. Der Grund heißt PHP2Shell, und das Bemerkenswerte daran ist nicht nur die Lücke selbst. Gefunden hat sie nämlich kein Team von Sicherheitsforschern, das monatelang Code gewälzt hat. Gefunden hat sie eine KI.

Zeit, das mal einzuordnen.

Was ist PHP2Shell?

Hinter dem Namen stecken zwei Schwachstellen im Kern von PHP, also in der Sprache, auf der WordPress, Drupal, Typo3, MediaWiki und unzählige andere Systeme laufen.

Merkmal	Details
CVE-Nummern	CVE-2026-109618 und CVE-2026-109619
Schweregrad	CVSS 9,2 (kritisch), watchTowr bewertet sogar mit 10,0
Betroffen	Praktisch alle PHP-Versionen von 5.4 bis 8.5, also über ein Jahrzehnt
Auswirkung	Ausführung von Schadcode aus der Ferne, ohne Login. Zusätzlich lassen sich Speicherinhalte wie Passwörter, Tokens und API-Keys auslesen.
Ursache	Speicherfehler beim Umgang mit fatalen Fehlern (v. a. Out-of-Memory). Nach einem abgebrochenen Request bleibt fehlerhafter Zustand zurück, den der nächste Request wiederverwendet.
Patch	21. Oktober 2026

Warum ist das so heikel? Die Lücke sitzt nicht in einem Plugin oder in schlampigem Website-Code, sondern eine Ebene darunter. Selbst eine perfekt gepflegte WordPress-Installation ist angreifbar, solange die PHP-Version darunter nicht aktualisiert ist. Wiz schätzt, dass rund 70 % aller Websites PHP nutzen. Diese Zahl stammt vom Entdecker selbst und lässt sich nicht unabhängig prüfen, die Größenordnung ist aber klar.

Die Zeitachse: Vom KI-Fund zum Notfall-Patch

2024

Ein PHP-Kernentwickler stößt bei einem Audit auf einen Out-of-Memory-Fehler. Behoben wird er nicht. Man ist sich über den Lösungsweg uneinig, und ein praktischer Angriff gilt als unrealistisch.

August 2026

Ryan Austin vom Sicherheitsunternehmen Calif findet mit GPT-5.6 Sol im Rahmen von OpenAIs Initiative „Patch the Planet“ einen funktionierenden Angriffsweg. Unabhängig davon entdeckt Wiz am 19. August die Lücke und baut mit Gemini 4 Argon und GPT-5.6 Sol innerhalb von zwei Tagen Exploits gegen Drupal und WordPress.

24. August

Meldung an das PHP-Security-Team. Am 21. September bestätigt PHP und beginnt mit dem Fix.

17. Oktober

Amazon Threat Intelligence sieht in seinen Honeypots einen ersten Angriffsversuch, also vier Tage vor der Veröffentlichung.

20. Oktober

Details sickern über Hacker News durch, Calif veröffentlicht versehentlich ein Proof-of-Concept-Video. Cloudflare meldet erste Ausnutzung.

21. Oktober

Patches für PHP 8.2 bis 8.5 erscheinen. Noch am selben Tag kursieren mehrere öffentliche Exploits. Das BSI warnt mit Stufe „3 / Orange“ und rät, betroffene Server im Zweifel vom Netz zu nehmen.

22. bis 24. Oktober

Weitere Behörden (u. a. CERT-EU, britisches NCSC, Singapur) ziehen nach. Hoster wie cPanel und CloudLinux liefern Backports, viele Anbieter fahren Notwartungen.

Die eigentliche Story: KI hat die Spielregeln geändert

Technisch ist PHP2Shell eine Kette aus mehreren Speicherfehlern. Solche Fehler gab es in PHP schon immer, und Warnungen davor auch. Trotzdem hat sich jahrelang niemand ernsthaft darum gekümmert. Der Grund: Mehrere solcher Bugs zu einem funktionierenden Angriff zu verketten, über verschiedene PHP-Versionen, Konfigurationen und Speicherlayouts hinweg, war mühsame Handarbeit für absolute Spezialisten. t3n hat es treffend zusammengefasst: Zehn Jahre lang hat die bloße Komplexität das Web geschützt.

Genau diesen Schutz haben KI-Modelle jetzt ausgehebelt. Laut Wiz hat die KI nicht nur beim Finden geholfen, sondern auch bei der Exploit-Entwicklung, beim Anpassen an unterschiedliche Umgebungen, beim Erkennen von Angriffen und beim Prüfen der Patches. Die Modelle haben fehlgeschlagene Versuche selbst analysiert und so lange nachgebessert, bis es funktionierte.

„A single researcher completed in a week what previously would have taken a world-class team months of work.“

— Wiz Research, Oktober 2026

Ein einzelner Forscher, eine Woche, statt eines Weltklasse-Teams über Monate. Dieser Satz ist für mich die eigentliche Nachricht dieser Woche. Wer meinen Artikel über den KI-Agenten Mythos gelesen hat, kennt die These: Wenn KI Schwachstellen in Minuten statt Monaten findet, verschieben sich alle Zeitfenster in der IT-Sicherheit. PHP2Shell ist der erste richtig große Praxisfall dafür.

👍 Die gute Nachricht

Die Lücke wurde von Verteidigern gefunden und koordiniert gemeldet
Ein Jahrzehnt alter Fehler ist endlich geschlossen
KI half auch bei Erkennung und Patch-Prüfung
Initiativen wie „Patch the Planet“ setzen KI gezielt für Open Source ein

👎 Die Kehrseite

Dieselben Werkzeuge stehen auch Angreifern zur Verfügung
Exploits kursierten schon vor dem offiziellen Patch
Zwischen Veröffentlichung und Angriff liegen Stunden, nicht Wochen
Die Entdeckungsrate steigt schneller als die Kapazität zum Fixen

Das Ungleichgewicht, über das kaum jemand spricht

Ein Detail hat mich besonders nachdenklich gemacht. Die PHP Foundation, die einen Großteil des Webs am Laufen hält, hat laut Guardian gerade einmal 13 Angestellte. Auf der anderen Seite stehen KI-Labore mit Milliardenbudgets, die Lücken jetzt im Akkord finden können.

Das Finden wird also billig und schnell. Das Fixen, Testen, Ausrollen und Koordinieren bleibt teuer, langsam und hängt oft an einer Handvoll Freiwilliger. Dass der Fehler von 2024 liegen blieb, weil das Team sich nicht auf einen Lösungsweg einigen konnte, ist kein Versagen Einzelner. Es zeigt, wie dünn die Personaldecke bei kritischer Open-Source-Infrastruktur ist.

Achtung: Wir müssen davon ausgehen, dass PHP2Shell kein Einzelfall bleibt. Wenn KI-Modelle zehn Jahre alte Fehler in PHP finden, finden sie sie auch in anderen Sprachen, Bibliotheken und Systemen. Die Frage ist nicht ob, sondern wie oft.

Was du jetzt tun solltest

Wenn du eine Website betreibst oder Verantwortung für Webanwendungen trägst, hier die Kurzfassung:

PHP-Version prüfen. Sicher sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 gibt es nur Quellcode-Patches bzw. Backports vom Hoster. Die Version findest du im Hosting-Panel oder unter WordPress → Werkzeuge → Website-Zustand → Info → Server.

Updaten, nicht tricksen. Amazon, Wiz und die PHP-Entwickler sind sich einig: Nur das Update behebt beide Lücken vollständig. WAF-Regeln (z. B. von Cloudflare) und Konfigurationsänderungen sind höchstens eine Übergangslösung.

Hoster kontaktieren. Bei Shared Hosting hast du die PHP-Version oft nicht selbst in der Hand. Frag nach, ob gepatcht wurde, und lass dir die Versionsnummer nennen.

Logs ab dem 17. Oktober prüfen. Nicht erst ab dem Patch-Tag. Auffällig sind ungewöhnliche Upload-Requests mit PHP_SESSION_UPLOAD_PROGRESS, gehäufte HTTP-500-Fehler, Speicherlimit-Fehler und seltsam große PHPSESSID-Cookies.

Zugangsdaten tauschen, wenn du unsicher bist. Weil die Lücke Speicherinhalte preisgeben kann, solltest du bei Verdacht Datenbank-Passwörter, API-Keys und Application Passwords erneuern.

Kleiner Praxis-Check: Auch diese Seite läuft auf WordPress und damit auf PHP. Sie ist inzwischen auf PHP 8.4.27 aktualisiert und damit geschützt. Ich hab’s also selbst gemacht, bevor ich es euch empfehle.

Was das für Projekte und Organisationen bedeutet

Spannend wird PHP2Shell für alle, die Projekte verantworten. Die Lücke wirft drei Fragen auf, die in kaum einem Projektplan stehen:

Frage	Bisher	Ab jetzt
Wie schnell müssen wir patchen?	Im nächsten Wartungsfenster, in Tagen oder Wochen	In Stunden. Amazon empfiehlt ausdrücklich, Patch-Fristen in Stunden statt Tagen zu messen.
Wer ist zuständig?	„Macht der Hoster“ oder „macht die IT“	Klare Verantwortlichkeit inkl. Vertretung, auch am Wochenende
Was ist unser Plan B?	Gibt es meist nicht	Entscheidung vorab klären: Wann nehmen wir ein System lieber vom Netz?
Wie alt ist unser Stack?	„Läuft doch“	Veraltete Versionen sind ein messbares Projektrisiko, kein Schönheitsfehler

Wer heute noch PHP 7.x oder eine ähnlich alte Basis betreibt, hat diese Woche gemerkt, was technische Schulden im Ernstfall kosten: keinen fertigen Patch, Notwartung, im schlimmsten Fall Abschalten.

✅ Mein Fazit

PHP2Shell ist mehr als eine weitere kritische Lücke. Es ist der Moment, in dem sichtbar wird, dass KI die Ökonomie der IT-Sicherheit umkrempelt. Lücken finden war bisher teuer, das hat uns geschützt. Jetzt wird es billig, für beide Seiten. Wer Systeme verantwortet, sollte daraus zwei Dinge mitnehmen: Patch-Prozesse müssen schneller werden, und veraltete Software ist ab sofort ein echtes Geschäftsrisiko. Und vielleicht sollten wir als Branche auch darüber reden, ob 13 Leute bei der PHP Foundation wirklich genug sind für ein Fundament, auf dem der halbe Webverkehr steht.