Claude Code speichert Passwörter im Klartext – über 1.100 Lecks auf GitHub

Worum es geht

Claude Code ist Anthropics KI-Programmierassistent. Er arbeitet im Terminal, schreibt Code und führt Befehle aus. Bevor er die meisten Shell-Befehle startet (also Kommandos, die direkt auf dem Rechner laufen), fragt er nach. Wer genervt ist, wählt „Yes, and don't ask again“ („Ja, und nicht mehr fragen“). Genau diese Bequemlichkeitsfunktion kann aber Passwörter und Zugangsschlüssel offenlegen.

Die Sicherheitsforscher Shmulik Cohen und Matan Giladi von der Firma Apiiro haben ihre Untersuchung am 5. November 2026 veröffentlicht. Ihr Ergebnis: In 1.122 öffentlichen Kopien der Datei .claude/settings.local.json auf GitHub steckt mindestens ein Geheimnis, etwa ein Passwort, ein API-Schlüssel (eine Art digitaler Generalschlüssel, mit dem Programme auf Dienste zugreifen) oder ein Token. Getestet haben die Forscher die Zugangsdaten nicht. Ein Unternehmen, das sie vorab informiert hatten, bestätigte aber, dass sein Schlüssel noch gültig war.

Wie das Passwort in die Datei kommt

Wer einen Befehl dauerhaft freigibt, legt damit laut Anthropics eigener Dokumentation eine „Allow-Regel“ in .claude/settings.local.json im Projektordner an. Passende Befehle laufen in späteren Sitzungen dann ohne Rückfrage. Manchmal ist diese Regel ein Muster, etwa npm test *. Manchmal ist sie aber der exakte Befehl, und dann wird jedes Passwort, das im Befehl steht, im Klartext mitgespeichert. Ein Beispiel: Du lässt Claude die Datenbankverbindung prüfen, der Befehl enthält PGPASSWORD=geheim123, und schon liegt eine weitere Kopie deines Datenbank-Passworts in einer Textdatei.

Die Forscher konnten das Verhalten nach eigenen Angaben mit den aktuellen Modellen Opus 5.5 und Fable 5.1 nachstellen. iTWire betont: Hier verleitet kein bösartiger Prompt die KI zum Datenklau. Das Problem entsteht im ganz normalen, erlaubten Arbeitsablauf.

Warum der eingebaute Schutz nicht reicht

Claude Code versucht, die Datei aus Git herauszuhalten. Git ist das Versionsverwaltungssystem, mit dem Code auf Plattformen wie GitHub landet. Wenn Claude Code die Datei zum ersten Mal schreibt, trägt es sie laut Dokumentation in die globalen Git-Ausschlüsse des Nutzers ein, eine Liste von Dateien, die Git auf diesem Rechner grundsätzlich ignoriert.

Dieser Schutz hat Lücken:

• Er gilt nur für einen Nutzer auf einem Rechner. Ein Kollege mit anderem Setup oder ein neuer Laptop sind nicht geschützt.
• Claude Code trägt die Datei nicht in die .gitignore des Projekts ein, also in die Ausschlussliste, die mit dem Projekt mitwandert.
• Ist die Datei schon einmal eingecheckt worden, wirken Ausschlussregeln laut Git-Dokumentation gar nicht mehr.

iTWire merkt an, dass das „local“ im Dateinamen nur beschreibt, wie Claude Code die Datei nutzt. Vor dem Hochladen schützt der Name nicht. Auffällig ist ein weiterer Befund: In 539 von 1.105 nachverfolgten Repositorys (Code-Sammlungen eines Projekts) wurde die Datei durch einen Commit geändert, also eine gespeicherte Änderung, bei dem Claude als Co-Autor eingetragen war. Die Forscher schließen daraus, dass Claude die Datei oft selbst einbucht. iTWire relativiert: Daraus folgt nicht, dass Claude jedes einzelne Geheimnis hochgeladen hat.

Die Zahlen im Detail

Apiiro hat GitHub zwischen dem 1. und 3. November durchsucht. Als Geheimnis zählte ein Wert, wenn er einem bekannten Schlüsselformat entsprach oder wenn ein Passwort oder Token neben der Adresse eines öffentlich erreichbaren Servers stand. Zusätzlich musste ein KI-Prüfer zustimmen.

