Claude Code legt Passwörter offen auf GitHub ab

Wer in Claude Code einen Befehl dauerhaft freigibt, speichert ihn samt Passwort im Klartext. Forscher fanden über 2.500 echte Zugangsdaten in öffentlichen Repositories. So prüfen und schützen sich Unternehmen.

Schlüsselbund aus Messingschlüsseln und ein einzelner Schlüssel liegen offen auf einer Glasablage in einem hellen, leeren Flur

Eine bequeme Schaltfläche in Claude Code sorgt dafür, dass Datenbank-Passwörter, SSH-Zugänge und Cloud-Schlüssel in öffentlichen Git-Repositories landen. Das zeigt eine Untersuchung des Sicherheitsunternehmens Apiiro, die am 6. November 2026 erschien. heise und die Cloud Security Alliance (CSA) haben die Ergebnisse aufgegriffen. Betroffen sind vor allem Teams, die Claude Code im Alltag nutzen und ihre Projekte auf GitHub veröffentlichen, ob als Open Source, für Kunden oder versehentlich.

Wie die Passwörter in die Datei kommen

Claude Code fragt vor Shell-Befehlen nach, ob es sie ausführen darf. Wer „Yes, and don't ask again“ wählt, gibt den Befehl dauerhaft frei. Claude Code speichert ihn dafür als Regel in der Datei .claude/settings.local.json, und zwar vollständig. Stand im Befehl ein Passwort oder Token, etwa bei einem Datenbankzugriff, liegt es danach im Klartext in dieser Datei.

Eigentlich soll die Datei nie in Git landen. Claude Code trägt sie dafür in die globale Ignore-Liste von Git auf dem Rechner ein, nicht in die .gitignore des Projekts. Laut heise greift dieser Schutz nicht, wenn ein Ordner erst später zum Repository wird, geklont wurde oder die Datei schon committet ist. Die CSA weist zudem darauf hin, dass die Datei auch über npm-Pakete und Archive nach außen gelangen kann.

Die Zahlen

Apiiro fand nach Angaben der CSA 104.185 öffentliche Kopien der Datei in 103.617 Repositories. 1.122 davon enthielten mindestens ein Geheimnis. Zählt man Git-Historie, geteilte Einstellungsdateien und Chat-Protokolle von Agenten dazu, kommen die Forscher auf 2.539 Geheimnisse in 1.994 Repositories. Darunter:

  • 379 Datenbank-Passwörter
  • 43 SSH-Zugänge zu öffentlichen Servern
  • 23 AWS-Schlüssel
  • 42 Token für GitHub, GitLab und npm

Besonders unangenehm: Laut heise hatte in 539 von 1.105 Repositories mit echten Geheimnissen Claude selbst als Mitautor die Datei per Commit verändert. Und gängige Scanner helfen nur bedingt. Gitleaks erkannte 564 der 1.122 Dateien, TruffleHog 643. Beide übersahen 215 Dateien, meist weil das Passwort in der Befehlssyntax steckte, etwa bei PGPASSWORD=, sshpass -p oder mysql -p.

Ein geöffneter kleiner Stahltresor in einem hellen Raum, aus dessen Tür einige weiße Papierblätter herausfliegen

Was Anthropic sagt

Eine offizielle Stellungnahme zu den Ergebnissen gibt es laut CSA nicht. Ältere Fehlerberichte zum Thema auf GitHub wurden automatisch geschlossen, einer davon im Januar 2026 als „not planned“. Laut Apiiro hat sich Boris Cherny, Leiter von Claude Code, in einer Diskussion auf Hacker News geäußert: Das Team prüfe, wie sich das Problem verhindern lasse. Im Gespräch seien ein Abfangen solcher Fälle im Auto-Modus und ein einfaches Secret-Scanning direkt in Claude Code. Beides ist bisher nur angekündigt. Es ist nicht das erste Datenschutzproblem des Werkzeugs in diesen Tagen: Erst vor wenigen Tagen wurde bekannt, dass Claude Code Konto-E-Mails an fremde Websites weitergab.

Die CSA formuliert die wichtigste Regel für Betroffene unmissverständlich:

„Rotation comes first, because deleting the file or rewriting history does not undo a leak.“

Wer die Datei nur löscht, hat also nichts gewonnen. Ein einmal veröffentlichtes Passwort muss als bekannt gelten.

Was das für Ihr Unternehmen heißt

  • Suchen: Durchsuchen Sie Ihre GitHub-Organisation, Forks, die komplette Git-Historie und veröffentlichte npm-Pakete nach .claude/settings.local.json und .claude/settings.json.
  • Zuerst austauschen: Jedes gefundene Passwort, jeden Schlüssel und jedes Token sofort ändern. Erst danach Datei und Historie bereinigen.
  • Projekt absichern: Die Datei mit git rm --cached aus Git entfernen und .claude/settings.local.json in die .gitignore jedes Projekts aufnehmen, ebenso in .npmignore und .dockerignore.
  • Keine Passwörter in Befehlen: Zugangsdaten gehören in Umgebungsvariablen oder einen Passwort-Manager, nicht in die Kommandozeile. Dann landen sie auch in keiner Freigabe-Regel.
  • Scanner nachschärfen: Eigene Regeln für Muster wie PGPASSWORD= oder mysql -p ergänzen, weil die Standardregeln sie übersehen.
  • Zentral steuern: Wo Claude Code im Team verwaltet wird, mit zentralen Verbotsregeln für .env-Dateien und Geheimnis-Ordner arbeiten. Wie teuer gestohlene Zugänge werden können, zeigt unser Beitrag zu LLMJacking.

Fazit

Das Problem ist kein klassischer Fehler, sondern eine Komfortfunktion, die Geheimnisse an einem Ort ablegt, an dem sie niemand vermutet. Coding-Agenten erzeugen neue Konfigurationsdateien, und die gehören genauso in die Sicherheitsprüfung wie .env-Dateien. Wenn Sie Ihre Repositories prüfen lassen oder den Einsatz von KI-Agenten im Team sauber aufsetzen möchten, sprechen Sie mich gern an.

Richard von Rüden
Über den Autor Richard von Rüden Senior Entwickler & AI Engineer

Seit über 15 Jahren entwickle ich Websites und Apps und beschäftige mich intensiv mit KI-Automatisierung sowie Datenschutz. In meinen Artikeln teile ich aktuelle News, fundiertes Fachwissen und Erfahrungen aus zahlreichen Projekten.

Kostenlose Beratung
← Zurück zu den News