Claude Code vaza segredos de desenvolvedores em repositórios públicos do GitHub

Um estudo de pesquisadores da Apiiro revelou que o Claude Code, assistente de codificação da Anthropic, pode salvar senhas, chaves de API e tokens SSH em texto claro quando um usuário seleciona a opção "Sim, e não pergunte novamente" durante a aprovação de comandos. Mais de 1.000 cópias desses arquivos de configuração foram encontradas em repositórios públicos do GitHub, contendo 1.379 credenciais distintas.

O mecanismo do vazamento

O problema ocorre em um fluxo de trabalho aparentemente inocente. Quando um desenvolvedor usa o Claude Code para executar comandos de shell que incluem credenciais — senhas de banco de dados, chaves de API, tokens de autenticação — o assistente pede permissão antes de executar. O desenvolvedor pode clicar em "Sim, e não pergunte novamente" para evitar ter que aprovar o mesmo comando repetidamente.

Onde reside o problema: em vez de registrar apenas um padrão genérico (como `Bash(npm run:*)`), o Claude Code salva o comando exato, incluindo a credencial em texto claro, em um arquivo chamado `.claude/settings.local.json`. Se esse arquivo acabar sendo commitado e enviado para um repositório público do GitHub — seja por acidente, por clonagem em outra máquina, ou porque o próprio Claude Code o commitou — todas as credenciais ficam expostas.

Os pesquisadores da Apiiro examinaram 104.185 cópias públicas desse arquivo em 103.617 repositórios. Cerca de 1,1% deles, ou 1.122 cópias, continham pelo menos uma credencial real, totalizando 1.379 segredos distintos. Quando os pesquisadores ampliaram a busca para incluir versões mais antigas do arquivo, arquivos de configuração compartilhados e transcripts de chat de agentes, o total subiu para 2.539 segredos em 1.994 repositórios.

A natureza das credenciais expostas é particularmente preocupante. Mais de um terço abria acesso direto a bancos de dados, incluindo 379 senhas de banco de dados e 122 chaves Supabase service-role. Outros incluem 43 logins SSH para servidores públicos, alguns com senha de root, 42 tokens do GitHub, GitLab e npm, e 23 chaves AWS.

Impacto organizacional

Embora a maioria dos arquivos expostos pertencesse a desenvolvedores individuais, 63 organizações foram afetadas, desde grupos estudantis até provedores estabelecidos. Entre elas: uma empresa de bancos de dados com chave de API cloud com acesso de administração, uma agência de software com token de produção do Square, e a senha de proprietário do banco de dados em nuvem de um aplicativo de registros médicos.

Apiiro notificou as organizações afetadas, embora tenha reconhecido que não testou se as credenciais ainda funcionavam. Uma organização confirmou que sua chave ainda estava ativa.

Por que as ferramentas de segurança convencionais falharam

Um dado que deveria alarmar equipes de segurança: dos 1.122 arquivos com segredos, o gitleaks (um scanner de segredos amplamente utilizado) sinalizou apenas 564, e o TruffleHog, outro scanner popular, sinalizou apenas 643. Isso significa que 215 arquivos com credenciais em texto claro escaparam tanto do gitleaks quanto do TruffleHog.

O problema também não se limita ao GitHub. O arquivo reside em formato JSON puro nas máquinas dos desenvolvedores, onde pode ser encontrado por malware. Em setembro de 2025, o worm Shai-Hulud do npm executou o scanner TruffleHog sobre os arquivos das máquinas infectadas, sinalizando mais da metade dos arquivos como contendo segredos.

A resposta da Anthropic

Boris Cherny, chefe do Claude Code na Anthropic, reconheceu o problema em um fórum do Hacker News, dizendo que a empresa está buscando soluções. "Historicamente, o Claude Code não fez limpeza de segredos (existem muitas boas ferramentas para isso), mas estamos avaliando o que podemos fazer para evitar isso", disse Cherny.

A equipe planeja prototipar abordagens incluindo fazer o modo automático capturar esses comandos e integrar um scanner básico de segredos. No entanto, um leitor apontou que a mesma exposição poderia ocorrer no modo auto, e Cherny concordou: "Bom ponto".

Cherny também argumentou que como o Claude Code adiciona o arquivo à lista global de .gitignore do desenvolvedor na criação, os cópias expostas foram criadas manualmente e enviadas. Contudo, os pesquisadores observaram que em 539 dos 1.105 repositórios que rastrearam, um commit listando Claude como coautor alterou o arquivo — sugerindo que o próprio Claude frequentemente commita o arquivo de configurações.

Um problema reportado há mais de um ano

Usuários do Claude Code reportaram esse comportamento em issues do GitHub desde agosto de 2025. Em dezembro de 2025, um relatório descreveu chaves de API chegando ao settings.local.json e acabando em um repositório público. Um bot automático fechou o relatório como "não planejado" em janeiro de 2026, após 60 dias sem resposta da equipe da Anthropic.

O problema é fundamental: o Claude Code não adiciona o arquivo à lista .gitignore do próprio projeto — ele adiciona apenas à lista global do usuário. Isso significa que a proteção não viaja com o projeto. Quando alguém clona o repositório ou quando uma pasta se torna um repositório, a proteção some.

O que fazer

Os pesquisadores recomendam:

1. Buscar seu repositório do GitHub por `.claude/settings.local.json` e `.claude/settings.json` em cada repositório 2. Verificar o histórico de git para cópias mais antigas 3. Substituir todas as credenciais antes de limpar os arquivos — excluir o arquivo não remove commits anteriores ou forks 4. Parar de colocar segredos em comandos. Usar variáveis de gerenciador de segredos (como `$DB_URL`) em vez de senhas em texto claro 5. Adotar aprovação por padrão (como `Bash(npm run:*)`) ao invés de comandos individuais 6. Adicionar `.claude/settings.local.json` aos templates de .gitignore da organização

O caso do Claude Code ilustra uma tensão crescente no ecossistema de desenvolvimento: quanto mais poder damos a assistentes de código baseados em IA, mais vulneráveis nos tornamos a tipos de vazamento que não são exploits sofisticados, mas consequências de funcionalidades projetadas para conveniência. O problema não é que um modelo de IA foi "enganado" — é que uma funcionalidade de conveniência salvou dados sensíveis em texto claro, e o ecossistema de segurança que os desenvolvedores confiaram para protegê-los simplesmente não consegue detectar o padrão.

A pergunta que fica é: se scanners consolidados como gitleaks e TruffleHog perderam quase 20% dessas credenciais, quantos outros segredos estão circulando em repositórios públicos sem que ninguém saiba?

Fontes: The Hacker News, iTWire, iTnews Australia

✓ Fontes independentes cruzadas e verificadas antes da publicação