Mehr als ein Drittel der Geheimnisse öffnet direkt eine Datenbank. Unter den Besitzern sind 63 Organisationen, vor allem Softwarefirmen jeder Größe. Zu den schwersten Fällen gehören laut Apiiro ein Admin-Cloud-Schlüssel eines Datenbankanbieters und das Besitzer-Passwort einer Datenbank mit Patientenakten. Am Montag lagen noch alle betroffenen Dateien auf dem Hauptzweig ihres Repositorys. Bei der Hälfte lagen sie dort schon seit mindestens 217 Tagen.

Von 16 Coding-Agenten, deren Dokumentation die Forscher verglichen haben, ist Claude Code der einzige, bei dem bestätigt ist, dass er standardmäßig den vollständigen freigegebenen Befehl in einer Projektdatei speichert.

Scanner übersehen viele Lecks

Viele Firmen setzen auf Secret-Scanner, also Programme, die Code automatisch nach Passwörtern und Schlüsseln durchsuchen. Bei diesen Dateien funktioniert das schlecht. Gitleaks erkannte nur 564 der 1.122 betroffenen Dateien, TruffleHog 643, und 215 erkannte keines der beiden Werkzeuge. Die Scanner suchen nach bekannten Schlüsselformaten. Ein Passwort hinter PGPASSWORD=, sshpass -p oder mysql -p sieht für sie aus wie ein gewöhnliches Wort in einer Befehlszeile.

Das Risiko besteht auch ohne GitHub. Die Datei liegt als einfacher Text im Projektordner und kann in npm-Paketen, Docker-Images, Zip-Archiven oder synchronisierten Ordnern landen. Schadsoftware sucht gezielt nach so etwas: Der Wurm Shai-Hulud ließ im September 2025 TruffleHog über infizierte Entwicklerrechner laufen.

Was Entwickler jetzt tun sollten

Die Forscher empfehlen diese Schritte:

1. Zuerst die Zugangsdaten austauschen (rotieren), erst danach aufräumen. Die Datei zu löschen reicht nicht, denn alte Versionen bleiben im Git-Verlauf und in Forks erhalten.
2. Die eigene GitHub-Organisation nach .claude/settings.local.json und .claude/settings.json durchsuchen, auch im Verlauf.
3. Die Datei mit git rm --cached .claude/settings.local.json aus der Versionsverwaltung nehmen und in die .gitignore des Projekts eintragen.
4. Die lokale Datei öffnen und jede Regel löschen, die ein Geheimnis enthält, auch wenn sie nie hochgeladen wurde.
5. Geheimnisse nicht in Befehle schreiben, sondern als Variable aus einem Secrets-Manager einsetzen (etwa $DB_URL). iTWire warnt dabei: Wer das Passwort direkt in eine Variablenzuweisung im Befehl schreibt, hat es trotzdem im Befehlstext.
6. Muster wie Bash(npm run:*) freigeben statt einzelner Befehle.

Sicherheitsteams sollen Agent-Ordner wie .claude/, .cursor/, .gemini/ und .specstory/ behandeln wie .env-Dateien, also als Orte, an denen Geheimnisse liegen. Diese Ordner gehören in die automatischen Prüfungen vor jedem Commit und in der CI (der automatischen Build- und Testkette).

Einordnung

Neu ist das Problem nicht. Bereits am 11. August 2025 meldete ein Nutzer, dass freigegebene Befehle mit API-Schlüsseln wortwörtlich in der Datei landen. Ein Bot schloss die Meldung am 3. Januar nach 60 Tagen ohne Aktivität als „not planned“. Laut Apiiro erging es vier verwandten Meldungen genauso, die letzte wurde am Vortag geschlossen. Anthropic hat auf keine davon geantwortet. Laut iTWire beschrieb die Sicherheitsfirma ironPeak schon im Februar 2026 einen ähnlichen Fund und veröffentlichte ein Prüfwerkzeug.

Wichtig zur Einordnung: Apiiro verkauft selbst Sicherheitsprodukte für Anwendungen und KI-Agenten, und die Zahlen sind nicht unabhängig überprüft. Belegt ist ein Risiko, keine nachgewiesene Datenpanne. Ob die Schlüssel noch funktionieren oder ob Dritte sie benutzt haben, ist offen. Den Mechanismus bestätigen aber Anthropics eigene Dokumentation und frühere Berichte. Der Fall zeigt eine neue Art von Sicherheitslücke durch KI-Agenten: Nicht der ausgeführte Befehl ist gefährlich, sondern das, was der Agent danach als Erinnerung abspeichert. Wer mit Claude Code arbeitet, sollte deshalb jetzt in seine .claude-Ordner schauen.