In öffentlichen GitHub-Repositories stecken Zehntausende Zugangsdaten, die aus den Einstellungsdateien von Claude Code stammen. Anthropic wurde nicht gehackt. Die Dateien wurden mitcommittet.
Claude Code settings.local.json ist die Datei, um die es geht
Der Weg in die Öffentlichkeit beginnt mit einer Bequemlichkeit. Claude Code fragt vor jedem Shell-Befehl um Erlaubnis.
Wer eine API abfragt, klickt nach dem dritten Mal auf „Yes, and don't ask again". Damit speichert Claude Code die Regel dauerhaft in der Datei Claude Code settings.local.json im Projektordner, und diese Regel enthält den kompletten Befehl samt Schlüssel im Klartext.
Genau das ist der Kern. Es braucht keinen Exploit, keinen Angreifer und keine Lücke im Modell. Es reicht ein Entwickler, der eine Freigabe nicht mehr liest, weil sie zum dritten Mal kommt.
Laut GitGuardian sitzen alle Fundstellen, die sich zuordnen ließen, in Allow-Regeln oder Umgebungsblöcken. In Deny-Regeln fand sich kein einziger Schlüssel.
Warum die Datei trotz gitignore in Repos landet
Claude Code versucht, das Problem selbst zu lösen. Wenn das Tool die Datei anlegt, trägt es sie in die globale gitignore-Datei des Entwicklers ein.
Diese Regel reist nicht mit, denn sie deckt keinen Ordner ab, der später zum Repository wird, keinen Klon auf einem anderen Rechner und keine Datei, die schon vorher versioniert war, und im Repository selbst steht nichts, was die Datei schützt.
Dazu kommt ein zweiter Weg, der oft übersehen wird. Ein Dockerfile mit COPY . . kopiert das Arbeitsverzeichnis und nicht den Git-Index. GitGuardian fand 613 Zugangsdaten in öffentlichen Docker-Hub-Images, 99 davon waren beim Test noch gültig, und ein Cloudflare-Token tauchte in 559 Tags desselben Images auf.
Wie groß der Claude Code secrets leak ist
Zwei Sicherheitsfirmen haben unabhängig gezählt, und ihre Zahlen beantworten verschiedene Fragen.
Apiiro fand 104.185 öffentliche Kopien solcher Dateien in 103.617 Repositories und darin 2.539 vertrauliche Zugangsdaten in 1.994 Repositories, wobei die Funde von einzelnen Entwicklerkonten bis zu 63 betroffenen Organisationen reichen. Die Beispiele klingen nach Albtraum: ein Admin-Schlüssel eines Datenbankanbieters, ein Produktionspasswort für Azure Postgres, ein Square-Token, das Besitzerpasswort einer Datenbank mit Krankenakten.
GitGuardian zählte anders, nämlich jeden jemals gepushten Stand. Das Ergebnis sind 31.088 verschiedene Secrets in 23.276 Repositories, und 5.343 davon funktionierten noch, als das Team sie mit einem automatischen, rein lesenden Test prüfte, ohne einen einzigen Schlüssel einzusetzen. Das ist etwa jedes sechste, nicht jedes.
Die Verteilung erklärt, warum das so lange niemandem auffiel. Die Masse sind Bearer-Token in curl-Aufrufen, die schnell ablaufen. Die gefährlichen Treffer sind Datenbank- und SSH-Zugänge, weil sie selten ablaufen und oft weitreichende Rechte haben.
Bemerkenswert ist der Trend. Im April 2026 wurden 12.535 Fälle in einem Monat registriert, im Oktober nur noch 959. Was den Rückgang ausgelöst hat, weiß GitGuardian selbst nicht.
Warum Scanner den AI agent secret leak übersehen
Die naheliegende Antwort wäre: Die Leute haben einfach keine Scanner laufen. So einfach ist es nicht.
Gitleaks und TruffleHog suchen nach bekannten Schlüsselformaten, also nach Anbieternamen, Präfixen und langen Zufallszeichen, und genau dieses Muster fehlt bei einem Passwort, das jemand in eine Freigabe getippt hat. Ein Passwort hinter PGPASSWORD=, sshpass -p oder mysql -p sieht aus wie ein gewöhnliches Wort in einem gewöhnlichen Befehl. Apiiro misst, dass die beiden Werkzeuge zusammen etwa jede fünfte leckende Datei übersehen.
Bei einem „AI agent secret leak" versagt damit genau die Prüfung, auf die sich viele Teams verlassen. Der Schlüssel steht nicht in einer .env-Datei mit klarem Namen, sondern mitten in einer Kommandozeile, die jemand freigegeben hat.
Was Anthropic zu Claude Code GitHub security sagt
Anthropic hat auf die Berichte reagiert, aber nicht mit einem Patch.
Boris Cherny, der bei Anthropic Claude Code verantwortet, schrieb auf Hacker News, das Team schaue sich an, was man dagegen tun könne, ohne einen Zeitplan oder eine geplante Änderung zu nennen. Er stellte klar, dass die Datei nicht in die Versionsverwaltung gehört und dass Claude sie automatisch ignoriert, wenn das Tool sie selbst anlegt. In den gemeldeten Fällen sei sie von Hand erstellt und eingecheckt worden.
Sein Rat an Entwickler: den Auto-Modus statt gepflegter Allow-Listen nutzen und in GitHub die Secret-Scanning-Funktion einschalten, unabhängig davon, welcher Agent läuft.
Ein standardmäßiger Ignore-Eintrag im Repository ist bislang nicht angekündigt.
Die Prüfliste für Claude Code settings.local.json
Wer wissen will, ob das eigene Projekt betroffen ist, kann das in wenigen Minuten klären.
Die erste Suche geht über die GitHub-Code-Suche nach dem Dateinamen, beschränkt auf die eigene Organisation. Die zweite gilt lokalen Klons und alten Branches. Die dritte den gebauten Images, weil dort der Git-Index keine Rolle spielt.
Findet sich etwas, ist Löschen der falsche erste Schritt. Ein Token, das einmal öffentlich war, gilt als verbrannt, weil Klone, Forks und Caches es behalten.
Kein Angriff, ein Commit.
Wie lange ist der Schlüssel schon öffentlich?
Wer den Schlüssel nur aus dem Repo löscht und die Historie umschreibt, hat das Problem versteckt und nicht gelöst, weil Klone, Forks und Build-Caches die alte Version weiter tragen, bis jemand sie findet.
Die Reihenfolge lautet: Schlüssel widerrufen, neue Zugangsdaten ausstellen, Protokolle auf Nutzung prüfen, dann aufräumen. Wer in Deutschland für Kunden entwickelt, sollte den Vorgang außerdem mit dem Auftraggeber klären, bevor dieser es aus einer Meldung erfährt.
Dauerhaft hilft nur ein anderer Umgang mit Geheimnissen. Statt sie in Befehle zu tippen, gehören sie in einen Secrets Manager, auf den die Umgebungsvariable verweist.
Was beim Claude Code secrets leak offen bleibt
Drei Punkte sind weiter unklar, und sie ändern nichts an der Dringlichkeit.
Erstens: Wie viele der gefundenen Schlüssel wirklich aktiv waren, lässt sich nur nachträglich schätzen. Die 5.343 von GitGuardian sind eine Untergrenze, weil das Team nur zählte, was ein automatischer Test bestätigen konnte.
Zweitens: Warum die Fallzahlen seit April um mehr als 90 % gefallen sind, weiß niemand. Möglich sind bessere Voreinstellungen, schnellere Löschung oder ein verändertes Meldeverhalten.
Drittens: Ob Anthropic eine Sperre einbaut, die unabhängig vom Erstellungsweg greift. Bis dahin bleibt es dabei, dass ein Werkzeug für Agenten eine Datei mit Klartextschlüsseln im Projektordner hinterlässt.
Wer den Ordner .claude wie eine .env-Datei behandelt, liegt richtig. Dort stehen nicht nur Einstellungen, dort stehen Zugänge.
