Am 13. November 2026 um 20:26 Uhr MEZ hat Cloudflare, ein US-Anbieter für die Auslieferung und den Schutz von Websites, Messdaten zu sogenannten KI-Pentest-Orchestratoren veröffentlicht^[1]. Gemeint ist Software, die mehrere KI-Agenten koordiniert, um Penetrationstests, also Sicherheitsprüfungen aus Angreifersicht, weitgehend selbstständig abzuarbeiten. Angreifer setzen dieselben Werkzeuge ohne Auftrag ein^[1].

Wichtig für die Einordnung: Die Zahlen sind Herstellerangaben aus Cloudflares eigenem Netz, und der Beitrag endet mit dem Angebot, beim Umsetzen der empfohlenen Schutzmaßnahmen zu helfen^[1]. Hintergrund sind die Warnung von CERT-EU vom 5. November^[2] und ein Bericht von Microsoft vom 6. November^[3] zum Missbrauch des Frameworks ARTEX, die wir am 11. November samt Grundschutz für KMU eingeordnet haben.

ARTEX ist ein quelloffenes System, das Angriffsschritte mit KI-Agenten automatisiert; sein Entwickler nahm es am 8. Oktober vom Netz^[1]. Inzwischen zählt Cloudflare über 12.000 Repositories, also öffentliche Code-Ablagen, darunter mehrere Hundert eigenständige Ableger des Originals; dazu kamen seit dem 8. Oktober Hunderte ähnlicher Frameworks^[1]. Cloudflare vermutet, dass gerade die Abschaltung die Verbreitung beschleunigt hat^[1].

Die Stärke der Werkzeuge beschreibt Cloudflare nüchtern: Sie prüfen offen erreichbare Dienste samt Konfiguration unermüdlich und systematisch, kleine Fehler fallen dadurch leicht auf^[1]. Laut FBI findet ARTEX besonders Systeme am Rand, die weniger Aufmerksamkeit bekommen als die Hauptanwendung: Partner- und Lieferantenportale, Backends mobiler Apps, Altsysteme und Anbindungen an Drittdienste^[5].

Unter den beobachteten Einfallstoren nennt das FBI Admin-Passwörter, die fest im JavaScript-Code einer Web-App stehen, Schnittstellen ohne Anmeldung und schwache Admin-Zugangsdaten^[5]. Cloudflare fand in mehreren Vorfällen eine gemeinsame Ursache: statische, nie ablaufende Zugangsschlüssel in CI/CD-Pipelines, also den automatisierten Abläufen, die Code bauen und auf Server bringen^[1]. Diese Schlüssel öffneten gleich mehrere Umgebungen^[1].

Ein Fall zeigt das Tempo. ARTEX verschaffte sich dort Zugriff auf einen kompromittierten, kontoweiten API-Schlüssel, der früher für Build- und Deploy-Abläufe diente, ohne IP-Beschränkung und ohne Rate-Limit, also ohne Begrenzung der Anfragen pro Zeit^[1]. Cloudflare beobachtete mehr als 69 Anfragen pro Minute, 400 Anfragen nach Datenbank-Abzügen in einer Stunde und Versuche, sich dauerhaft einzunisten; der Einstieg lag vermutlich bei einem großen Cloud-Anbieter^[1]. Wie viele Daten tatsächlich abflossen, sagen diese Zahlen nicht.

Cloudflare empfiehlt sechs Säulen: eine Web Application Firewall (WAF, ein Filter für Web-Anfragen) mit Rate-Limits, Anomalie-Erkennung, Bot-Abwehr, Zugang nur nach Identitätsprüfung, geprüfte Schnittstellen-Schemas und Bedrohungsinformationen^[1]. An einen Anbieter gebunden ist davon nichts. Je nach Aufbau setzen Sie die Punkte beim Hoster, im Webserver, im CMS oder in der Anwendung selbst um:

Erste Anlaufstelle sind die Zugriffsprotokolle (Logs) des Webservers; fragen Sie Ihren Hoster danach. Ein typisches Verdachtsmuster sind viele Anfragen einer IP-Adresse in kurzer Zeit, die mit den Statuscodes 404 (nicht gefunden) oder 403 (verboten) enden^[12]. Das FBI nennt zusätzlich kurze, heftige Aktivitätsschübe und gehäufte Fehlversuche mit kleinen, schrittweisen Änderungen^[5].

Ob ein KI-Tool dahintersteckt, verraten Logs nicht sicher. Die Browser-Kennung (User-Agent) lässt sich fälschen, wie Google für seinen eigenen Crawler warnt^[13]. IP-Adressen werden zudem neu vergeben, deshalb rät das FBI, veröffentlichte Angreifer-Adressen vor dem Sperren zu prüfen^[5]. Und: Auch dynamische IP-Adressen können personenbezogene Daten sein, ein berechtigtes Interesse an ihrer Speicherung zur Abwehr von Cyberangriffen ist aber möglich, so der EuGH 2016 zur damaligen Datenschutzrichtlinie, der Vorgängerin der DSGVO^[14]. Speicherdauer und Zugriff auf Logs gehören ins Datenschutzkonzept.

Cloudflares Zahlen sind ein Signal, kein Lagebild für Deutschland. Neu ist weniger, welche Lücken gesucht werden, als das Tempo.

Unsere Reihenfolge für KMU: zuerst Admin-Zugänge und Zugangsschlüssel, dann Rate-Limits, dann die Feinarbeit an den Schnittstellen. Schnell erledigt ist ein Tipp des BSI: eine security.txt, eine kleine Textdatei, über die Sicherheitsforschende Lücken melden können. Betreut ein Dienstleister die Website, gehört dessen Kontakt hinein^[6].