Claude Code vaza senhas em 1.122 arquivos públicos no GitHub ao salvar comandos aprovados

O que a pesquisa encontrou

A empresa de segurança Apiiro publicou em 5 de novembro de 2026 um relatório mostrando como um comportamento padrão do Claude Code, agente de codificação da Anthropic, resulta em credenciais reais expostas em repositórios públicos do GitHub. Ao varrer o GitHub entre 1º e 3 de novembro de 2026, a empresa encontrou 2.539 segredos reais, como senhas de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, chaves de nuvem, tokens de API e logins SSH com privilégio de root, espalhados por 1.994 repositórios públicos.

63 organizações foram afetadas, a maioria empresas de software de todos os tamanhos. Uma delas confirmou à Apiiro que a chave vazada estava ativa no momento da descoberta. Entre os achados mais graves estão a própria chave de API em nível de administrador de um fornecedor de banco de dados, a senha de produção de um Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → Postgres, um token de produção da Square e a senha de administrador do banco de dados de um sistema de prontuário médico.

Como o vazamento acontece na prática

O problema nasce de uma função de conveniência. Quando o Claude Code precisa rodar um comando de shell, por exemplo para consultar um banco e entender por que o login falha em staging, ele pede confirmação antes de executar. Se o desenvolvedor escolhe a opção "Yes, and don't ask again", o agente grava o comando exato, segredo incluso, como regra permanente em .claude/settings.local.json, dentro da pasta do projeto.

O arquivo deveria ficar só na máquina do desenvolvedor, e o próprio Claude Code tenta impedir que ele vá para o controle de versão: quando cria o arquivo dentro de um repositório git, adiciona a entrada ao gitignore global do usuário. Isso cobre o caso comum, mas não cobre uma pasta que vira repositório depois, um clone em outra máquina ou um arquivo que alguém já commitou antes. A regra nunca entra no .gitignore do próprio repositório, então nada viaja junto com o projeto para protegê-lo.

Em boa parte dos casos, quem faz o commit é o próprio agente: a Apiiro rastreou 1.105 repositórios com segredo real e encontrou um commit co-autorado pelo Claude Code alterando o arquivo em 539 deles, citando modelos que vão do Sonnet 4.5 ao Opus 5.5.

Em resumo: o comportamento é do produto Claude Code, não do modelo por trás dele. A Apiiro reproduziu o mesmo padrão com o Opus 5.5 e o Fable 5.1, o que descarta a hipótese de falha pontual de um modelo específico.

A escala do problema

O GitHub tem 104.185 cópias públicas do arquivo .claude/settings.local.json, espalhadas por 103.617 repositórios. Dessas, 1.122 (1,1%) guardam pelo menos um segredo real, somando 1.379 segredos distintos. A composição do que vazou:

• 636 chaves de provedores em formato reconhecível (AWS, GitHub, npm, Supabase, Stripe, Slack, OpenAI, entre outros)
• 743 senhas ou tokens associados a hosts públicos
• 379 senhas de banco de dados e 122 chaves de serviço do Supabase
• 103 tokens de conta do Supabase, que dão acesso a todos os projetos da conta
• 43 logins SSH, alguns com senha de root
• 23 chaves AWS e 6 chaves privadas

Quanto maior o arquivo, maior o risco: um em cada dez arquivos acima de 8 KB tem um segredo real, contra menos de um em 500 abaixo de 500 bytes. Isso acontece porque quanto mais tempo o desenvolvedor passa clicando em "não perguntar de novo", mais comandos (e segredos) se acumulam na lista de permissões.

O problema também é antigo e persistente: na mediana dos repositórios afetados, o arquivo foi commitado pela primeira vez 217 dias antes da varredura, e em 118 repositórios há mais de um ano. Apagar o arquivo não resolve: 734 segredos reais aparecem só em versões antigas do histórico do git, em 509 repositórios onde o arquivo já foi removido do estado atual. Forks também copiam o problema: 211 forks de 74 repositórios carregam os mesmos segredos.

Organizações afetadas

A Apiiro documentou casos específicos, todos confirmados em commits fixados por hash:

Por que os scanners de segredo não pegam isso

Ferramentas como gitleaks e TruffleHog são afinadas para reconhecer formatos de chave: prefixo do provedor, string longa e aleatória. Rodando as duas sobre os 104.185 arquivos, a Apiiro viu o gitleaks sinalizar 564 dos 1.122 arquivos com segredo real, o TruffleHog 643, e 215 não foram sinalizados por nenhum dos dois.

