Claude Codes Funktion „Nicht erneut fragen“ leakt Secrets in öffentlichen Repositories

Passwörter und API-Schlüssel, die in Shell-Befehle eingegeben werden, die über den Claude Code-Assistenten von Anthropic genehmigt wurden, sind in öffentlichen GitHub-Repositories exponiert. Das Sicherheitsunternehmen Apiiro berichtete am 6. November 2026, dass der KI-Assistent diese Zugangsdaten im Klartext speichert, wenn Benutzer die Option „Ja, und nicht erneut fragen“ auswählen.

Was passiert ist

Wenn Entwickler Claude Code nutzen, bittet der Assistent vor der Ausführung von Shell-Befehlen um Erlaubnis. Wenn ein Benutzer beschließt, einen bestimmten Befehl dauerhaft zu genehmigen, speichert das Tool die exakte Befehlszeichenkette, einschließlich eingebetteter Secrets, in einer lokalen Konfigurationsdatei namens .claude/settings.local.json. Zwar versucht das Tool, diese Datei aus der Versionskontrolle auszuschließen, indem es sie zu den globalen Git-Ausschlusslisten des Benutzers hinzufügt, aber es fügt die Datei nicht zur .gitignore des Projekts hinzu. Folglich wird die Datei Teil der Repository-Historie, wenn sie manuell oder vom Agenten selbst committet wird.

Apiiro durchsuchte öffentliche GitHub-Repositories und identifizierte 104.185 Kopien dieser Einstellungsdatei in 103.617 Repositories. Von diesen enthielten 1.122 Dateien mindestens ein Secret, was insgesamt 1.379 eindeutigen exponierten Zugangsdaten entspricht. Die geleakten Daten umfassen 379 Datenbank-Passwörter, 43 SSH-Anmeldedaten für öffentliche Server, 42 Tokens für Dienste wie GitHub und npm sowie 23 AWS-Schlüssel. Forscher bestätigten, dass bei einem benachrichtigten Unternehmen ein aktiver Schlüssel über diesen Mechanismus exponiert war.

Die Exposition ist persistent, da das Entfernen der Datei aus dem aktuellen Branch sie nicht aus der Git-Historie oder Forks löscht. In 539 der untersuchten Repositories änderten Commits, die Claude als Mitautor auflisteten, die Datei, was darauf hindeutet, dass der Agent oft seine eigenen Konfigurationsänderungen committet. Zusätzlich enthielten 298 Kopien der geteilten .claude/settings.json-Datei, die Teams absichtlich committen, ebenfalls Secrets. Unter Einbeziehung historischer Versionen und Agent-Chats steigt die Gesamtzahl der exponierten Secrets auf 2.539 in 1.994 Repositories.

Wie es funktioniert

Die Schwachstelle resultiert daraus, wie Claude Code die Befehlsgenehmigung handhabt. Standardmäßig fragt es Benutzer vor der Ausführung von Shell-Befehlen nach. Wenn ein Benutzer „Ja, und nicht erneut fragen“ auswählt, erstellt das System eine Allow-Regel in .claude/settings.local.json. Diese Regel stimmt mit zukünftigen Befehlen überein, um wiederholte Abfragen zu vermeiden. Wenn der genehmigte Befehl eine exakte Zeichenkette und kein Muster ist, wird jedes Passwort oder Token, das in diesen Befehl eingegeben wurde, wortwörtlich in der JSON-Datei gespeichert.

Obwohl Claude Code die Datei bei der ersten Erstellung in einem Repository zu den globalen Git-Ausschlusslisten des Benutzers hinzufügt, ist dieser Schutz lokal auf die spezifische Maschine und den Benutzer beschränkt. Er wird nicht an andere Mitarbeiter weitergegeben und schützt nicht vor versehentlichen Commits. Darüber hinaus übersehen Standard-Tools zur Secret-Erkennung diese Lecks oft. In Tests markierte gitleaks nur 564 der 1.122 exponierten Dateien, und TruffleHog markierte 643. Beide Tools übersahen 215 Dateien vollständig, da sie nach bekannten Schlüsselformaten suchen, während Passwörter, die in Befehle wie mysql -p eingebettet sind, als gewöhnlicher Text erscheinen.

Wichtige Details

• Apiiro fand 1.122 öffentliche Kopien von .claude/settings.local.json, die mindestens ein Secret enthielten.
• Zu den exponierten Secrets gehören 379 Datenbank-Passwörter, 43 SSH-Anmeldedaten und 23 AWS-Schlüssel.
• Claude Code ist der einzige Coding-Agent unter 16 geprüften, bei dem bestätigt wurde, dass er standardmäßig vollständige genehmigte Befehle in Projektdateien speichert.
• Standard-Scanner wie gitleaks und TruffleHog konnten 215 der exponierten Secrets nicht erkennen.
• Vier Fehlerberichte bezüglich dieses Verhaltens wurden von einem automatisierten Bot ohne Antwort von Anthropic geschlossen.
• Secrets bleiben in der Git-Historie und in Forks zugänglich, selbst nachdem die Datei aus dem Hauptbranch gelöscht wurde.

Warum es wichtig ist

Für Software-Ingenieure hebt dieser Vorfall eine kritische Lücke im Sicherheitsmodell von KI-Coding-Assistenten hervor. Entwickler gehen oft davon aus, dass lokale Konfigurationsdateien vor öffentlicher Offenlegung sicher sind, insbesondere wenn Tools behaupten, Git-Ausschlüsse zu verwalten. Da jedoch globale Git-Einstellungen verwendet werden, kann jeder Mitarbeiter, der die Datei committet, oder jeder Fehler in der lokalen Konfiguration sensible Daten leaken. Die Tatsache, dass der KI-Agent selbst diese Dateien committen kann, verschärft das Risiko, da Entwickler möglicherweise nicht jede Änderung überprüfen, die vom Assistenten vorgenommen wird.

Sicherheitsteams müssen agentenspezifische Ordner und Gedächtnisdateien nun mit derselben Sorgfalt behandeln wie .env-Dateien. Das Versagen standardmäßiger Scan-Tools, Passwörter zu erkennen, die in Befehlszeichenketten eingebettet sind, bedeutet, dass bestehende CI/CD-Pipelines ein falsches Gefühl der Sicherheit vermitteln können. Organisationen müssen ihre Pre-Commit-Hooks und Konfigurationen zur Secret-Erkennung aktualisieren, um gezielt auf diese neuen Vektoren abzuzielen und sicherzustellen, dass Passwörter innerhalb von Befehlen neben traditionellen API-Schlüsselformaten markiert werden.

Was Sie tun können

• Durchsuchen Sie Ihre GitHub-Organisation nach .claude/settings.local.json und .claude/settings.json, einschließlich in der Git-Historie.
• Rotieren Sie jedes Passwort, Token und jeden Schlüssel, der jemals in diesen Dateien gespeichert wurde, bevor Sie mit der Bereinigung beginnen.
• Führen Sie git rm --cached .claude/settings.local.json aus und fügen Sie die Datei zur .gitignore Ihres Repositories hinzu.
• Überprüfen Sie die lokale Einstellungsdatei auf Ihrem Rechner manuell und löschen Sie alle Regeln, die hartcodierte Secrets enthalten.
• Verwenden Sie Umgebungsvariablen (z. B. $DB_URL) in Befehlen, anstatt Secrets direkt einzugeben, sodass die gespeicherte Regel auf den Variablennamen verweist.
• Genehmigen Sie Befehlsmuster (z. B. npm run:*) anstelle einzelner exakter Befehle, um zu verhindern, dass spezifische Argumente gespeichert werden.