Claude Code legte Passwörter und Schlüssel in 1.122 öffentlichen GitHub-Dateien offen

Passwörter und API-Schlüssel, die Entwickler in genehmigte Befehle in Claude Code eingegeben haben, liegen in öffentlichen GitHub-Repositories, wo sie jeder lesen kann. Das zeigt eine Studie des Sicherheitsunternehmens Apiiro, veröffentlicht am 5. November 2026 und aufgegriffen von The Hacker News.

Das Problem ist der Modus „Yes, and don't ask again“ („Ja, und nicht erneut fragen“). Wer einen Befehl mit dieser Option genehmigt, lässt Anthropic' Programmierassistenten die Berechtigungsregel in der Datei .claude/settings.local.json des Projekts speichern — und wenn die Regel für einen exakten Befehl gilt, wird der gesamte Befehl Wort für Wort gespeichert, einschließlich jedes darin eingegebenen Passworts oder Tokens, im Klartext.

Was Apiiro gefunden hat

Die Forscher durchsuchten das öffentliche GitHub und fanden 104.185 Kopien der Datei in 103.617 Repositories. Davon enthielten 1.122 Kopien (etwa 1,1 %) mindestens ein Secret, insgesamt 1.379 verschiedene Secrets allein in den aktuellen Kopien der lokalen Datei. Zählt man die Git-Historie, die geteilte Datei .claude/settings.json und gespeicherte Agenten-Chatprotokolle hinzu, liegt die Gesamtzahl bei 2.539 Secrets in 1.994 Repositories, unter Beteiligung von 63 Organisationen.

  • 379 Datenbankpasswörter — mehr als ein Drittel der Secrets eröffnet direkten Zugang zu einer Datenbank;
  • 43 SSH-Anmeldedaten öffentlicher Server;
  • 42 Tokens für GitHub, GitLab und npm;
  • 23 AWS-Schlüssel;
  • Zu den schwerwiegendsten Fällen zählen laut den Forschern ein Cloud-Schlüssel mit Administratorrechten eines Datenbankanbieters und das Besitzerpasswort einer Datenbank mit Patientenakten.

Das Löschen der Datei aus dem Projekt macht das Leck nicht rückgängig: Ältere Versionen bleiben in der Git-Historie und in Forks erhalten. Die Forscher fanden weitere 734 Secrets in älteren Versionen der Datei, in 509 Repositories, und 211 Forks von 74 Repositories mit denselben Secrets. Am Montag der Veröffentlichungswoche lagen alle Dateien mit Secrets noch im Hauptbranch ihrer Repositories — und in der Hälfte der Fälle seit mindestens 217 Tagen.

Warum die Scanner so viel übersehen haben

Die Forscher testeten die Secret-Scanner gitleaks und TruffleHog an den 1.122 Kopien mit Secrets: gitleaks meldete 564 und TruffleHog 643 — und 215 wurden von keinem der beiden gemeldet. Die meisten Fehlschläge sind Passwörter, die in Befehle eingetippt wurden: Sie entsprechen keinem bekannten Schlüsselformat und wirken wie gewöhnliche Wörter in einer Befehlszeile.

Ein Designdetail steht im Zentrum des Problems: Claude Code trägt die Datei beim Erstellen in die globalen Git-Ausschlüsse des Nutzers ein, fügt sie aber niemals zur .gitignore des Projekts selbst hinzu — der Schutz reist also nicht mit dem Code mit. In 539 der 1.105 nachverfolgten Repositories hat ein Commit, der Claude als Co-Autor nennt, die Datei verändert, was darauf hindeutet, dass der Agent die Datei oft selbst committet.

Was jetzt zu tun ist

Die Empfehlung der Forscher lautet, Zugangsdaten zu rotieren, bevor irgendetwas bereinigt wird:

  1. Suchen Sie in Ihrer GitHub-Organisation nach .claude/settings.local.json und .claude/settings.json und prüfen Sie die Git-Historie jedes Repositories, auch dort, wo die Dateien schon gelöscht sind;
  2. Zuerst rotieren: Ändern Sie alle Passwörter, Tokens und Schlüssel, die diese Dateien je enthalten haben, bevor Sie aufräumen;
  3. Entfernen Sie die lokale Datei mit git rm --cached .claude/settings.local.json aus der Versionskontrolle und tragen Sie sie in die .gitignore des Repositories ein;
  4. Öffnen Sie die Datei auf Ihrem eigenen Computer und löschen Sie jede Regel, die ein Secret enthält, auch wenn sie nie zu GitHub gelangt ist;
  5. Legen Sie niemals Secrets in Befehle: Verweisen Sie auf sie als Variablen aus einem Secret-Manager, etwa $DB_URL, damit die gespeicherte Regel den Variablennamen enthält, nicht das Secret;
  6. Genehmigen Sie Muster wie Bash(npm run:*) statt einzelner Befehle.

Eine alte Warnung ohne Antwort

Nutzer von Claude Code hatten dieses Verhalten bereits gemeldet: Ein Fehlerbericht vom 11. August 2025 besagte, dass genehmigte Befehle mit API-Schlüsseln und Tokens Wort für Wort in settings.local.json gespeichert wurden. Ein automatisierter Bot schloss den Bericht am 3. Januar nach 60 Tagen ohne Aktivität als „nicht geplant“. Laut den Forschern wurden alle vier einschlägigen Berichte, die in der Studie zitiert werden, von demselben Bot geschlossen — der jüngste am Tag vor der Veröffentlichung — und keiner erhielt eine Antwort von Anthropic.

Eine Grenze der Ergebnisse sollte klar benannt werden: Apiiro hat nicht geprüft, ob die gefundenen Zugangsdaten noch funktionieren — ein „echtes Secret“ bedeutet in der Studie einen Wert, der einem bekannten Format oder einem verifizierten Kontext entsprach, mit Zustimmung eines KI-Prüfers. Ein benachrichtigtes Unternehmen bestätigte, dass sein Schlüssel zum Zeitpunkt der Entdeckung aktiv war. Von den 16 Programmieragenten, deren Dokumentation die Forscher verglichen, ist Claude Code der einzige, bei dem bestätigt ist, dass er standardmäßig den vollständigen genehmigten Befehl in einer Projektdatei speichert.

Geekiki hat bereits über einen anderen Sicherheitsfall rund um Claude Code berichtet: Claude umging die Sicherheitsüberwachung von Anthropic mit Fiktion und Imkerei.

Quellen

Bildnachweis: The Hacker News.

Transparenzhinweis: Dieser Artikel wurde mithilfe künstlicher Intelligenz erstellt, unter Abgleich öffentlicher Informationen aus Internetquellen, darunter die Originalstudie von Apiiro und die Berichterstattung von The Hacker News. Die Fakten wurden anhand der zitierten Quellen geprüft; bitte konsultieren Sie die Originalquellen, um die Details zu bestätigen.

Muse