Apiiro hat Zehntausende öffentliche Kopien einer Konfigurationsdatei von Claude Code auf GitHub gefunden, und mehr als tausend davon enthalten ausnutzbare Secrets. Verantwortlich ist eine Funktion, die den Alltag mit dem Agenten beschleunigen soll und den freigegebenen Befehl speichert, ohne zwischen Zugangsdaten und einem harmlosen Argument zu unterscheiden.
Eine vertrauenswürdige Datei, die auch Secrets merkt
Antwortet ein Entwickler auf eine Ausführungsanfrage mit „Yes, and don’t ask again“, schreibt Claude Code die Regel in .claude/settings.local.json im Projektstamm. Bezieht sich die Regel auf einen exakten Befehl statt auf ein generisches Muster, wird jedes in diesem Befehl eingegebene Argument, ein Passwort oder ein API-Token eingeschlossen, im Klartext gespeichert. Das Tool trägt die Datei in die globalen Git-Ausschlüsse der Maschine ein, auf der sie entstanden ist, nicht aber in die .gitignore des Repositorys: Der Schutz reist also nicht mit dem Code mit. Die Parallele zu einem sauberen Umgang mit Umgebungsvariablen und Secrets drängt sich hier auf: Ein Zugangsdatum, das über einen Shell-Befehl statt über einen dedizierten Manager läuft, bleibt beim ersten Fehltritt exponiert.
Das Ausmaß des Problems laut Apiiro
Das Sicherheitsunternehmen zählte mehr als 104.000 Kopien dieser Datei in mehr als 103.000 öffentlichen Repositories. Davon enthalten 1.122 mindestens ein ausnutzbares Secret, insgesamt 1.379 unterschiedliche Secrets. Rechnet man die Git-Historie, doppelte Forks und eine zweite Konfigurationsdatei, .claude/settings.json, hinzu, steigt die Gesamtzahl auf 2.539 Secrets in 1.994 Repositories und 63 Organisationen.
| Secret-Kategorie | Festgestellte Menge | Hauptrisiko |
|---|---|---|
| Datenbank-Passwörter | 379 | Direkter Zugriff auf Produktionsdaten |
| Tokens (GitHub, GitLab, npm) | 42 | Code im Namen eines Kontos veröffentlichen oder ändern |
| SSH-Zugänge zu öffentlichen Servern | 43 | Übernahme einer exponierten Maschine |
| AWS-Schlüssel | 23 | Zugriff auf die Cloud-Infrastruktur des betroffenen Kontos |
Unter den genannten Fällen finden sich ein Cloud-Schlüssel mit Administratorrechten eines Datenbankanbieters und das Eigentümerpasswort einer Datenbank mit Patientenakten. Die Forscher prüften nicht systematisch, ob jedes Secret noch aktiv war, doch ein benachrichtigtes Unternehmen bestätigte, dass einer seiner Schlüssel noch funktionierte.
Warum klassische Scanner es übersehen
Von den 1.122 Dateien mit einem Secret erkannte gitleaks 564 und TruffleHog 643; 215 entgingen beiden, weil ein mitten in einer Befehlszeile verstecktes Secret nicht immer wie ein Standard-API-Schlüssel aussieht. Apiiro empfiehlt, Agenten-Ordner, .claude/ ebenso wie .cursor/, als Risikozonen auf dem Niveau einer .env-Datei zu behandeln und Pre-Commit- und CI-Scanner entsprechend zu verstärken, eingebettet in das bereits vorhandene Kommandozeilen-Werkzeugset auf dem Entwicklungsrechner.
In 1.105 untersuchten Repositories, in denen ein Commit Claude als Mitautor ausweist, zeigen 539 eine automatische Änderung dieser Konfigurationsdatei durch den Agenten selbst.
So wird die Konfiguration jetzt korrigiert
Die Reihenfolge der Schritte zählt: Zuerst die offengelegten Zugangsdaten widerrufen, dann erst das Repository bereinigen, denn eine bereinigte Git-Historie entfernt nichts, was Crawler bereits indexiert haben könnten.
# 1. Datei aus der Versionskontrolle entfernen, ohne sie von der Festplatte zu löschen
git rm --cached .claude/settings.local.json
# 2. Zur .gitignore des Projekts hinzufügen, nicht nur zum globalen Ausschluss
echo ".claude/settings.local.json" >> .gitignore
# 3. Prüfen, ob eine freigegebene Regel einen vollständigen Befehl mit Secret enthält
grep -n "Bearer\|password\|API_KEY" .claude/settings.local.json
git rm --cached bereinigt die Historie nicht: Jedes bereits committete Secret bleibt in alten Commits und bestehenden Forks lesbar. Die sofortige Rotation des Secrets bleibt der einzige verlässliche Schutz.Was man sich merken sollte
- Claude Codes Funktion „don’t ask again“ kann ein Secret im Klartext in eine Projektdatei schreiben, die standardmäßig nicht auf Repository-Ebene geschützt ist.
- In öffentlichen Repositories wurden mehr als 1.300 ausnutzbare Secrets gefunden, darunter Datenbank-, SSH- und Cloud-Zugänge.
- Klassische Secret-Scanner übersehen fast jeden fünften Fall, wenn das Zugangsdatum mitten in einem Befehl versteckt ist.
- Die Korrektur beginnt mit der Rotation der Zugangsdaten vor jeder Bereinigung des Repositorys, gefolgt vom Eintrag der Datei in die
.gitignoredes Projekts.
Bei Projekten, die im Alltag begleitet werden, wird diese Agenten-Konfigurationsdatei genauso behandelt wie eine Umgebungsdatei: Sie landet niemals in einem Commit, Punkt. Die Gewohnheit, „don’t ask again“ zu antworten, um ein paar Sekunden zu sparen, hat Kosten, die erst sichtbar werden, wenn ein Repository öffentlich wird. Ein Secrets-Manager kombiniert mit Freigaberegeln, die auf Mustern statt auf exakten Befehlen beruhen, löst das Problem an der Wurzel, ohne auf den Komfort zu verzichten, den diese Agenten ansonsten bringen, dazu passend die Erfahrungen zu redaktionellen Agenten im Produktivbetrieb. — Simon Janvier
Zum Weiterlesen: der vollständige Apiiro-Bericht, via The Hacker News.
