Claude Code: wachtwoorden in 1.122 GitHub-bestanden

👁 113 keer gelezen

Op 11 augustus 2025 meldde een Claude Code-gebruiker op GitHub een bug met nummer 5544. Commando’s die in de agent waren goedgekeurd, werden letterlijk opgeslagen in het bestand settings.local.json, inclusief API-sleutels en tokens. Anthropic reageerde niet. Op 3 januari 2026 sloot een automatisch systeem de melding na 60 dagen stilte met de opmerking „not planned”. Tien maanden later telden onderzoekers van Apiiro de gevolgen: op openbare GitHub-repositories staan 1.122 kopieën van dit bestand met minstens één echt geheim erin.

Ik gebruik Claude Code dagelijks in een map met meer dan vijfhonderd projectsubmappen. Voordat ik aan dit artikel begon, heb ik die map gescand. Hieronder vind je de uitkomst en de commando’s waarmee je zelf in twee minuten hetzelfde kunt doen.

Met één klik sla je een wachtwoord op

Claude Code vraagt voordat het de meeste terminalcommando’s uitvoert om toestemming. Naast de gewone opties „ja” en „nee” is er een derde: „Yes, and don’t ask again”. Die voegt een regel toe aan het bestand .claude/settings.local.json in de projectmap. Vanaf dat moment worden overeenkomende commando’s zonder nieuwe vraag uitgevoerd. Zo werkt het volgens de documentatie over de instellingen van Claude Code.

Het probleem is dat de regel soms het volledige commando bevat in plaats van een patroon. Vraag je de agent bijvoorbeeld waarom je niet kunt inloggen op een database op een testserver, dan kan die een commando samenstellen met een wachtwoord uit je configuratie. Zonder dat wachtwoord kan hij immers niets controleren. De toestemmingsvragen verschijnen meerdere keren per sessie. Na de tiende vraag leest bijna niemand nog de hele lange regel. Eén klik - en het wachtwoord staat als platte tekst in een JSON-bestand. Apiiro reproduceerde dit met de nieuwste modellen, Opus 5.5 en Fable 5.1. Het probleem ligt dus bij het gereedschap zelf, niet bij een specifiek model.

Claude Code probeert het bestand buiten de repository te houden. Wanneer het de eerste keer in een git-repository wordt opgeslagen, voegt Claude Code het toe aan de globale lijst met genegeerde bestanden op je computer. Die bescherming reist echter niet mee met het project: het bestand komt niet in de .gitignore van de repository terecht, geldt niet voor een map die pas later een repository wordt en helpt niet als het bestand al eens in een commit is beland. Bovendien commit de agent het vaak zelf. In 539 van de 1.105 repositories met geheimen die Apiiro onderzocht, was het bestand gewijzigd in een commit die als mede door Claude gemaakt was ondertekend. De commitinstructies zeggen dat het model .env en credentials.json moet overslaan, maar zwijgen over het eigen bestand met toestemmingen.

1.122 bestanden, 1.379 geheimen

Shmulik Cohen en Matan Giladi van Apiiro doorzochten openbare GitHub-repositories tussen 1 en 3 november 2026. Ze vonden 104.185 kopieën van het bestand in 103.617 repositories. In 1.122 daarvan zat een geheim, oftewel 1,1 procent. In totaal ging het om 1.379 verschillende geheimen: 636 sleutels in de herkenbare indeling van bekende aanbieders en 743 wachtwoorden of tokens naast het adres van een openbare server.

Meer dan een derde geeft rechtstreeks toegang tot een database: het ging om 379 databasewachtwoorden en 122 Supabase-servicekeys. Daarnaast vonden de onderzoekers 43 SSH-logins voor openbare servers, sommige met het rootwachtwoord, 42 tokens voor GitHub, GitLab en npm en 23 AWS-sleutels. De bestanden zijn vooral van individuele ontwikkelaars, maar er zijn ook 63 organisaties bij, van studentenverenigingen tot softwarebedrijven. De ernstigste gevallen waren een cloudkey van een databaseleverancier met beheerdersrechten en het wachtwoord van de eigenaar van een database in een app met medische documentatie. Een van de gewaarschuwde bedrijven bevestigde dat zijn sleutel werkte. De overige geheimen zijn niet getest. „Geheim” betekent hier dus gegevens die er echt uitzien, niet gegevens waarvan zeker is dat ze toegang geven.

