Cloudflare nutzt KI-Agenten, um die eigene Web Application Firewall zu belastungstesten

Cloudflare-Ingenieure haben ihre eigene Web Application Firewall (WAF) kürzlich einem strengen Belastungstest unterzogen, bei dem sie Frontier-Large-Language-Models (LLMs) einsetzten. Die am 29. September 2026 veröffentlichte Studie beschreibt, wie ein automatisiertes System als adversarischer Hacker fungierte und Tausende von Payload-Varianten iterativ durchlief, um Blindstellen in den Echtzeit-Abwehrmechanismen zu finden. Das Experiment deckte spezifische Schwachstellen bei der Verarbeitung von obfuskiertem Server-Side Request Forgery (SSRF) und Versuchen zur Befehlsinjektion auf, was zu sofortigen Updates in Cloudflares verwalteten Regelwerken führte.

Was passiert ist

Das Sicherheitsteam entwickelte eine maßgeschneiderte, Python-basierte Testumgebung, um zu evaluieren, ob moderne KI-Modelle WAF-Schutzmaßnahmen effektiver umgehen können als herkömmliche statische oder dynamische Analysewerkzeuge. Im Gegensatz zu standardmäßigen Penetrationstests nutzte dieses System LLMs, um Angriffsvektoren dynamisch basierend auf Live-HTTP-Antworten zu mutieren. Der Tester hatte keinen Zugriff auf Quellcode oder interne WAF-Regeln und verließ sich ausschließlich auf ausgewählte Antwortdaten, um seinen nächsten Schritt zu bestimmen. Dieser Black-Box-Ansatz imitierte das Vorgehen eines externen Angreifers, der eine geschützte Anwendung ohne Vorwissen über deren Infrastruktur abtastet.

Der Test wurde gegen eine autorisierte Kunden-Staging-Umgebung ausgeführt, die mit den strengsten Einstellungen von Cloudflare konfiguriert war. Dazu gehörten das Blockieren des WAF Attack Scores bei 30 oder darunter sowie das OWASP Core Ruleset auf Paranoia Level 3. Im Laufe des Experiments führte das System 1.107 Mutationsversuche in 45 Szenarien durch, die sechs Hauptangriffskategorien abdeckten: Cross-Site Scripting, SQL-Injection, Befehlsinjektion, Server-Side Request Forgery, Pfadtraversierung und Log4j-Exploits. Während die Mehrheit der Angriffe blockiert wurde, identifizierte der Prozess 49 spezifische Erkenntnisse, die einer menschlichen Überprüfung und anschließenden Abschwächung bedurften.

Die meisten erfolgreichen Umgehungen fielen in zwei Kategorien: Befehlsinjektion und Server-Side Request Forgery. In einem SSRF-Szenario entdeckte das Modell beispielsweise, dass die Darstellung einer Cloud-Metadata-IP-Adresse mit einem abschließenden Punkt es ermöglichte, die Erkennung zu umgehen, wo Standarddezimal- oder Oktaldarstellungen versagten. Diese Erkenntnisse waren keine bestätigten Exploits, sondern Hinweise darauf, dass die Normalisierungslogik der WAF bestimmte Randfälle unterschiedlich behandeln könnte. Das Team nutzte diese Einsichten, um seine Erkennungsengines zu verfeinern, was zu neuen Regeln für obfuskierte Hosts und eingeschränkte Protokolle führte.

Wie es funktioniert

Das Testsystem arbeitet mit einem adaptiven Zyklus, der von zwei unterschiedlichen LLM-Aufrufen pro Iteration gesteuert wird. Der erste Aufruf, die Vorschlagsphase, erhält den anfänglichen Anfragekontext und eine Historie früherer Ergebnisse, um eine neue Variante vorzuschlagen. Dabei kann die Kodierung geändert, die Nutzlast an einen anderen Teil der HTTP-Anfrage verschoben oder das Zielformat angepasst werden. Der zweite Aufruf, die Überprüfungsphase, analysiert Status, Header und Body der Antwort, um festzustellen, ob der Versuch erfolgreich war oder blockiert wurde. Dieser Feedback-Zyklus ermöglicht es dem Modell zu lernen, welche Mutationen wirksam sind, ohne jemals die zugrunde liegenden WAF-Regelausdrücke oder Angriffsscores zu sehen.

