Uma investigação da empresa de segurança aplicacional Apiiro encontrou mais de mil cópias públicas de um ficheiro de configuração do Claude Code, o assistente de programação da Anthropic, com palavras-passe, tokens e chaves de API em texto simples. A causa não é um ataque nem uma vulnerabilidade com CVE atribuído. O problema está numa função de conveniência: quando o programador aprova um comando com a opção «Yes, and don’t ask again», o comando completo, incluindo qualquer credencial que contenha, pode ficar guardado em .claude/settings.local.json. Se esse ficheiro for incluído num commit e enviado para um repositório público, os segredos ficam à vista de qualquer pessoa.
Resposta rápida: O Claude Code guarda as aprovações permanentes de comandos em .claude/settings.local.json, e esses comandos podem incluir credenciais. A Apiiro encontrou 1122 cópias públicas desse ficheiro com segredos e, ao incluir o histórico git e outros ficheiros, um total de 2539 segredos em 1994 repositórios. Se usa o Claude Code, revogue primeiro as credenciais expostas e só depois limpe os ficheiros. Remova o ficheiro do controlo de versões com git rm --cached e acrescente-o ao .gitignore do próprio repositório.
Como é que uma aprovação se torna uma fuga de credenciais
Por omissão, o Claude Code pede autorização antes de executar a maioria dos comandos de shell. A própria documentação da Anthropic explica que, quando o Claude pede permissão para executar um comando Bash e o utilizador escolhe «Yes, and don’t ask again», o Claude Code guarda essa aprovação como uma regra de permissão em .claude/settings.local.json. A partir daí, os comandos equivalentes passam a correr sem novo pedido de confirmação.
O risco aparece quando o comando aprovado traz um segredo lá dentro. Pense numa cadeia de ligação a uma base de dados com a palavra-passe incluída, num cabeçalho HTTP com um token de autenticação ou numa variável de ambiente atribuída na linha de comandos. Segundo os investigadores, a fuga começa quando o Claude Code propõe um comando que contém credenciais extraídas de ficheiros de configuração ou fornecidas durante a resolução de um problema. A regra fica gravada tal como foi escrita, com o segredo incluído.
A ferramenta tem uma salvaguarda. De acordo com a documentação, da primeira vez que o Claude Code escreve o ficheiro num repositório git que ainda não o ignora, acrescenta **/.claude/settings.local.json ao ficheiro global de exclusões do git. A falha está no alcance dessa proteção, que vive apenas nas definições git de um utilizador, num computador. O Claude Code nunca acrescenta o ficheiro ao .gitignore do próprio projeto, pelo que a proteção não acompanha o projeto. Basta outro colaborador, outra máquina ou um ficheiro criado à mão para a salvaguarda deixar de existir.
Há ainda um fator que agrava o problema. A Apiiro encontrou commits com o Claude como coautor a alterar o ficheiro em 539 dos 1105 repositórios rastreados que continham segredos, o que sugere que o próprio agente inclui muitas vezes o ficheiro nos commits que faz.
O que a Apiiro encontrou, em números
O estudo é assinado pelos investigadores Shmulik Cohen e Matan Giladi e foi divulgado esta semana. Algumas fontes datam-no de 5 de novembro, outras de 6. A recolha de dados decorreu entre 1 e 3 de novembro de 2026. A tabela reúne os números principais.
| Indicador | Valor reportado pela Apiiro |
|---|---|
Cópias públicas de .claude/settings.local.json analisadas | 104 185, em 103 617 repositórios |
| Cópias com pelo menos um segredo | 1122 (cerca de 1,1%) |
| Segredos distintos nesses ficheiros | 1379 |
| Segredos só presentes em versões antigas (histórico git) | 734, em 509 repositórios |
| Forks com os mesmos segredos dos originais | 211 forks de 74 repositórios |
Cópias do ficheiro partilhado .claude/settings.json com segredos | 298 em 76 011 |
| Total, incluindo histórico e transcrições do agente | 2539 segredos em 1994 repositórios |
| Organizações identificadas | 63, sobretudo empresas de software |
O tipo de segredos encontrados torna o caso mais sério. Mais de um terço dá acesso direto a bases de dados, incluindo 379 palavras-passe de bases de dados. Entre os restantes há 43 credenciais SSH para servidores públicos, 42 tokens de GitHub, GitLab e npm, e 23 chaves AWS.
Os investigadores não testaram se as credenciais ainda funcionavam e não indicam se alguém chegou a usá-las. Ainda assim, segundo a Apiiro, uma empresa confirmou que a chave exposta estava ativa.
Porque é que os scanners habituais não apanham tudo
O estudo deixa também um aviso para as equipas que confiam apenas em ferramentas automáticas de deteção de segredos. Dos 1122 ficheiros com segredos, o gitleaks assinalou 564 e o TruffleHog 643, e os dois juntos falharam 215. A explicação é que estas ferramentas reconhecem bem formatos de chave estruturados, como as chaves AWS. Têm mais dificuldade com palavras-passe soltas no meio de uma linha de comandos, que só se identificam pelo contexto.
A Apiiro comparou também a documentação de vários assistentes. Entre 16 agentes de programação, o Claude Code é o único que, segundo a documentação, guarda por omissão o comando aprovado completo num ficheiro do projeto.
Um comportamento já reportado
Não é um problema novo. Um pedido aberto em agosto de 2025 no repositório do Claude Code já dizia que os comandos aprovados com credenciais eram guardados palavra a palavra na lista local de permissões. Segundo a Apiiro, os relatos anteriores sobre este comportamento no GitHub foram fechados por um bot automático sem resposta da Anthropic. Até à publicação deste artigo, não encontrámos nenhuma posição pública da Anthropic sobre o estudo. Convém notar que a Apiiro vende produtos de segurança para aplicações e agentes.
Os investigadores começaram também a avisar diretamente os donos dos repositórios afetados. Num desses avisos, pedem para revogar o segredo, executar git rm --cached .claude/settings.local.json e acrescentar o ficheiro ao .gitignore, garantindo que não usaram a credencial.
O que fazer agora: passos concretos
Não há atualização para instalar, porque não existe nenhuma correção identificada nem nenhum CVE. Cabe a cada equipa agir sobre os seus repositórios, e a ordem dos passos conta: as credenciais devem ser revogadas antes da limpeza, porque apagar o ficheiro não retira o segredo do histórico git nem dos forks.
- Procurar: pesquise na organização GitHub os ficheiros
.claude/settings.local.jsone.claude/settings.json, incluindo o histórico. Num repositório local,git log --all -- .claude/settings.local.jsonmostra se o ficheiro já foi incluído em algum commit. - Revogar: trate qualquer palavra-passe, token ou chave encontrada como comprometida e substitua-a.
- Retirar do controlo de versões: execute
git rm --cached .claude/settings.local.jsone acrescente o caminho ao.gitignoredo repositório e aos modelos de.gitignoreda organização. - Rever as regras guardadas: o comando
/permissionsdo Claude Code lista as regras ativas. Apague as aprovações que contenham segredos. - Tirar os segredos dos comandos: use variáveis de ambiente ligadas a um gestor de segredos, para que a regra guardada contenha apenas uma referência como
$DB_URLe não o valor real. - Alargar a deteção: trate as pastas dos agentes (
.claude/,.cursor/,.gemini/,.specstory/), os ficheiros de memória e as transcrições como se fossem ficheiros.env, tanto nos repositórios como nos portáteis.
Porque é que isto importa em Portugal
Os assistentes de programação com IA estão a entrar rapidamente nas equipas de desenvolvimento, incluindo em PME e startups portuguesas. Este caso mostra que o risco não vem só de agentes manipulados por atacantes. Também vem dos rastos que deixam durante o trabalho normal, em ficheiros que os programadores raramente abrem. O próprio iTWire sublinha que não se trata de um prompt hostil a convencer um modelo de IA a roubar uma palavra-passe.
Para as organizações abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a gestão de credenciais e a segurança da cadeia de desenvolvimento fazem parte das medidas de gestão de risco exigidas. Uma chave de produção exposta num repositório público pode ser o ponto de partida de um incidente significativo, a notificar ao CNCS. Se as credenciais derem acesso a bases de dados com dados pessoais, o caso pode também cair no RGPD: uma violação de dados pessoais tem, em regra, de ser notificada à CNPD no prazo de 72 horas após o responsável dela tomar conhecimento.
Para programadores e gestores técnicos, a lição é simples: a conveniência de não voltar a responder a um pedido de autorização tem um custo, e os ficheiros de configuração dos agentes de IA devem ser tratados com o mesmo cuidado que qualquer ficheiro com segredos.
Perguntas frequentes
Isto é uma vulnerabilidade do Claude Code com CVE?
Não. Não há nenhum CVE atribuído. O problema resulta do funcionamento documentado da opção de aprovação permanente, que guarda o comando completo, e do facto de o ficheiro poder acabar num commit e num repositório público.
Que ficheiro devo verificar?
Sobretudo .claude/settings.local.json, mas também o ficheiro partilhado .claude/settings.json, o histórico git de ambos e as transcrições guardadas do agente.
Basta apagar o ficheiro do repositório?
Não. O segredo continua no histórico git e em eventuais forks. É preciso revogar e substituir primeiro as credenciais expostas e só depois retirar o ficheiro do controlo de versões e acrescentá-lo ao .gitignore do projeto.
Como evito que volte a acontecer?
Não escreva segredos diretamente nos comandos. Use variáveis de ambiente ligadas a um gestor de segredos, acrescente o ficheiro local aos modelos de .gitignore da organização e estenda a deteção de segredos às pastas de configuração dos agentes de IA.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Apiiro, pela Anthropic na documentação de definições do Claude Code e na documentação de permissões, e pelo iTWire.