Was gerade passiert
Drei unabhängige Berichte aus den letzten Monaten zeigen in dieselbe Richtung.
- Cequence (veröffentlicht am 28. Okt.): ein Scanner, ~32 gefälschte KI-Identitäten, aktiv mindestens von Ende September bis Ende Oktober. Jede Cloud-Adresse feuerte in etwa acht Sekunden eine Salve von 50 bis 190 Anfragen ab und zog dann weiter. An einem einzigen Tag nutzte er mehr als 300 Adressen, und keine der Adressen von Ende September tauchte einen Monat später wieder auf. CSO Online merkt in seinem Bericht an, dass diese Art der Rotation statische IP-Blocklisten deutlich weniger nützlich macht.
- GreyNoise (August): Ein anderer Cluster gab sich von 824 Adressen aus als 13 KI-Crawler aus, und keine davon lag in den veröffentlichten IP-Bereichen der Firmen. Die meistabgefragten Pfade lesen sich wie eine Checkliste aller Orte, an denen ein Framework Secrets liegen lassen könnte: /.env, /app/.env, /api/.env, /backend/.env, /.env.local, /.env.production, /.env.bak, /.aws/credentials. Die falschen Bots fragten kein einziges Mal nach /robots.txt. Anthropics echter Crawler tat das und fragte nie eine Credential-Datei ab.
- Symantec, via Help Net Security (23. Okt.): Ein Honeypot, der sich als ungeschützter KI-Dienst ausgab, ertappte den autonomen Agenten eines Angreifers bei der Arbeit. Sein Jailbreak-Prompt erzählte dem Modell, das Lesen von .env-Dateien, API-Keys und Datenbankschemas sei ganz normale Entwicklungsarbeit. Die meisten der über 127.000 Anfragen, die der Honeypot protokollierte, waren Aufklärung, Versuche mit gestohlenen Keys und Sondierungen nach offenen Konfigurationsdateien.
Das Muster ist klar. Angreifer wissen, dass Website-Betreiber angefangen haben, KI-Crawler auf Allowlists zu setzen, also leihen sie sich deren Namen. Und sie wissen, dass KI-Keys echtes Geld wert sind: Ein geleakter OpenAI-, Anthropic- oder Gemini-Key kann eine hohe Rechnung verursachen, bevor du es merkst.
Warum das Builder angeht, die schnell shippen
Der User-Agent-String ist nur ein Header, den der Besucher über sich selbst schreibt. Er beweist gar nichts. Wenn dein Hosting-Setup, eine CDN-Regel oder deine WAF „bekannte KI-Bots“ durchlässt, hast du womöglich genau diesem Traffic eine Tür geöffnet.
Noch wichtiger: Das Gesuchte ist ein klassischer Fehler in schnell gelaunchten Apps. Eine .env-Datei landet im Web-Root, weil der Build den ganzen Projektordner kopiert hat. Eine .env.production.bak bleibt nach einem nächtlichen Fix liegen. Ein Docker-Image liefert /app als statische Dateien aus. Nichts davon braucht einen raffinierten Exploit. Es ist ein GET-Request, und dem Bot ist egal, ob es seine erste oder seine neunzigste Anfrage ist.
So prüfst du deine App
Fang mit den Pfaden an, die die Scanner tatsächlich abfragen. Führe die Schleife unten in einem Terminal mit deiner eigenen Domain aus.
Du willst in jeder Zeile 404 oder 403 sehen. Ein 200 ist ein Problem, aber prüfe den Inhalt, bevor du in Panik gerätst: Viele Single-Page-Apps liefern für jeden unbekannten Pfad index.html mit Status 200. Führe curl -s https://yourapp.com/.env | head -5 aus und sieh dir an, was zurückkommt. Siehst du KEY=value-Zeilen, behandle jedes Secret in dieser Datei als kompromittiert.
for p in .env .env.local .env.production .env.bak .env.old \
app/.env api/.env backend/.env .aws/credentials .git/config; do
code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourapp.com/$p")
echo "$code /$p"
donePrüfe bei der Gelegenheit auch die verwandten Lecks, die dieselben Secrets auf anderem Weg preisgeben:
- Ein erreichbares .git-Verzeichnis lässt jeden deinen Quellcode rekonstruieren, einschließlich jeder .env, die jemals committet wurde.
- Keys in deinem JavaScript-Bundle brauchen überhaupt keinen Scanner. Öffne die DevTools und durchsuche das Bundle nach sk-, AIza oder key.
- Source Maps in Produktion können deinen Original-Quellcode ausliefern, samt Kommentaren.
Prüfe dann deine Logs. Suche nach Anfragen an /.env oder /.aws/credentials. Hat eine davon einen 200 zurückgegeben, ist das der Startzeitpunkt deines Vorfalls.
So behebst du es
1. Hol Secrets aus dem Web-Root. Die eigentliche Lösung ist, dass die Datei gar nicht erst zum Ausliefern da ist. Umgebungsvariablen gehören in die Einstellungen deines Hosts (Vercel, Netlify, Railway, Fly und die anderen haben sie alle), nicht in eine Datei, die zusammen mit deinen statischen Assets deployt wird. Stell sicher, dass .env* sowohl in .gitignore als auch in .dockerignore steht.
2. Blockiere Dotfiles als Absicherung auf dem Server. Für nginx:
# Deny all hidden files except the ACME challenge path
location ~ /\.(?!well-known) {
deny all;
return 404;
}Für Apache (.htaccess):
<FilesMatch "^\.">
Require all denied
</FilesMatch>Bei einer Express-App, die statische Dateien ausliefert, ignoriert express.static Dotfiles standardmäßig. Überschreibe das nicht mit dotfiles: 'allow'.
3. Rotiere alles, was offenlag. Die Datei zu löschen macht die geleakten Keys nicht ungeschehen. Rotiere jedes Secret, das jemals erreichbar war, angefangen bei Zahlungs-, Datenbank- und KI-Anbieter-Keys. Unser Beitrag zum Railway-Datenleck zeigt Schritt für Schritt, wie du die Secrets deiner App ohne Ausfallzeit rotierst.
4. Vertrau nicht dem User-Agent. Wenn du KI-Crawler durch eine Firewall oder ein Rate-Limit lässt, prüfe sie anhand der IP-Bereiche, die die Firmen veröffentlichen, statt nur den Namen abzugleichen. GreyNoise listet in seinem Bericht die offiziellen JSON-Dateien von Anthropic, OpenAI, Google und Perplexity auf. Cequence rät dasselbe: Verifiziere über signierte Requests, veröffentlichte Adressbereiche oder direkte Integrationen.
5. Patche dein Dev-Tooling, wenn es offenliegt. GreyNoise sah diese Scanner auch den Vite-Dateilese-Bug CVE-2025-30208 ausprobieren. Wenn ein Vite-Dev-Server je aus dem Internet erreichbar ist, aktualisiere auf 6.2.3, 6.1.2, 6.0.12, 5.4.15 oder 4.5.10 oder neuer, und stell Dev-Server gar nicht erst öffentlich bereit.
6. Setze Ausgabenlimits für KI-Keys. Die meisten KI-Anbieter lassen dich die monatlichen Ausgaben begrenzen oder Keys auf bestimmte Projekte beschränken. Ein Leck verhindert das nicht, aber aus einer vierstelligen Überraschung wird eine kleine.
Kurze Checkliste
Bevor du das Terminal schließt, stell sicher, dass:
- jeder Pfad aus der curl-Schleife oben 404/403 zurückgibt, nicht deine Datei.
- .env* in .gitignore und .dockerignore steht.
- dein Server oder Host Dotfiles verweigert.
- keine Secret-Keys im JS-Bundle oder in Source Maps stecken.
- jeder Key, der jemals erreichbar war, rotiert wurde.
- Allowlists für KI-Crawler IP-Bereiche prüfen, nicht nur den User-Agent.
- Ausgabenlimits für die Keys deiner KI-Anbieter gesetzt sind.
Prüfe es, bevor die Bots es tun
Diese Scanner wechseln durch Hunderte Adressen und verbringen pro Salve etwa acht Sekunden. Durch Log-Beobachtung gewinnst du nicht. Du gewinnst, indem du sicherstellst, dass nichts da ist, wenn sie anklopfen.
AppSafe prüft genau auf die Lecks, nach denen diese Bots suchen, darunter erreichbare .env-Dateien, offengelegte .git-Verzeichnisse, Datenbank-Dumps und API-Keys in deinem Frontend-Bundle, und jeder Befund kommt mit einem Fix-Prompt zum Kopieren für dein KI-Coding-Tool. Wenn du noch vor dem Launch stehst, ist unsere Checkliste für KI-gebaute Apps eine gute Ergänzung. Starte einen kostenlosen Scan deiner App und sieh, was ein Bot sehen würde.