Entscheidend ist, dass der Code die strenge Kontrolle über die Ausführungsumgebung behält. Das LLM sendet keine Anfragen direkt; stattdessen generiert es Vorschläge, die von der Python-Testumgebung validiert und ausgeführt werden. Vor jeder Anfrage prüft das System den Ziel-Hostnamen gegen eine Allowlist, deaktiviert Weiterleitungen und erzwingt eine harte Grenze für Versuche. Nach jeder Antwort zeichnet das System strukturierte Beweise auf und behandelt jeden zurückgegebenen Text als nicht vertrauenswürdige Eingabe. Dieses Design stellt sicher, dass der Testprozess sicher und reproduzierbar bleibt und verhindert, dass die KI unbeabsichtigte Schäden verursacht oder sensible Daten während der Bewertung leckt.

Wichtige Details

• Der Test generierte 1.107 Mutationsversuche, wobei 558 explizit von der WAF blockiert wurden, bevor sie die Anwendung erreichten.
• Die menschliche Triagemethode reduzierte die Rohausgabe auf 49 gültige Erkenntnisse, von denen 48 mit Befehlsinjektion oder SSRF zusammenhingen.
• Die WAF-Konfiguration umfasste das Blockieren des WAF Attack Scores bei 30 oder darunter sowie das OWASP Core Ruleset auf Paranoia Level 3.
• Neue Erkennungen für SSRF-obfuskierte Hosts und eingeschränkte Protokolle wurden nach dem Test zum Managed Ruleset hinzugefügt.
• Das System verwendete zwei separate LLM-Aufrufe pro Iteration: einen zum Vorschlagen von Mutationen und einen zum Überprüfen der Antworten.
• Anfragen, die die WAF umgingen, wurden als Hinweise für Ermittlungen behandelt, nicht als bestätigte Exploits, und erforderten weitere Validierung.

Warum das wichtig ist

Für Software-Ingenieure und Sicherheitsverantwortliche hebt diese Studie die Grenzen statischer, regelbasierter Abwehrmaßnahmen gegenüber adaptiven Gegnern hervor. Herkömmliche Penetrationstests folgen oft vordefinierten Skripten und übersehen neuartige Kodierungstechniken oder logische Fehler, die eine KI durch Iteration entdecken kann. Indem Cloudflare demonstriert, dass LLMs Lücken selbst in hochkonfigurierten WAFs finden können, unterstreicht das Unternehmen die Notwendigkeit kontinuierlicher, automatisierter Sicherheitstests, die sich parallel zur Bedrohungslandschaft entwickeln. Es deutet darauf hin, dass die alleinige Abhängigkeit von signaturbasierter Erkennung unzureichend ist, wenn Angreifer KI nutzen können, um unendliche Variationen bekannter Exploits zu generieren.

Die Erkenntnisse bekräftigen zudem die Bedeutung der Defense-in-Depth-Strategie. Selbst wenn eine WAF eine spezifische mutierte Anfrage nicht blockiert, muss die Anwendung selbst weiterhin sicher bleiben. Im SSRF-Beispiel führte die Umgehung nicht zu einer Datenexfiltration, da die Anwendungsebene wahrscheinlich eigene Schutzmaßnahmen besaß oder die Anfrage so fehlerhaft war, dass eine tatsächliche Ausnutzung verhindert wurde. Dies erinnert Entwickler daran, dass das Patchen von Software und die Aktualisierung von Abhängigkeiten kritische Ergänzungen zu netzwerkbasierten Sicherheitskontrollen sind. Eine WAF ist ein Schild, kein Heilmittel, und ihre Wirksamkeit hängt von der Resilienz des gesamten Stacks ab.

Was Sie tun können

• Aktivieren Sie alle verfügbaren Managed Rulesets und setzen Sie die Schwellenwerte für den WAF Attack Score gemäß Ihrem Risikoprofil auf empfohlene Levels.
• Führen Sie bestehende Tests zur Anwendungssicherheit gegen Staging-Umgebungen aus, die durch dieselben WAF-Konfigurationen wie die Produktionsumgebung geschützt sind.
• Implementieren Sie positive Sicherheitskontrollen, die erwartete Anfrageformen definieren, um die Angriffsfläche für unbekannte Varianten zu reduzieren.
• Prüfen Sie Sicherheitsereignisse im Log-only-Modus, bevor neue Regeln erzwungen werden, um False Positives und legitime Traffic-Muster zu identifizieren.
• Halten Sie Anwendungsabhängigkeiten und Frameworks aktuell, um Schwachstellen zu mildern, die offengelegt werden könnten, falls WAF-Ebenen versagen.
• Erwägen Sie den Einsatz KI-gesteuerter Testwerkzeuge zur Ergänzung manueller Penetrationstests, mit Fokus auf adaptive Mutation von Payloads.