Zugangsdaten im Klartext: Claude Code schiebt Passwörter in öffentliche Repositories

Laut der Sicherheitsfirma Apiiro enthalten 1.122 öffentliche GitHub-Kopien einer Einstellungsdatei des KI-Coding-Agenten Claude Code echte Zugangsdaten. Gespeichert wurden sie über die Komfortoption „Ja, nicht mehr fragen“. Ob diese Passwörter und Schlüssel noch funktionieren, hat Apiiro nicht getestet. Ein vorab informiertes Unternehmen bestätigte allerdings, dass sein Schlüssel aktiv war. Das berichtet The Hacker News am 7. November 2026. Bezogen auf 104.185 gefundene Kopien der Datei sind das rund 1,1 Prozent.

„Ja, nicht mehr fragen“ speichert Zugangsdaten im Klartext

Die Option „Ja, nicht mehr fragen“ schreibt in Claude Code eine Freigaberegel in die Datei .claude/settings.local.json im Projektordner. Laut Anthropics Dokumentation gilt eine solche Freigabe für Shell-Befehle dauerhaft. Sie gilt pro Repository und pro Befehl. Ein Repository ist die versionierte Ablage eines Softwareprojekts. Spätere Sitzungen führen passende Befehle ohne Rückfrage aus.

Ein Klick genügt. Das Problem liegt im Wortlaut der Regel. Sie deckt laut The Hacker News nur ab, was die Abfrage angeboten hat. Manchmal ist das ein Muster wie npm test *. Manchmal ist es ein exakter Einzelbefehl. Enthält dieser Befehl ein Passwort, wird es mitgespeichert. Die Datei hält es im Klartext fest. Wer Zugangsdaten direkt in einen Befehl tippt, hinterlegt sie also dauerhaft im Projekt.

Apiiro reproduzierte das Verhalten laut The Hacker News mit den aktuellen Modellen Opus 5.5 und Fable 5.1. Die Forschenden verglichen zudem die Dokumentation von 16 Coding-Agenten. Nur Claude Code speichert demnach nachweislich standardmäßig den vollständigen freigegebenen Befehl in einer Projektdatei.

Gerade solche Abkürzungen machen Claude Code für Poweruser attraktiv. Sie kosten aber Kontrolle. Klicken Sie die Option nie bei Befehlen mit Zugangsdaten.

Datenbankpasswörter führen die Fundliste an

Mehr als ein Drittel der von Apiiro entdeckten Geheimnisse öffnet laut The Hacker News direkt eine Datenbank. Die Forschenden fanden auf GitHub 104.185 Kopien der Datei in 103.617 Repositories. Die 1.122 belasteten Kopien enthalten zusammen 1.379 verschiedene Geheimnisse.

Die folgende Tabelle zeigt, welche Arten von Zugangsdaten Apiiro fand und wo weitere Geheimnisse lagen.

Als Geheimnis zählte ein Wert, wenn er einem bekannten Schlüsselformat entsprach. Ebenso zählten Passwörter und Tokens neben der Adresse eines öffentlichen Servers. Zusätzlich musste ein KI-Prüfer zustimmen. Rechnet Apiiro Altversionen, die geteilte settings.json und gespeicherte Agenten-Chatprotokolle ein, sind es 2.539 Geheimnisse in 1.994 Repositories.

Unter den Besitzenden der Dateien sind laut Apiiro 63 Organisationen, meist Softwarefirmen jeder Größe. Zu den schwersten Fällen zählt der administrative Cloud-Schlüssel eines Datenbankanbieters. Dazu kommt das Eigentümer-Passwort einer Datenbank mit Patientenakten. Ob jemand diese Zugangsdaten bereits missbraucht hat, sagen die Forschenden nicht.

Liegen geblieben sind sie lange. Am 2. November 2026 lag laut The Hacker News jede belastete Datei noch auf dem Standard-Branch ihres Repositories. In der Hälfte dieser Repositories lag sie dort seit mindestens 217 Tagen. Wer nach dem Source-Code-Leak von Claude Code die Enterprise-Risiken neu bewertet hat, muss die Liste jetzt verlängern.

Der Git-Schutz von Claude Code endet am eigenen Rechner

Claude Code hält die Datei .claude/settings.local.json über eine rechnerweite Ausschlussliste aus Git heraus, nicht über die .gitignore des Projekts. Laut Anthropics Einstellungsdokumentation trägt Claude Code beim ersten Schreiben in einem Git-Repository den Eintrag **/.claude/settings.local.json in die globalen Git-Excludes ein. Diese Liste gilt für alle Projekte, aber nur auf diesem einen Computer.

Dieses Bild wurde mit KI generiertProviderhiggsfieldModellgpt_image_2_5 flare high 1k 16:9Promptflat vector illustration, side-by-side view of a single laptop on the left with a shield icon labeled "Git-Excludes" protecting a file card named "settings.local.json", and on the right a separate second laptop and a cloud repository icon where the same file card has no shield and shows a small open padlock and a key symbol. A dashed arrow from the left laptop to the right stops with a break mark, suggesting the protection does not travel. Clean geometric shapes, flat colors in dark blue, mint green and signal orange on a light gray background, bird's eye perspective, no people, no hands. No watermark, no signature.

Mythos: Claude Code hält die Datei zuverlässig aus öffentlichen Repositories heraus.

Falsch.

Laut heise online greift der Schutz nicht, wenn ein Ordner erst später zum Git-Repository wird. Er versagt ebenso bei Projekten, die von einem anderen Rechner geklont wurden. Gleiches gilt, wenn jemand die Datei bereits committet hat, also in einen gespeicherten Versionsstand aufgenommen. Dann fehlt die Regel in der .gitignore, und die Zugangsdaten in der Datei sind ungeschützt. Wer die Datei von Hand anlegt, muss sie laut Dokumentation selbst eintragen.