Twee cijfers springen eruit. In de helft van de repositories met geheimen stond het bestand minstens 217 dagen; in 118 repositories lag het er langer dan een jaar. Alleen het bestand verwijderen helpt ook weinig: oudere versies in de git-geschiedenis bevatten nog eens 734 geheimen in 509 repositories. Daarnaast kopieerden 211 forks dezelfde gegevens uit 74 projecten. Als Apiiro ook de geschiedenis, het gedeelde bestand settings.json en opgeslagen gesprekken met agents meetelt, komt het uit op 2.539 geheimen in 1.994 repositories.

Populaire scanners voor geheimen missen een flink deel. Van de 1.122 bestanden markeerde gitleaks er 564 en TruffleHog 643; 215 bestanden werden door geen van beide tools gevonden. Scanners zoeken naar sleutels met een herkenbare indeling. Een wachtwoord achter PGPASSWORD= of sshpass -p ziet er juist uit als een gewoon woord in een gewoon commando.

Wat ik zelf vond

Mijn werkmap heeft 504 submappen en 34 git-repositories. Ik vond precies één bestand met de naam settings.local.json, in de hoofdmap, met 14 toestemmingsregels. Het script waarmee ik zocht naar wachtwoorden, tokens, sleutels en adressen met een wachtwoord erin vond niets. De hoofdmap is geen repository, dus het bestand kon sowieso niet op GitHub belanden. Er zijn negen gedeelde bestanden met de naam settings.json; zes daarvan worden door git gevolgd in demoprojecten. Ook die zijn schoon.

Dat komt waarschijnlijk eerder door mijn gewoonte dan door voorzorg: ik start Claude Code vanuit één bovenliggende map, waardoor alle toestemmingen in één bestand buiten git terechtkomen. Elders was het interessanter. Apiiro onderzocht ook de geheugenbestanden van agents en vond geheimen in negen repositories. Claude Code heeft bij mij meer dan duizend van zulke notities. Mijn eenvoudige scanner wees in twee ervan een tekenreeks aan die op een sleutel lijkt. Die twee ga ik nu handmatig controleren. Ze staan buiten repositories, maar zijn nog steeds gewone tekstbestanden op schijf.

Controle in twee minuten

Gebruik op Linux, macOS of in Git Bash op Windows eerst dit commando om alle instellingenbestanden van Claude Code in je thuismap te vinden:

find ~ -path '*/.claude/settings*.json' -not -path '*/node_modules/*' 2>/dev/null

Zoek daarna naar bestanden met iets dat op een geheim lijkt. Het commando toont alleen bestandsnamen, niet de waarden. Je kunt het dus uitvoeren terwijl iemand meekijkt of wanneer je je scherm opneemt:

find ~ -path '*/.claude/settings*.json' -not -path '*/node_modules/*' -print0 2>/dev/null |
 xargs -0 grep -lE 'PGPASSWORD=|MYSQL_PWD=|sshpass -p|mysql .*-p[^ ]|Bearer [A-Za-z0-9._-]{20,}|sk-[A-Za-z0-9_-]{20,}|gh[pousr]_[A-Za-z0-9]{30,}|AKIA[0-9A-Z]{16}|://[^:/" ]+:[^@/" ]+@'

In PowerShell op Windows ziet hetzelfde er zo uit:

Get-ChildItem $HOME -Recurse -Force -Filter 'settings*.json' -ErrorAction SilentlyContinue |
 Where-Object { $_.DirectoryName -like '*\.claude' } |
 Select-String -Pattern 'PGPASSWORD=|MYSQL_PWD=|sshpass -p|Bearer [A-Za-z0-9._-]{20,}|sk-[A-Za-z0-9_-]{20,}|gh[pousr]_[A-Za-z0-9]{30,}|AKIA[0-9A-Z]{16}|://[^:/" ]+:[^@/" ]+@' -List |
 Select-Object -ExpandProperty Path

Een lege uitkomst is geen garantie: geen enkel patroon vangt ieder wachtwoord. Controleer lange bestanden daarom ook zelf. Kijk vervolgens in elke repository waarin je met een agent werkt of git het bestand nu volgt, en of dat ooit heeft gedaan:

git ls-files .claude/
git log --all --oneline -- .claude/settings.local.json

Een leeg antwoord op beide commando’s is goed nieuws. Heb je projecten op GitHub, zoek dan in de code met path:.claude/settings.local.json user:je-gebruikersnaam of org:je-bedrijf. Elk resultaat is een bestand dat iedereen op dat moment kan lezen.

Is een sleutel gelekt? Eerst vervangen, dan opruimen

