Scanner zielen auf KI-Tool-Konfigurationen

Automatische Scanner klappern seit jeher jeden Server ab, der auf Port 443 antwortet. Bisher suchten sie nach WordPress-Loginseiten und .env-Dateien. Die Liste hat sich geändert.

Der Agentic Web Index von Known Agents wertet den Bot-Verkehr von mehr als 5.000 Websites aus. Unter der Überschrift "Recent Top Targeted Paths" steht dort, welche Pfade Scanner gerade am häufigsten anfragen. Ganz oben:

/.config/anthropic/credentials/default.json
/.claude/settings.json
/.claude.json
/.hermes/.env
/.openclaw/.env
/.codex/config.toml
/.continue/config.json
/.aider.conf.yml
/service-account.json

Das sind die Konfigurationsdateien von Claude Code, Codex, Continue, Aider und OpenClaw. Sie stehen jetzt auf derselben automatisierten Einkaufsliste wie früher wp-login.php.

Erst die Einordnung, dann die Panik

Zwei Dinge sollte man auseinanderhalten, weil die Berichterstattung sie zusammenzieht.

Die Überschrift, unter der der Fund auf Hacker News lief, verknüpft die Scans mit gefälschten KI-Bots. Die Datenquelle gibt das so nicht her. Known Agents weist Spoofing separat aus und zählt eine Anfrage dann als gefälscht, wenn sie eine bekannte Agenten-Identität behauptet, aber deren Authentifizierung nicht besteht, also verifizierte IP oder Web Bot Auth. Die Anteile sind klein: Googlebot 0,5 Prozent, ChatGPT-User 0,1 Prozent, ClaudeBot 0,1 Prozent. Die Seite stellt Scans und Spoofing nebeneinander, ohne das eine dem anderen zuzuschreiben.

Der belastbare Teil ist die Pfadliste. Und die genügt, denn sie sagt etwas Einfaches: Jemand hält es für lohnend, systematisch nach diesen Dateien zu suchen.

Zur weiteren Einordnung aus derselben Auswertung: 35 Prozent des gemessenen Verkehrs kommen von Bots, robots.txt wird zu 98,5 Prozent befolgt, und ClaudeBot ist mit 27 Prozent der stärkste einzelne Agent im Feld. Die Scanner gehören zu den 1,5 Prozent, die sich um robots.txt nicht scheren.

Was in diesen Dateien tatsächlich steht

Hier wird es interessanter, als die Liste vermuten lässt. Wir haben für die verbreitetsten Werkzeuge in der Dokumentation nachgesehen, und das Ergebnis ist gemischt.

Bei Claude Code liegen Schlüssel also gar nicht dort, wo gesucht wird. Auch Zugangsdaten für Plugins wandern in den Keychain des Betriebssystems, nicht in die Einstellungsdatei. Zwei Einschränkungen bleiben: settings.json kennt einen env-Block, in den Leute erfahrungsgemäß Umgebungsvariablen samt Schlüssel schreiben, und apiKeyHelper verweist auf ein Skript, das Rückschlüsse auf den Aufbau der Umgebung erlaubt.

Bei Codex rät die Dokumentation ausdrücklich davon ab, Schlüssel in die TOML-Datei zu schreiben, auch wenn ein entsprechendes Feld existiert. Der Scanner fragt trotzdem nach, weil es nichts kostet.

Aider ist der Fall, bei dem ein Treffer wirklich weh tut. Dort ist der Klartext-Schlüssel in der YAML-Datei dokumentierter Normalweg.

Der Mechanismus, um den es eigentlich geht

Ein Scanner fragt diese Pfade über HTTP ab. Er kommt also nur an sie heran, wenn ein Webserver sie ausliefert. Niemand veröffentlicht solche Dateien absichtlich, aber es gibt ein paar Wege, auf denen sie trotzdem im Netz landen.

Der häufigste ist das Deployment, bei dem der Server auf genau das Verzeichnis zeigt, in dem auch entwickelt wurde. Dann liegt .claude/ mit im Auslieferungspfad. Ähnlich läuft es über das Repository: Eine projektbezogene .aider.conf.yml ohne passenden .gitignore-Eintrag wird eingecheckt und wandert von dort in jedes Deployment. Und ein COPY . . im Dockerfile nimmt beim Bauen alles mit, auch das, was niemand im Image haben wollte.

Der Punkt ist erfreulich unspektakulär: Es geht nicht um eine Lücke in den Werkzeugen, sondern darum, dass ihre Konfiguration jetzt Beute ist. Das ist eine Hygienefrage, und Hygienefragen lassen sich abhaken.

Was sich in zehn Minuten prüfen lässt

Der einfachste Test ist, die Pfade selbst gegen die eigene Anwendung abzufragen:

for p in .claude/settings.json .claude.json .codex/config.toml .aider.conf.yml .continue/config.json .env; do
  printf '%s -> ' "$p"
  curl -s -o /dev/null -w '%{http_code}\n' "https://eure-domain.example/$p"
done

Alles außer 403 und 404 gehört angesehen.

Danach ist die wirksamste Einzelmaßnahme ein pauschales Verbot im Webserver für alle Pfade, die mit einem Punkt beginnen, mit der bekannten Ausnahme für .well-known. Das deckt auch die Werkzeuge ab, die es nächsten Monat gibt. Dazu die Konfigurationsdateien in .gitignore und .dockerignore eintragen, projektbezogen und global. Und wer Aider nutzt, sollte einmal nachsehen, ob in der .aider.conf.yml wirklich ein Schlüssel steht, und ihn in eine Umgebungsvariable verschieben.

Wer einen Treffer findet, sollte den betroffenen Schlüssel als kompromittiert behandeln und rotieren. Automatisierte Scans sind schnell, aber sie sind auch stumpf, und die allermeisten Anfragen aus dieser Liste laufen ins Leere. Genau deshalb ist es machbar, auf der richtigen Seite dieser Statistik zu stehen.