Die harte Wahrheit steht in der Commit-Historie. In 539 von 1.105 nachverfolgten Repositories veränderte laut Apiiro ein Commit mit Claude als Mitautor die Datei. Die Forschenden schließen daraus, dass der Agent die Datei häufig selbst einspielt. Vielen Betroffenen scheint das laut heise online nicht klar zu sein.

Löschen allein funktioniert nicht. Alte Versionen bleiben laut The Hacker News in der Git-History erhalten, der vollständigen Versionsgeschichte eines Projekts. Sie stecken auch in Forks, also Kopien des Repositories unter anderen Konten. Einmal öffentliche Zugangsdaten sind verbrannt.

Neu ist das Verhalten nicht. Ein Fehlerbericht vom 11. August 2025 beschrieb laut The Hacker News bereits, dass freigegebene Befehle mit API-Keys und Tokens wörtlich in der Datei landen. Ein Bot schloss den Bericht am 3. Januar 2026 nach 60 Tagen ohne Aktivität als „not planned“. Derselbe Bot schloss vier verwandte Berichte, den jüngsten am 6. November 2026. Eine Antwort von Anthropic erhielt laut den Forschenden keiner davon.

Gängige Secret-Scanner übersehen Passwörter in Befehlszeilen

Die Secret-Scanner gitleaks und TruffleHog, Werkzeuge zum Aufspüren von Schlüsseln im Code, erkennen viele der belasteten Dateien nicht. Apiiro ließ beide ohne ihren Verifikationsschritt über alle Kopien laufen. Von 1.122 Dateien mit Geheimnis markierte gitleaks 564. TruffleHog kam auf 643. Keines der beiden Werkzeuge erkannte 215 Dateien.

Die meisten Lücken betreffen laut The Hacker News Passwörter, die in Befehlen stehen. Scanner suchen nach bekannten Schlüsselformaten. Ein Passwort hinter PGPASSWORD=, sshpass -p bzw. mysql -p wirkt für sie wie ein gewöhnliches Wort. Genau dort stehen viele Zugangsdaten.

GitHub rüstet laut heise online immer wieder Schutzfunktionen gegen veröffentlichte Geheimnisse nach. Im Frühjahr 2025 erweiterte GitHub sein Paket Advanced Security um ein Scan-Werkzeug gegen abfließende Zugangsdaten. Verlassen Sie sich trotzdem nicht auf Formaterkennung.

Auch Kopien abseits von GitHub zählen. Die Datei ist laut Apiiro schlichtes JSON im Projektordner. Sie kann in npm-Pakete, Docker-Images, Zip-Archive und synchronisierte Ordner geraten. Schadsoftware hat Entwicklerrechner schon früher nach Zugangsdaten durchsucht. Der Wurm Shai-Hulud ließ im September 2025 TruffleHog über infizierte Computer laufen. Wie schnell Agenten selbst an fremde Daten kommen, zeigte der Sandbox-Ausbruch bei WorkOS.

Erst Zugangsdaten tauschen, dann aufräumen

Apiiro rät, betroffene Zugangsdaten zuerst zu rotieren, also durch neue zu ersetzen, und erst danach die Dateien zu bereinigen. Wer zuerst löscht, wiegt sich in falscher Sicherheit. Machen Sie das nicht.

Für Entwicklungsteams nennen die Forschenden laut The Hacker News diese Schritte:

1. Durchsuchen Sie Ihre GitHub-Organisation nach .claude/settings.local.json und .claude/settings.json, auch in der Git-History bereits gelöschter Dateien.
2. Tauschen Sie jedes Passwort, jedes Token und jeden Schlüssel aus, den diese Dateien je enthalten haben.
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 auch auf Ihrem eigenen Rechner, selbst wenn sie nie committet wurde, und löschen Sie jede Regel mit einem Geheimnis.
5. Rufen Sie Geheimnisse als Variablen aus einem Secrets-Manager auf, einem Tresor für Schlüssel, etwa als $DB_URL, damit die Regel nur den Variablennamen speichert.
6. Geben Sie Muster wie Bash(npm run:*) frei statt einzelner Befehle.

Sicherheitsteams sollen laut Apiiro Agentenordner wie .claude/, .cursor/, .gemini/ und .specstory/ wie .env-Dateien behandeln. Das gilt samt Memory-Dateien der Agenten, auf Laptops ebenso wie in Repositories. Diese Ordner gehören in Pre-Commit- und CI-Scans, inklusive Git-History. CI steht für die automatische Prüfung bei jedem Code-Eingang. Der Scanner muss Passwörter in Befehlen finden. Prüfen Sie Zugangsdaten mit öffentlicher Serveradresse zuerst. Genau diese öffnen laut den Forschenden den Zugang.

Tipp: Nehmen Sie .claude/settings.local.json in die .gitignore-Vorlagen Ihrer Organisation auf, damit der Schutz mit jedem neuen Projekt mitwandert.

Anthropic reagiert inzwischen. Laut heise online beteiligte sich Boris Cherny, Leiter von Claude Code bei Anthropic, am 7. November 2026 an einer Diskussion auf Hacker News. Er kündigte an, das Team prüfe, wie sich solche Lecks verhindern lassen. Als Prototyp nannte er den Auto-Modus, in dem ein Klassifikator Aktionen anstelle der Nutzenden prüft. Er soll solche Fälle künftig abfangen. Dazu könnte Claude Code ein einfaches Scanning auf Geheimnisse erhalten. Ein Auslieferungsdatum nennt keiner der Berichte. Bis dahin schützt nur die eigene Prüfung Ihre Zugangsdaten. Durchsuchen Sie Ihre Repositories noch diese Woche.