Hätte eine KI-WAF php2shell gestoppt? Die falsche Frage.
php2shell ist eine kritische Lücke in der PHP-Laufzeitumgebung selbst, und fast die Hälfte aller PHP-Seiten läuft auf einer Version, für die kein Patch kommt. Verängstigte Seitenbetreiber greifen jetzt zu KI-WAFs. Hier steht, warum das die falsche Frage ist und was Sie wirklich davor bewahrt, übernommen zu werden.
Diese Woche ist eine neue PHP-Lücke aufgetaucht, und sie ist übel. Man nennt sie php2shell. Es sind zwei Schwachstellen, CVE-2026-109618 und CVE-2026-109619. PHP bewertet beide mit 9,2 von 10. Manche Forscher sprachen von glatten 10 Punkten. Quelle: Help Net Security | SecurityWeek
Die Details sind durchgesickert, bevor der Patch fertig war. Bis zum 21. Oktober griffen Angreifer live betriebene Seiten in großem Stil an. Quelle: Hadrian
Hier kommt der Teil, der den Leuten Angst macht. Die Lücke steckt in PHP selbst, nicht in Ihrem Code. Ihre Anwendung kann sauber sein, und trotzdem sind Sie angreifbar. Quelle: The Hacker News
Deshalb bekomme ich immer wieder eine Frage gestellt. Hätte eine KI-WAF das gestoppt? Ich halte das für die falsche Frage. Ich zeige Ihnen, warum.
Was php2shell wirklich ist
Die meisten Web-Lücken stecken in Ihrer Anwendung. Ein schlecht geprüftes Formularfeld. Eine schwache Login-Seite. php2shell ist anders. Die Lücke steckt in der PHP-Laufzeitumgebung. Das ist die Engine, die jede PHP-Seite ausführt. Quelle: Hadrian
Am schlimmsten trifft es Setups mit mod_php und Apache. Dort braucht ein Angreifer keinen Login. Die Lücke kann zünden, noch bevor Ihr Code überhaupt läuft. PHP stuft genau diesen Fall als höchstes Risiko ein. Quelle: Hadrian
Die meisten Angriffe missbrauchen bisher eine Funktion. Sie heißt session upload progress. PHP geht beim Lesen eines Uploads falsch mit dem Speicher um. Quelle: Hadrian
Jetzt der unangenehme Teil für Verteidiger. Die bösartige Anfrage kann völlig normal aussehen. Es ist ein Datei-Upload. Kein seltsames SQL-Anführungszeichen. Kein Script-Tag. Kein ../ im Pfad. Nichts, worüber ein Filter Alarm schlagen könnte.
Diesen Film haben wir schon gesehen
Das alles kommt mir bekannt vor. Es erinnert mich an die frühen Tage der SQL-Injection. Ein Nischentrick wurde schnell zum Massenphänomen. Die Werkzeuge wurden billig. Bis 2008 scannte ein Botnetz das halbe Web nach einem einzigen schwachen Feld ab und verseuchte jede Seite, die es fand. Quelle: Dark Reading (Asprox, 2008)
php2shell hat dieselbe Form. Es ist unauthentifiziert. Es steckt in der Laufzeitumgebung. Es lässt sich trivial scannen. Deshalb durchkämmt gerade jeder Akteur, gut wie böse, das Web nach verwundbaren Seiten. Bei so vielen verlassenen Anwendungen da draußen ist es so gut wie sicher, dass sie fündig werden.
Aber in einem entscheidenden Punkt ist das schlimmer als SQL-Injection. SQL-Injection war eine Lücke in Ihrer Anwendung. Eine gepflegte Anwendung konnte sie im Code beheben. php2shell ist eine Lücke in der PHP-Laufzeitumgebung. Auf einer Version am Ende ihres Lebenszyklus hat der Betreiber gar keinen Fix. Die verlassene Anwendung ist nicht nur ungepatcht. Sie ist nicht patchbar.
Ja, KI beschleunigt inzwischen beide Seiten. Angreifer generieren automatisch Scanner. Verteidiger schreiben automatisch virtuelle Patches. Aber das ist kein fairer Tausch. Der Angreifer braucht einen Treffer über Millionen von Seiten hinweg. Der Verteidiger muss jede einzelne absichern. Schnellere Werkzeuge helfen einer Seite nicht, um die sich niemand mehr kümmert.
Das ist das Entdecken von Schwachstellen, das steil nach oben geht. Über diesen Wandel habe ich geschrieben, als ein KI-Modell auf einen Schlag Tausende Zero-Days zutage förderte. php2shell ist eine der ersten Folgen davon, nicht die letzte.
Das eigentliche Problem ist altes PHP
PHP hat am 21. Oktober Fixes ausgeliefert. Die sicheren Builds sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Quelle: Help Net Security Patchen Sie, und Sie sind sicher. Einfach, oder?
Nicht für den Großteil des Webs. Schauen Sie sich an, was PHP-Seiten heute tatsächlich einsetzen. Diese Zahlen stammen aus Hadrians Tabelle zu PHP-Versionen und Fixes, aufgebaut auf W3Techs-Daten. Quelle: Hadrian, Tabelle PHP-Version / offizieller Fix (W3Techs, 21. Okt. 2026)
Rechnen Sie es zusammen. Rund 48,5% der PHP-Seiten laufen auf einer Version, für die kein offizieller Fix kommt. Quelle: Hadrian, Tabelle PHP-Version / offizieller Fix PHP betreibt etwa 69,3% aller Seiten mit bekanntem Backend. Das ist also nahezu ein Drittel des gesamten Webs. Quelle: W3Techs via Hadrian
Das sind Versionen am Ende ihres Lebenszyklus. Upstream hat den Support dafür vor Jahren eingestellt. PHP hat zwar reine Quellcode-Patches für 7.4, 8.0 und 8.1 veröffentlicht, aber Sie müssen selbst aus dem Quellcode bauen. Quelle: Hadrian Die meisten Seitenbetreiber werden das nie tun.
Das ist der Kern der Sache. Ein riesiger Teil des Webs kann nicht patchen. Also suchen die Betreiber stattdessen nach etwas zum Kaufen. Und der Markt hat eine Antwort parat. Es ist die KI-WAF.
Warum "rettet mich eine KI-WAF" die falsche Frage ist
Ich habe einen ganzen Leitfaden darüber geschrieben, was "KI-gestützt" bei einer WAF wirklich bedeutet. Lesen Sie den für das ganze Bild. Die Kurzfassung lautet so. Eine echte KI-WAF lernt Ihren normalen Datenverkehr und meldet das Ungewöhnliche.
Das klingt perfekt für eine Lücke, für die noch niemand eine Regel hat. Aber überlegen Sie, was das Modell sieht. Es sieht die Anfrage. php2shell richtet seinen Schaden im PHP-Speicher an, nachdem die Anfrage durchgelassen wurde. Der Hinweis steckt nicht in den Bytes auf der Leitung. Das Modell hat also nichts, woraus es lernen könnte.
Sobald ein öffentlicher Exploit existiert, kann eine WAF die bekannte Form des Angriffs blockieren. Das ist real und nützlich. Aber das ist eine Signatur. Es ist ein virtueller Patch. Eine schlichte regelbasierte WAF macht genau dasselbe, oft schneller.
Das KI-Etikett bringt hier also wenig. Das, wofür es verkauft wird, nämlich einen brandneuen Angriff durch das Lesen der Absicht zu erkennen, ist genau das, was es bei einer Speicher-Lücke nicht leisten kann. Zu wissen, welche Bytes PHP brechen, stammt aus dem CVE. Es stammt nicht daher, dass das Modell schlau ist.
Was Sie wirklich davor bewahrt, übernommen zu werden
Eine WAF ist ein Sicherheitsgurt. Sie ist nicht die Bremse. Hier steht, was die eigentliche Arbeit leistet.
- Weg von PHP am Ende seines Lebenszyklus. Das ist der einzige echte Fix. PHP 8.2 oder neuer bekommt Patches. Alles Ältere läuft auf geborgter Zeit.
- Betreiben Sie PHP mit minimalen Rechten. Nutzen Sie php-fpm, nicht mod_php. Geben Sie dem Worker einen eigenen Benutzer mit wenig Rechten.
- Machen Sie Ihren Upload-Ordner nicht ausführbar. Landet dort eine Shell, darf sie nicht laufen. Eine abgelegte
.php-Datei ist nutzlos, wenn der Server sich weigert, sie auszuführen. - Schalten Sie session upload progress ab, wenn Sie es nicht nutzen. Setzen Sie es in der php.ini oder im FPM-Pool und starten Sie dann die Worker neu.
- Blockieren Sie herrenlose
.php-Anfragen. Ein Angreifer, der eindringt, legt meist eine Shell ab und ruft sie auf. Eine Regel, die unbekannte.php-Dateien mit 404 beantwortet, stumpft diesen Schritt ab. - Halten Sie saubere Backups bereit. Ein übernommenes System bleibt übernommen. Der ehrliche Fix für einen Einbruch ist die Wiederherstellung aus einer nachweislich sauberen Kopie. Quelle: Hadrian
; php.ini oder Ihr FPM-Pool, dann die Worker neu starten.
; Hier setzen, nicht mit ini_set() oder .user.ini.
; Das hilft, ist aber für sich allein kein vollständiger Fix.
session.upload_progress.enabled = 0Wo eine WAF ihren Platz verdient
Ich sage nicht, lassen Sie die WAF weg. Eine WAF verschafft Ihnen Zeit. Das zählt enorm, wenn Sie heute nicht patchen können.
Nehmen Sie Nivoli Edge als ehrliches Beispiel. Sein "PHP parser guard" blockiert fehlerhafte Uploads am Edge, bevor PHP sie liest. Die eigene Dokumentation führt CVE-2026-109618 und CVE-2026-109619 unter den abgedeckten Lücken auf. Quelle: Nivoli-Doku
Aber lesen Sie die nächste Zeile in genau dieser Doku. Der Guard "verringert die Angriffsfläche durch Lücken in PHP selbst" und "ersetzt nicht das Aktualisieren von PHP". Quelle: Nivoli-Doku Das ist die ehrliche Formulierung. Ich wünschte, mehr Anbieter würden so schreiben.
Eine Regel gegen herrenlose .php-Dateien und ein Parser-Guard bremsen einen Angreifer aus. Sie machen eine ungepatchte Laufzeitumgebung nicht sicher. Keine WAF tut das.
Das Fazit
Also, hätte eine KI-WAF php2shell gestoppt? Für den brandneuen Angriff: nein. Für die später bekannte Form stoppt ihn eine Signatur, und dafür brauchen Sie keine KI.
Die eigentliche Lehre ist älter und langweiliger. Patchen Sie, was Sie können. Wenn Sie nicht patchen können, härten Sie ab. Minimale Rechte. Nicht ausführbare Uploads. Saubere Backups. Setzen Sie dann eine WAF davor, um Zeit zu gewinnen.
Die Box, die Sie kaufen, ist nicht der Fix. Die Gewohnheiten sind es.