Am 7. November 2026 berichtete The Hacker News über Apiiros Fund: 1.122 öffentliche Kopien einer Claude-Code-Einstellungsdatei auf GitHub enthielten mindestens ein Geheimnis. Apiiro hatte 104.185 Kopien in 103.617 Repositories durchsucht. Ob die meisten gefundenen Zugangsdaten noch gültig waren, prüfte das Unternehmen nicht; eine kontaktierte Firma bestätigte laut Bericht, dass ihr Schlüssel zu diesem Zeitpunkt aktiv war.
Eine lokale Git-Ausschlussregel schützt nicht vor bereits veröffentlichten Commits. Bei einem Fund gilt: zuerst Zugangsdaten rotieren, dann aufräumen.
Wie ein freigegebener Befehl ein Geheimnis speichern kann
Wählt ein Nutzer bei einem einzelnen Shell-Befehl „Yes, and don’t ask again“, kann Claude Code diesen exakten Befehl als dauerhaft erlaubte Regel in .claude/settings.local.json speichern. Steht ein Passwort oder Token wörtlich im Befehl, kann es so ebenfalls in der Datei landen. Eine Regel kann stattdessen auch ein Muster enthalten; darin muss kein Geheimnis stehen.
Laut dem Bericht trägt Claude Code die Datei beim ersten Anlegen in einem Git-Repository in die globale Ausschlussliste des jeweiligen Nutzers ein. Diese Einstellung gilt nur für dessen Git-Konfiguration und wird nicht mit dem Repository geteilt. Bereits eingecheckte Dateien werden dadurch nicht entfernt; auch eine Regel in der Projektdatei .gitignore ersetzt dieser lokale Ausschluss nicht.
Was die gemeldeten Zahlen umfassen
Apiiro zählte 1.379 Geheimnisse in den 1.122 aktuellen öffentlichen Kopien von .claude/settings.local.json. Die größere Zahl von 2.539 Geheimnissen in 1.994 Repositories umfasst zusätzlich ältere Dateiversionen, gemeinsam genutzte .claude/settings.json-Dateien und gespeicherte Agenten-Chats.
| Umfang | Enthaltene Dateien und Inhalte | Gemeldete Geheimnisse |
Aktuelle öffentliche Kopien von .claude/settings.local.json | 1.122 von 104.185 durchsuchten Kopien enthielten mindestens ein Geheimnis | 1.379 |
| Erweiterte Erhebung | Zusätzlich ältere Versionen, gemeinsam genutzte .claude/settings.json-Dateien und gespeicherte Agenten-Chats | 2.539 |
Zu den gemeldeten Funden gehörten 379 Datenbankpasswörter, 43 SSH-Zugänge zu öffentlichen Servern, 42 Tokens für GitHub, GitLab und npm zusammen sowie 23 AWS-Schlüssel. Mehr als ein Drittel der Geheimnisse ermöglichte laut Bericht den direkten Zugriff auf eine Datenbank. Apiiro fand außerdem 734 Geheimnisse in älteren Dateiversionen aus 509 Repositories. In 211 Forks von 74 Repositories tauchten dieselben Geheimnisse auf; unter 76.011 gemeinsam genutzten .claude/settings.json-Dateien enthielten 298 Geheimnisse.
Warum Löschen nicht alle Kopien beseitigt
Eine Datei kann aus dem aktuellen Projekt verschwinden und trotzdem in der Git-Historie oder in Forks erhalten bleiben. Apiiro ließ die 1.122 Dateien mit Geheimnissen auch von gitleaks und TruffleHog prüfen. Die Scans liefen ohne den jeweiligen Verifizierungsschritt der Werkzeuge.
| Scanergebnis | Markierte Dateien von 1.122 | Bedingung |
| gitleaks | 564 | Scan ohne Verifizierungsschritt |
| TruffleHog | 643 | Scan ohne Verifizierungsschritt |
| Von keinem der beiden Werkzeuge markiert | 215 | Beide Scans ohne Verifizierungsschritt |
Die einzelnen Scannerwerte sind keine voneinander getrennten Gruppen: Eine Datei kann von beiden Werkzeugen markiert worden sein. Die Zahlen zeigen, dass ein einzelner Scan nicht alle Dateien aus der untersuchten Gruppe erkannte.
Was Betroffene laut Apiiro tun sollten
Apiiros empfohlene Reihenfolge setzt bei den Zugangsdaten an, nicht beim Löschen der Datei:
- Aktuelle Dateien und die Git-Historie nach betroffenen Werten durchsuchen.
- Gefundene Zugangsdaten vor der Bereinigung rotieren.
- Die lokale Datei aus der Versionsverwaltung nehmen und eine passende Regel in der projektweiten
.gitignoreergänzen. Regeln mit Geheimnissen aus den lokalen Einstellungen entfernen. - Geheimnisse nicht als wörtliche Werte in Befehle schreiben, sondern auf Variablen eines Secret-Managers verweisen.
- Bei dauerhaften Freigaben Befehlsmuster statt exakter Befehle verwenden.
Dateizugriff braucht eine eigene Regel
Eine Claude-Code-Communitydiskussion zitiert Hinweise, sensible Pfade mit Read-Deny-Regeln zu sperren; .claudeignore soll den Zugriff über Dateiwerkzeuge demnach nicht steuern. Solche Regeln betreffen das Lesen von Dateien. Sie entfernen keine Zugangsdaten, die bereits in einem freigegebenen Befehl oder in der Git-Historie gespeichert sind.