Cybersicherheit

Claude Code speicherte Passwörter im Klartext, 1.122 Dateien liegen auf GitHub

Susan Hill
Fügen Sie uns bei Google hinzu

Anthropics Claude Code fragt vor den meisten Shell-Befehlen um Erlaubnis. Eine der angebotenen Antworten lautet: „Ja, und frag nicht noch einmal.“ Wählt man diese Option für einen Befehl, der ein Passwort enthält – etwa für die Anmeldung an einer Datenbank –, kann Claude Code den gesamten Befehl mitsamt Passwort in eine unverschlüsselte Einstellungsdatei im Projekt schreiben. Sicherheitsforscher haben nun Tausende solcher Passwörter und Schlüssel in öffentlichen Code-Repositories auf GitHub gefunden, wo sie für alle einsehbar sind.

Wer Claude Code nutzt, sollte nach einer Datei namens settings.local.json suchen. Sie liegt in einem versteckten Ordner namens .claude im Stammverzeichnis des Repositorys und wird zusammen mit dem Projekt weitergegeben, sofern man das nicht verhindert. Das Verhalten ist in allen Ländern gleich, in denen das Tool verfügbar ist. Die eigenen Gewohnheiten zu ändern dauert eine Minute; ein durchgesickertes Passwort aufzuräumen dagegen erheblich länger, denn wer die Datei löscht, entfernt sie damit weder aus der Git-Historie noch aus den Forks anderer Nutzer.

Das auf Softwaresicherheit spezialisierte Unternehmen Apiiro durchsuchte öffentliche GitHub-Repositories und fand nach Angaben seiner Untersuchung, über die The Hacker News berichtete, 104.185 Kopien der Datei in 103.617 Repositories. Etwa 1,1 Prozent davon – 1.122 Kopien – enthalten mindestens ein Geheimnis, insgesamt 1.379 verschiedene Zugangsdaten. Mehr als ein Drittel davon würde direkten Zugriff auf eine Datenbank ermöglichen; darunter sind 379 Datenbankpasswörter. Außerdem fanden sich 43 SSH-Zugänge zu öffentlichen Servern, 42 Tokens für GitHub, GitLab und npm sowie 23 Schlüssel für Amazon Web Services.

Bei den Betroffenen handelt es sich nicht nur um Hobbyentwickler. Apiiro konnte die Dateien 63 Organisationen zuordnen, überwiegend Softwareunternehmen unterschiedlicher Größe. Zu den gravierendsten Fällen zählen der Cloud-Schlüssel eines Datenbankanbieters mit Administratorrechten und das Besitzerpasswort einer Datenbank mit Krankenakten. Ältere Versionen der Datei in der Git-Historie enthalten weitere 734 Geheimnisse in 509 Repositories; 211 Forks von 74 Repositories führen dieselben Geheimnisse wie die Originale mit. Rechnet man gemeinsam genutzte Einstellungsdateien hinzu, die Teams absichtlich einchecken, sowie gespeicherte Chatprotokolle von Agenten, steigt die Zahl auf 2.539 Geheimnisse in 1.994 Repositories.

Claude Code versucht durchaus, die Datei aus der Versionsverwaltung herauszuhalten. In der Einstellungsdokumentation von Anthropic heißt es, dass das Tool beim ersten Schreiben der Datei eine Regel zu den globalen Git-Ausschlüssen des Nutzers hinzufügt, sodass Git sie auf diesem Computer ignoriert. Diese Regel wird jedoch nicht mit dem Projekt auf den Laptop eines Teammitglieds, einen Build-Server oder einen neuen Rechner übertragen. Für eine Datei, die bereits eingecheckt wurde, bringt sie ebenfalls nichts. In 539 der 1.105 von den Forschern zurückverfolgten Repositories änderte ein Commit, in dem Claude als Mitautor aufgeführt war, die Datei – ein Hinweis darauf, dass der Agent sie oft selbst eincheckt. Von den 16 Coding-Agenten, deren Dokumentation Apiiro verglich, ist Claude Code der einzige, bei dem bestätigt wurde, dass er standardmäßig den vollständigen freigegebenen Befehl in einer Projektdatei speichert.