De volgorde is belangrijk. Trek eerst in het dashboard van de aanbieder - van je database, cloudomgeving of GitHub - elk wachtwoord, token en elke sleutel die ooit in het bestand heeft gestaan in. Maak daarna nieuwe aan. Het bestand uit de repository verwijderen maakt het lek niet ongedaan: de oude versie blijft bestaan in de geschiedenis, in forks en in klonen bij iedereen die ze al heeft opgehaald. Controleer ook de toegangslogboeken van de aanbieder om te zien of iemand anders de sleutel heeft gebruikt.

Ruim pas daarna de repository op:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git commit -m "Volg lokale Claude Code-instellingen niet"

Het bestand blijft op schijf staan, maar git volgt het niet langer. De regel in .gitignore reist met het project mee naar iedereen die het kloont. Open ook het bestand zelf, zelfs als het nooit in git heeft gestaan, en verwijder regels met wachtwoorden. Je kunt de geschiedenis van de repository daarna opschonen met git filter-repo. Dat is alleen nog cosmetisch: een vervangen sleutel kan niemand meer gebruiken, maar een ongewijzigde sleutel red je niet door de geschiedenis te herschrijven.

Voor de toekomst zijn twee gewoontes genoeg. Zet geen geheimen in commando’s, maar vraag de agent om naar een variabele te verwijzen, bijvoorbeeld $DATABASE_URL. De toestemmingsregel onthoudt dan de naam van de variabele in plaats van het wachtwoord. Keur ook patronen goed, zoals Bash(npm run:*), in plaats van losse commando’s. Voeg in een team .claude/settings.local.json toe aan de .gitignore-sjablonen en behandel agentmappen (.claude/, .cursor/, .gemini/) als .env-bestanden. Ik schreef eerder over wat ik zelf in bestanden voor agents bewaar, in een artikel over CLAUDE.md en AGENTS.md. Een breder overzicht van hoe AI de beveiliging verandert, vind je in mijn artikel over AI en cyberbeveiliging in 2026.

Anthropic belooft prototypes

Apiiro deelde de resultaten vóór publicatie met Anthropic. Op 7 november reageerde Boris Cherny, hoofd van Claude Code, op Hacker News. Hij gaf toe dat de tool geheimen tot nu toe niet opschoonde en zei dat het team enkele oplossingen zou onderzoeken, waaronder het herkennen van zulke commando’s in de automatische modus en een eenvoudige scan op geheimen. Het team is, zoals hij schreef, „looking into what we can do to prevent this”. Hij voegde eraan toe dat Claude Code het bestand al bij het aanmaken negeert in git. Daarom denkt hij dat iemand de kopieën op GitHub handmatig heeft toegevoegd. Een oplossing is er nog niet. Melding 5544 is inmiddels gesloten en vergrendeld, terwijl het bestand waarover de melding gaat nog steeds wordt opgeslagen na elke klik op „don’t ask again”.

Veelgestelde vragen

Speelt dit probleem alleen bij Claude Code?

Van de 16 vergeleken agents bevestigde Apiiro het mechanisme waarbij een volledig commando in een projectbestand wordt opgeslagen alleen bij Claude Code. De onderzoekers vonden wel geheimen in exports van gesprekken met Cursor en aider, in geheugenbestanden van agents en in instellingen voor automatische goedkeuringen van Copilot in VS Code.

Is het genoeg om het bestand uit de repository te verwijderen?

Nee. De oude versie blijft in de git-geschiedenis, in forks en in klonen staan. De enige effectieve reactie is elk wachtwoord en elke sleutel uit het bestand vervangen. Ruim de repository pas daarna op.

Beschermt de automatische modus hiertegen?

Gedeeltelijk. Cherny raadt de automatische modus aan in plaats van vaste toestemmingsregels. Toen een lezer opmerkte dat de agent in die modus ook naar een gevoelig commando kan vragen, gaf het hoofd van Claude Code hem gelijk. De veiligste aanpak is om geheimen helemaal niet in commando’s te zetten.

Bronnen

• Apiiro: Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub (5.11.2026, bijgewerkt op 8.11)
• The Hacker News: Claude Code’s „Don’t Ask Again”-bestand lekt wachtwoorden en sleutels in 1.122 openbare GitHub-kopieën (7.11.2026)
• GitHub, anthropics/claude-code, melding #5544 (11.08.2025, gesloten op 3.01.2026)
• Documentatie van Claude Code: instellingenbestanden en prioriteit
• Eigen scan van de werkmap, 9 november 2026 (aantallen zonder paden en waarden)

// lees verderllms.txt: lezen ChatGPT en andere AI-bots het bestand?AI-overzichtGPT-6 Cyber vs Claude Mythos vs Gemini 4 CarbonAI-overzichtClaude en Europese organisaties: één dader, vele doelenAI-overzicht