Falhas críticas no Claude Code expõem desenvolvedores a execução remota de código e roubo de chaves de API
Múltiplas vulnerabilidades descobertas no Claude Code – assistente de programação com IA da Anthropic – mostraram que, em determinados cenários, basta o desenvolvedor abrir um projeto malicioso para que comandos sejam executados sem consentimento claro e chaves de API sejam expostas.
Essas falhas afetam diretamente a segurança da infraestrutura de IA, já que permitem desde execução remota de código (RCE) até a exfiltração silenciosa de credenciais sensíveis.
As vulnerabilidades foram documentadas por pesquisadores de segurança, que identificaram problemas na forma como o Claude Code lida com mecanismos de configuração, como Hooks, servidores MCP (Model Context Protocol) e variáveis de ambiente. Esses componentes, que deveriam apenas ajustar o comportamento da ferramenta, na prática passaram a funcionar como um vetor adicional de ataque dentro do ambiente de desenvolvimento.
O cenário é especialmente perigoso porque, em muitos casos, o único passo necessário para que o ataque seja disparado é o desenvolvedor clonar um repositório controlado por invasores e abri‑lo em seu ambiente local. A partir daí, arquivos de configuração manipulados podem acionar comandos arbitrários no sistema e ainda expor credenciais da API da Anthropic usadas pelo Claude Code.
Bypass de consentimento e injeção de código via hooks
Uma das falhas identificadas, sem número de CVE atribuído, mas com severidade classificada como CVSS 8.7, permitia a injeção de código ao burlar o fluxo de consentimento exibido ao usuário ao iniciar o Claude Code em diretórios não confiáveis.
O problema estava relacionado a hooks declarados no arquivo `.claude/settings.json`. Esses hooks, projetados para automatizar tarefas ou configurar o ambiente, podiam ser abusados para executar código malicioso antes que o usuário tivesse plena consciência do risco ou pudesse negar a execução.
Essa vulnerabilidade foi corrigida na versão 1.0.87 do Claude Code, liberada em setembro de 2025, após ajustes no fluxo de aprovação e na forma como o sistema interpreta e valida configurações definidas por projetos externos.
Execução automática de comandos shell na inicialização
Outra falha, registrada como CVE-2025-59536 (CVSS 8.7), ampliou ainda mais as preocupações. Nesse caso, o problema permitia que comandos de shell fossem executados automaticamente durante o processo de inicialização da ferramenta, desde que o usuário abrisse um projeto contido em um diretório sob controle de atacantes.
Na prática, isso significa que um repositório aparentemente legítimo pode incluir configurações e scripts que disparam ações críticas assim que o projeto é carregado pelo Claude Code. Não seria necessária nenhuma interação adicional do usuário além de abrir o diretório, o que torna o ataque extremamente furtivo.
A correção dessa vulnerabilidade foi incluída na versão 1.0.111, lançada em outubro de 2025, com alterações na lógica de inicialização e maior restrição à execução automática de comandos.
Configurações que se sobrepõem à vontade do usuário
Esses problemas expuseram um ponto sensível: arquivos de configuração, como `.mcp.json` e `.claude/settings.json`, podiam, em determinadas condições, se sobrepor à vontade explícita do desenvolvedor. Mesmo quando o usuário acreditava estar controlando o que podia ou não ser executado, as configurações internas do projeto eram capazes de reconfigurar permissões e integrar serviços externos sem transparência suficiente.
Uma opção específica, `”enableAllProjectMcpServers”: true`, era particularmente problemática. Quando ativada, ela podia autorizar automaticamente o uso de servidores MCP definidos pelo projeto, abrindo caminho para integrações externas potencialmente maliciosas sem exigir uma análise cuidadosa do desenvolvedor.
Isso desloca o centro do risco: o perigo não está apenas no código da aplicação, mas também na camada de configuração e automação que acompanha o projeto.
Vazamento de chaves de API via variável de ambiente
A terceira vulnerabilidade, CVE-2026-21852 (CVSS 5.3), estava relacionada à divulgação indevida de informações durante o processo de carregamento do projeto.
Segundo comunicado da própria Anthropic, bastava que um repositório malicioso definisse a variável de ambiente `ANTHROPIC_BASE_URL` apontando para um endpoint controlado pelo atacante. Nessa situação, o Claude Code poderia realizar requisições autenticadas para esse endpoint antes mesmo de exibir o aviso pedindo que o usuário confirmasse se confiava no projeto.
Como consequência, a chave de API do desenvolvedor poderia ser enviada para a infraestrutura do invasor, permitindo:
– Redirecionar tráfego autenticado para serviços externos controlados pelo atacante;
– Capturar credenciais ativas associadas à conta do desenvolvedor;
– Acessar arquivos e recursos vinculados a projetos integrados à API;
– Modificar, corromper ou excluir dados armazenados em serviços de nuvem;
– Gerar custos inesperados devido ao uso indevido da API para processamento de grandes volumes de requisições.
Essa falha foi corrigida na versão 2.0.65 do Claude Code, lançada em janeiro de 2026, com mudanças na ordem em que variáveis de ambiente são processadas e no momento em que as requisições autenticadas são permitidas.
Como essas falhas mudam o modelo de ameaça em ambientes com IA
Esses incidentes deixam claro que o modelo de risco tradicional para ambientes de desenvolvimento precisa ser atualizado.
Em cenários clássicos, a principal recomendação era simples: não executar código não confiável. Em ecossistemas baseados em assistentes de IA, o risco se antecipa: o perigo pode surgir no instante em que o projeto é aberto, antes de qualquer execução explícita por parte do programador.
Arquivos de configuração, que antes eram vistos apenas como metadados de apoio, hoje fazem parte efetiva da superfície de ataque. Eles definem não só o contexto de funcionamento, mas também influenciam:
– quais comandos podem ser disparados automaticamente;
– como e para onde o sistema se comunica externamente;
– quais integrações com serviços de terceiros são ativadas;
– que permissões o assistente de IA terá dentro do ambiente do desenvolvedor.
Nesse cenário, a linha entre “dados” e “código executável” fica cada vez mais tênue. Um simples JSON de configuração pode, indiretamente, levar à execução de comandos com o mesmo impacto de um script malicioso.
Assistentes de IA como novo elo frágil na cadeia de suprimentos
Outro ponto crítico é o impacto na cadeia de suprimentos de software. Repositórios públicos, dependências de terceiros e templates de projeto já eram, historicamente, alvos atraentes para ataques de supply chain.
Com a adoção massiva de assistentes de programação baseados em IA, esse risco se expande: essas ferramentas geralmente operam com permissões amplas, acesso às chaves de API do usuário e integração profunda com IDEs e sistemas de build.
Isso significa que:
– um repositório aparentemente inocente pode ser usado para configurar o assistente de IA de forma maliciosa;
– a ferramenta passa a agir como “ponte” entre o código do atacante e a infraestrutura do desenvolvedor;
– qualquer abuso de configuração pode afetar não apenas uma máquina, mas todo o fluxo de trabalho atrelado à conta de IA e à nuvem associada.
Assim, proteger apenas o código da aplicação já não é suficiente. É necessário estender práticas de segurança para o ecossistema de ferramentas inteligentes que orbitam o desenvolvimento.
Boas práticas para desenvolvedores que usam assistentes de IA
Diante desse cenário, algumas medidas passam a ser essenciais para quem utiliza ferramentas como o Claude Code no dia a dia:
1. Tratar repositórios desconhecidos como potencialmente maliciosos
Antes de abrir um projeto no ambiente de desenvolvimento principal, revise arquivos como `.claude/settings.json`, `.mcp.json` e scripts de inicialização. Se possível, faça a primeira análise em um ambiente isolado (máquina virtual ou container).
2. Reforçar a gestão de chaves de API
Utilize chaves específicas para desenvolvimento, com permissões minimizadas e limites de uso. Evite reaproveitar a mesma chave entre ambientes de teste, produção e contas pessoais. Revogue imediatamente qualquer chave que possa ter sido exposta.
3. Revisar e ajustar permissões padrão do assistente
Desative opções que habilitem automaticamente todos os servidores MCP ou integrações externas definidas pelo projeto. Prefira um modelo em que cada servidor, plugin ou integração precise de autorização explícita, com descrição clara do que fará.
4. Monitorar logs e uso de API
Acompanhe registros de chamadas de API, tanto da Anthropic quanto de outros serviços utilizados no pipeline. Atividade incomum, picos de uso ou acessos a endpoints que você não reconhece podem indicar comprometimento.
5. Separar ambientes e perfis de uso
Sempre que possível, use contas, perfis e chaves diferentes para: projetos pessoais, clientes, testes e ambientes de produção. Assim, um incidente em um contexto não compromete automaticamente todos os outros.
O papel dos fornecedores de IA na mitigação de riscos
Embora boas práticas dos desenvolvedores sejam fundamentais, a responsabilidade não é só do usuário. Ferramentas de IA precisam ser projetadas com o princípio de segurança por padrão. Isso inclui:
– fluxos de consentimento mais rigorosos e detalhados, especialmente ao carregar projetos externos;
– validação estrita de arquivos de configuração antes de permitir execução de hooks ou comandos;
– isolamento das credenciais de API de modo que não possam ser usadas por componentes não confiáveis sem autorização explícita;
– mecanismos de alerta quando um projeto tenta redefinir variáveis sensíveis como `ANTHROPIC_BASE_URL` ou ativar todos os MCPs de uma vez.
As correções lançadas nas versões 1.0.87, 1.0.111 e 2.0.65 mostram um movimento nessa direção, mas também evidenciam que o modelo de segurança para assistentes de programação ainda está amadurecendo.
Como empresas podem se preparar para esse novo tipo de risco
Organizações que utilizam assistentes de IA em larga escala devem incorporar esses vetores ao seu processo de gestão de risco. Algumas ações recomendadas:
– Políticas internas claras sobre o uso de assistentes de IA, definindo quais ferramentas são autorizadas, em quais ambientes e com quais permissões;
– Treinamentos de conscientização específicos para desenvolvedores, abordando riscos de arquivos de configuração, variáveis de ambiente e integrações automáticas;
– Auditorias periódicas em repositórios internos, buscando configurações suspeitas que possam ser usadas para abuso de hooks ou servidores MCP;
– Integração com equipes de segurança para monitorar o uso de APIs, chaves e acessos à nuvem relacionados aos assistentes de código.
Ao tratar ferramentas de IA como componentes críticos da cadeia de desenvolvimento – e não apenas como “plugins de produtividade” – as empresas reduzem significativamente a superfície de ataque.
IA como motor de produtividade… e de novos desafios de segurança
Os casos envolvendo o Claude Code ilustram uma tendência inevitável: quanto mais a IA se integra ao fluxo de desenvolvimento, mais ela passa a compartilhar os mesmos riscos – e a criar novos.
Assistentes inteligentes otimizam tarefas, revisam código, geram testes e automatizam pipelines, mas também se tornam alvos atraentes para invasores, justamente por estarem no centro da interação entre desenvolvedores, código e infraestrutura em nuvem.
A mensagem central desses incidentes é clara: em ambientes impulsionados por IA, segurança não pode ser pensada apenas como proteção do código-fonte final. É preciso considerar o ciclo completo – desde o momento em que um repositório é clonado até a forma como arquivos de configuração orientam o comportamento de ferramentas inteligentes.
Adotar uma postura mais crítica diante de projetos desconhecidos, revisar configurações com atenção e exigir mais transparência e controles de segurança dos fornecedores de IA são passos indispensáveis para reduzir o risco de execução remota de código e roubo de chaves de API em um cenário cada vez mais automatizado.