Die üblichen Schutzmechanismen übersehen einen großen Teil der Fälle. Apiiro ließ zwei verbreitete Open-Source-Scanner für Geheimnisse, gitleaks und TruffleHog, über sämtliche Kopien laufen: gitleaks schlug bei 564 der 1.122 Dateien Alarm, TruffleHog bei 643; 215 blieben von beiden unentdeckt. Bei den meisten übersehenen Fällen handelte es sich um Passwörter, die nach PGPASSWORD=, sshpass -p oder mysql -p eingegeben worden waren. Für ein Tool, das nach bekannten Schlüsselformaten sucht, sehen solche Angaben wie gewöhnliche Wörter aus.

Die Ergebnisse sind mit Vorbehalten zu betrachten. Apiiro verkauft Sicherheitstools für KI-gestützte Entwicklung, weshalb die Untersuchung zugleich als Verkaufsargument dient. Das Unternehmen prüfte nicht, ob die Zugangsdaten noch funktionieren; allerdings bestätigte eines der benachrichtigten Unternehmen, dass sein Schlüssel noch gültig gewesen war. Ein Wert wurde als Geheimnis gezählt, wenn er einem bekannten Schlüsselformat entsprach oder neben einer öffentlichen Serveradresse stand und von einem KI-Prüfer als Geheimnis eingestuft wurde. Dadurch bleibt ein gewisser Spielraum für falsch positive Treffer. Apiiro weist außerdem darauf hin, dass die Zahl der Mitautorenschaft nicht belegt, dass Claude alle offengelegten Zugangsdaten selbst eingeführt hat. Und GitHub ist nur der sichtbare Teil: Da es sich um eine einfache JSON-Datei im Projektordner handelt, kann sie ebenso in einem npm-Paket, einem Docker-Image, einem ZIP-Archiv oder einem synchronisierten Ordner landen.

Der erste Rat der Forscher lautet, alle Zugangsdaten zu erneuern: Ändern Sie jedes Passwort, jeden Token und jeden Schlüssel, der jemals in der Datei stand, bevor Sie mit dem Aufräumen beginnen. Denn ein Geheimnis, das öffentlich war, gilt als kompromittiert – unabhängig davon, ob man die Historie umschreibt. Beenden Sie anschließend die Erfassung der Datei mit git rm –cached, nehmen Sie sie in die .gitignore-Datei des Repositorys auf und öffnen Sie in Claude Code /permissions, um jede gespeicherte Regel zu löschen, die ein Geheimnis enthält. Werden Zugangsdaten über Umgebungsvariablen eingebunden, speichert eine Regel lediglich einen Namen wie $DB_URL statt des Passworts. Wer Muster statt einzelner Befehle freigibt, hält außerdem konkrete Argumente vollständig aus der Datei heraus.

Nutzer hatten das Problem schon früher gemeldet. In einem am 11. August 2025 eingereichten Fehlerbericht hieß es, freigegebene Befehle mit API-Schlüsseln und Tokens würden wortgetreu in settings.local.json gespeichert. Ein automatisierter Bot schloss den Bericht am 3. Januar nach 60 Tagen ohne Aktivität mit dem Vermerk „nicht geplant“. Apiiro, das seine Untersuchung am 6. November veröffentlichte, zufolge wurden alle vier von ihm angeführten verwandten Berichte von demselben Bot geschlossen – der jüngste am 6. November –, ohne dass Anthropic darauf antwortete. Am 2. November befand sich jede von Apiiro gefundene offengelegte Datei noch im Hauptbranch ihres Repositorys; in der Hälfte der Fälle war das seit mindestens 217 Tagen so.

Weder The Hacker News noch Apiiro berichten von einer Stellungnahme Anthropics, und das dokumentierte Verhalten hat sich nicht geändert: Wer beim nächsten Befehl mit eingegebenem Passwort „Nicht noch einmal fragen“ auswählt, speichert damit auch dieses Passwort.

Schlagwörter: , , , , ,

Fügen Sie uns bei Google hinzu

Diskussion

Es gibt 0 Kommentare.