A lacuna é a senha dentro do comando. Uma senha digitada depois de PGPASSWORD=, sshpass -p ou mysql -p, ou um header de autenticação numa chamada curl, é só uma palavra comum numa linha de comando comum, e os dois scanners deixam passar na maior parte das vezes. Isso importa além deste arquivo específico: o mesmo padrão aparece em qualquer lugar onde um agente registra o que executou, como transcrições de chat e notas de handoff.

Não é só um arquivo

A Apiiro encontrou o mesmo tipo de vazamento em outros arquivos que times commitam de propósito ou por hábito: o settings.json compartilhado, versão de equipe do mesmo mecanismo, tinha 298 arquivos com segredo entre 76.011 verificados. Transcrições de chat de agentes (.specstory, aider, exports do Cursor) somaram 120 arquivos com segredo em 87 repositórios, e arquivos de memória de agente (MEMORY.md e similares) apareceram em 9 repositórios, assim como configurações de auto-aprovação do GitHub Copilot no VS Code.

Um terço das notas de handoff com segredo foi escrito pelo próprio agente. O vazamento também aparece fora do GitHub: 126 dos 31.053 Hugging Face Spaces verificados têm o arquivo .claude/settings.local.json público, um deles com chave de serviço de banco de dados e senha de usuário. No GitLab.com, 2 das 69 cópias públicas checadas tinham segredo real, incluindo um token de acesso do próprio GitLab.

O risco não some se o arquivo não for público

Mesmo quando o arquivo nunca sai da máquina do desenvolvedor, ele continua sendo um JSON em texto puro na pasta do projeto, e isso já é risco. A Apiiro lembra que malware já coleta credenciais de máquinas de desenvolvedor em massa: em setembro de 2025, o worm Shai-Hulud, que se espalhou pelo npm, baixava o TruffleHog e rodava sobre os arquivos da vítima. Esse mesmo scanner sinaliza 643 dos 1.122 arquivos encontrados pela Apiiro.

Três semanas antes, pacotes maliciosos do Nx instruíram o próprio Claude Code e o Gemini CLI da vítima a vasculhar o disco atrás de segredos. O arquivo também pode vazar sem passar pelo git: dentro de um pacote npm publicado, numa imagem Docker construída com um comando de cópia, num zip ou numa pasta sincronizada. E um segredo aprovado uma vez fica ali até alguém apagar a regra manualmente, muito depois de o comando original ter sido executado.

O problema não é novo, mas nunca foi corrigido

Desenvolvedores relatam esse exato mecanismo em issues abertas no repositório do Claude Code desde agosto de 2025 (#5544, #11982, #13106, #91270), nenhuma delas respondida pela Anthropic e três fechadas automaticamente por inatividade ou duplicidade. A empresa ironPeak já tinha encontrado o mesmo arquivo com segredo em fevereiro de 2026, medindo 2,4% de repositórios com pastas de configuração de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → carregando segredos no histórico, numa amostra de 100. A Lakera, por sua vez, achou credenciais em 33 arquivos do tipo distribuídos em 30 pacotes npm em abril de 2026.

O relatório da Apiiro é o primeiro a medir a escala completa no GitHub e a cruzar isso com os outros arquivos de agente que carregam o mesmo risco. A empresa reportou cada caso de organização ao respectivo dono em 2 e 3 de novembro de 2026.

O que fazer se você usa Claude Code

Para quem desenvolve, o roteiro de resposta é direto:

1. Se o arquivo está rastreado num repositório, rode git rm --cached .claude/settings.local.json e adicione a entrada ao .gitignore do próprio repositório, não só ao gitignore global.
2. Rotacione toda credencial que o arquivo já guardou algum dia. Remover o arquivo do estado atual não limpa histórico do git, forks nem clones.
3. Mesmo que o arquivo nunca tenha sido commitado, abra-o e apague toda regra que contenha um segredo literal.
4. Pare de digitar segredos dentro de comandos: referencie-os como $VAR a partir do seu gerenciador de segredos, para que a regra salva seja $DB_URL, e não o valor real.
5. Prefira aprovar padrões, como Bash(npm run:*), em vez de comandos literais inteiros.

Para times de segurança, o recado é tratar pastas de agente como .claude/, .cursor/, .gemini/ e .specstory/, além de arquivos de memória, como arquivo de segredo, no mesmo nível do .env, tanto em laptops quanto em repositórios. Isso significa incluir essas pastas no scanning de pre-commit e CI, com um scanner capaz de pegar senha dentro de comando (padrões como PGPASSWORD=, sshpass -p, mysql -p, headers de bearer token), não só formatos conhecidos de chave, além de adicionar .claude/settings.local.json aos templates de .gitignore da organização.

Fonte: Hacker News