Apiiro berichtete am 5. November 2026, dass Zugangsdaten in öffentlich zugänglichen GitHub-Kopien von Claude Codes Projektdatei .claude/settings.local.json gefunden wurden. Wer bei einer Shell-Zeile „Yes, and don’t ask again“ auswählt, kann damit laut Apiiro den vollständigen Befehl als Freigaberegel speichern. Steht darin ein Passwort oder Token, kann auch dieses im Klartext in der Datei landen.

Wie eine Freigabe ein Geheimnis speichern kann

Englischsprachiger Kommentar von SavvyNik zu Apiiros Befunden, Git-Verlauf und möglichen Gegenmaßnahmen

Die Freigabeoption soll einen Befehl für spätere Ausführungen erlauben. Apiiros berichteter Befund betrifft den Fall, dass der gespeicherte Befehl selbst Zugangsdaten enthält: Sie können dann Teil der lokalen Projekteinstellungen werden. Werden diese Einstellungen in ein öffentliches Repository übernommen, können die Zugangsdaten dort sichtbar sein.

Was Apiiros GitHub-Zahlen erfassen

Apiiros Untersuchung bezog sich auf öffentliche GitHub-Daten, die zwischen dem 1. und 3. November 2026 gesammelt wurden. In 1.122 von 104.185 untersuchten Kopien der Einstellungsdatei fanden sich laut dem Unternehmen Zugangsdaten. Das sind etwa 1,1 Prozent dieser Kopien. Sie enthielten zusammen 1.379 einzelne Zugangsdaten.

Ein weiter gefasster Zähler kam auf 2.539 Geheimnisse in 1.994 Repositories und 63 Organisationen. Er umfasste zusätzlich andere Dateien und den Git-Verlauf. Die 1.122 beziehen sich also auf Kopien einer bestimmten Einstellungsdatei, die 2.539 auf einzelne Geheimnisse aus einem größeren Bestand.

Apiiro zufolge bestätigte ein Unternehmen, dass ein offengelegter Schlüssel aktiv war. Die berichteten Zahlen stammen aus einer Stichprobe öffentlicher GitHub-Kopien.

Warum das Löschen der Datei nicht genügt

Die Berichte beschreiben für Claude Code einen globalen Git-Ausschluss, der die lokale Einstellungsdatei betrifft. Er fügt jedoch keine Regel zur .gitignore des jeweiligen Repositories hinzu und gilt nicht für Dateien, die Git bereits verfolgt. Eine solche lokale Ausnahme schützt daher nicht automatisch jede Projektkopie.

Wurde die Datei bereits eingecheckt, kann ihre frühere Version im Git-Verlauf bleiben. Auch Kopien in Forks oder Klonen verschwinden nicht dadurch, dass die aktuelle Datei gelöscht wird. Und das Löschen einer Datei sperrt ein darin enthaltenes Zugangsmittel nicht.

Bei möglicher Offenlegung zuerst den betroffenen Zugang sperren oder erneuern. Danach Datei und Repository-Verlauf bereinigen.

Warum Secret-Scanner Lücken lassen können

Apiiro berichtete, dass 215 der 1.122 Dateien mit Zugangsdaten weder Gitleaks noch TruffleHog markierten. In den Berichten wird als Grund genannt, dass Passwörter in Shell-Befehlen oder Anfrage-Headern nicht unbedingt den üblichen Mustern für bekannte Anbieterschlüssel entsprechen.

Was bei einer möglichen Offenlegung zuerst zu tun ist

Wenn ein Befehl mit Zugangsdaten in ein Repository gelangt sein könnte, empfehlen die Berichte diese Reihenfolge:

  1. Betroffene Zugangsdaten sperren oder erneuern.
  2. Aktuelle Dateien und den Git-Verlauf nach der Einstellungsdatei und den Zugangsdaten durchsuchen.
  3. Die Datei aus der Versionsverwaltung nehmen und eine passende Regel in der .gitignore des Repositories ergänzen.
  4. Die lokale Einstellungsdatei auf weitere Zugangsdaten prüfen und Geheimnisse nicht wörtlich in freigegebene Befehle schreiben.

Bei einer Datei, die bereits veröffentlicht wurde, ersetzt das Aufräumen im Repository nicht das Sperren oder Erneuern der darin enthaltenen Zugangsdaten.