Falhas críticas no Claude Code expõem desenvolvedores a RCE e roubo de chaves de API
Múltiplas vulnerabilidades descobertas no Claude Code, assistente de programação com IA da Anthropic, mostraram que abrir um projeto aparentemente inofensivo pode ser o bastante para comprometer todo o ambiente de desenvolvimento. As falhas permitiam desde execução remota de código (RCE) até exfiltração de chaves de API, com impacto direto na infraestrutura de IA e em serviços conectados.
As vulnerabilidades foram analisadas em profundidade por pesquisadores de segurança, que identificaram problemas em três pilares da ferramenta:
– mecanismos de configuração via Hooks;
– servidores MCP (Model Context Protocol);
– variáveis de ambiente usadas pelo assistente.
O ponto central é que essas configurações, que deveriam apenas ajustar o comportamento do assistente, passaram a ter efeito prático de “código em execução”, criando uma nova superfície de ataque em ambientes de desenvolvimento baseados em IA.
—
Risco imediato: abrir o repositório já dispara o ataque
Diferente do modelo clássico, em que o usuário precisa rodar explicitamente um binário ou script malicioso, no caso do Claude Code o simples ato de clonar e abrir um repositório controlado por um invasor poderia ser suficiente para:
– executar comandos arbitrários na máquina do desenvolvedor;
– expor a chave da API da Anthropic e outras credenciais sensíveis;
– acionar integrações externas sem qualquer confirmação adicional.
Ou seja, o momento de risco se antecipa: o ataque não começa quando o código é compilado ou executado, mas quando o projeto é carregado pelo assistente de IA e suas configurações são interpretadas.
—
Bypass de consentimento via hooks em diretórios não confiáveis (CVSS 8,7)
Uma das vulnerabilidades, ainda sem identificador CVE público (CVSS 8,7), permitia injeção de código por meio de um bypass no fluxo de consentimento do usuário. O problema ocorria quando o Claude Code era iniciado em um diretório não confiável que continha configurações específicas.
O ponto frágil estava nos hooks definidos no arquivo `.claude/settings.json`. Esses hooks, pensados para automatizar tarefas ou ajustar o ambiente, podiam ser manipulados para:
– executar scripts ou comandos assim que o projeto fosse aberto;
– contornar o fluxo de aprovação do usuário, que deveria exigir consentimento explícito;
– simular uma configuração legítima, mas com ações maliciosas embutidas.
A Anthropic tratou essa falha na versão 1.0.87 do Claude Code, liberada em setembro de 2025, endurecendo o fluxo de consentimento e limitando o comportamento de hooks em diretórios considerados não confiáveis.
—
CVE-2025-59536: comandos shell automáticos na inicialização (CVSS 8,7)
Outra falha de alta gravidade, catalogada como CVE-2025-59536 (CVSS 8,7), ampliava o risco ao permitir a execução automática de comandos shell durante a inicialização da ferramenta. Bastava o usuário abrir um projeto em um diretório sob controle de um atacante para que scripts fossem executados sem qualquer clique adicional.
Entre os vetores de ataque estavam:
– uso de arquivos de configuração como `.mcp.json` e `.claude/settings.json` para sobrepor aprovações prévias;
– modificação silenciosa de preferências, ativando integrações e servidores MCP sem alerta claro;
– combinação dessas configurações com scripts externos, possibilitando acesso ao sistema operacional.
Na prática, um invasor poderia:
– instalar backdoors;
– extrair arquivos sensíveis;
– alterar código-fonte;
– pivotar para outros sistemas conectados ao ambiente do desenvolvedor.
Essa vulnerabilidade foi corrigida na versão 1.0.111, lançada em outubro de 2025, com mudanças no processo de inicialização, validação mais rígida de configurações e maior transparência sobre quais comandos podem ser acionados automaticamente.
—
“enableAllProjectMcpServers”: quando conveniência vira vetor de ataque
Um ponto específico chamou a atenção dos especialistas: a opção `”enableAllProjectMcpServers”: true`. Essa configuração tinha o objetivo de facilitar o uso de servidores MCP em um projeto, ativando todas as integrações definidas sem exigir aprovação individual.
Do ponto de vista de segurança, porém, o impacto é severo:
– qualquer repositório malicioso poderia declarar MCP servers apontando para infraestrutura controlada por invasores;
– ao abrir o projeto, o assistente ativaria todos esses servidores sem perguntar;
– isso criaria canais diretos de comunicação entre o ambiente do desenvolvedor e sistemas externos potencialmente hostis.
Esse comportamento reforça a necessidade de tratar configurações de IA com o mesmo rigor aplicado a scripts de inicialização e pipelines de CI/CD.
—
CVE-2026-21852: exfiltração de chaves via ANTHROPIC_BASE_URL (CVSS 5,3)
A terceira vulnerabilidade, catalogada como CVE-2026-21852 (CVSS 5,3), envolvia vazamento de informações durante o fluxo de carregamento do projeto. Embora tenha pontuação menor, o impacto prático é sensível, pois lida com credenciais diretas da infraestrutura de IA.
Segundo comunicado da Anthropic, um repositório malicioso poderia definir a variável de ambiente `ANTHROPIC_BASE_URL` apontando para um endpoint sob controle do atacante. Em determinados cenários, o Claude Code faria requisições autenticadas para esse endpoint antes mesmo de exibir o aviso de confiança ao usuário.
O efeito colateral:
– a chave de API do desenvolvedor poderia ser enviada ao servidor do invasor;
– requisições legítimas seriam redirecionadas para infraestrutura externa;
– o atacante passaria a ter acesso ao mesmo nível de privilégios de API do desenvolvedor.
Com isso, abrir um projeto manipulado deixava de ser apenas um risco local e passava a comprometer diretamente serviços em nuvem, modelos de IA e dados corporativos vinculados a essa chave.
A falha foi corrigida na versão 2.0.65 do Claude Code, lançada em janeiro de 2026, com ajustes no momento em que requisições autenticadas são realizadas e na forma como variáveis de ambiente sensíveis são tratadas.
—
O que um invasor pode fazer com uma chave de API comprometida
Uma vez em posse da chave de API da Anthropic (ou de outras integrações conectadas):
– redirecionar tráfego autenticado para servidores controlados, capturando conteúdo gerado e recebido;
– exfiltrar credenciais ativas e tokens adicionais armazenados em serviços interligados;
– acessar arquivos de projetos compartilhados com o assistente, incluindo código proprietário e dados de clientes;
– alterar ou apagar dados armazenados em nuvem, prejudicando pipelines de desenvolvimento e ambientes de produção;
– gerar custos financeiros inesperados, abusando da API com grandes volumes de requisições, treinos ou inferências.
Em organizações que centralizam grande parte do desenvolvimento em torno de assistentes de IA, uma única chave vazada pode equivaler a comprometer um repositório inteiro de segredos.
—
Mudança profunda no modelo de ameaça em ambientes com IA
Esses incidentes expõem uma mudança estrutural no modelo de risco. Em ambientes tradicionais, a ameaça principal está associada à execução de binários, scripts ou dependências não confiáveis. Já em ecossistemas baseados em IA:
– a superfície de ataque se desloca para arquivos de configuração;
– o risco se manifesta antes da execução explícita de código;
– o simples carregamento de um projeto passa a ser um ponto crítico.
Arquivos como `.claude/settings.json`, `.mcp.json` e variáveis de ambiente deixam de ser elementos passivos e assumem papel ativo na lógica de execução, podendo:
– iniciar comandos;
– estabelecer conexões externas;
– habilitar integrações automaticamente;
– contornar fluxos de consentimento mal projetados.
Na prática, configurações de IA agora fazem parte da camada de execução, o que exige que times de segurança as tratem como código – com revisão, versionamento, políticas de confiança e monitoramento.
—
Configurações como código: nova fronteira da cadeia de suprimentos
A ampliação do uso de assistentes de IA em desenvolvimento adiciona uma nova etapa na já complexa cadeia de suprimentos de software. Já não basta auditar dependências, imagens de contêiner e pipelines de CI/CD:
– configurações específicas de ferramentas de IA passam a influenciar diretamente o comportamento de todo o ambiente;
– repositórios de terceiros podem embutir configurações maliciosas voltadas exclusivamente a assistentes de código;
– ataques se tornam mais discretos, explorando opções de conveniência (como ativar todos os MCP servers) para ganhar persistência.
Isso cria um cenário em que:
– repositórios aparentemente inofensivos, focados em exemplos de uso de IA, podem ser isca para ataques;
– forks e templates compartilhados podem carregar configurações perigosas copiadas automaticamente entre projetos;
– a confiança cega em presets e arquivos padrão se torna um vetor crítico.
—
Boas práticas para desenvolvedores que usam assistentes de IA
Diante desse contexto, algumas recomendações práticas se tornam essenciais para quem utiliza Claude Code ou ferramentas similares:
1. Tratar arquivos de configuração como código executável
– Revisar manualmente `.claude/settings.json`, `.mcp.json` e outros arquivos antes de abrir o projeto com a ferramenta de IA.
– Buscar por hooks, scripts e comandos shell embutidos nesses arquivos.
2. Desconfiar de diretórios desconhecidos ou não confiáveis
– Abrir repositórios de origem duvidosa inicialmente em ambiente isolado (máquina virtual, container, pasta sem integrações ativas).
– Desativar, sempre que possível, opções de “confiança automática” para projetos recém-clonados.
3. Revisar integrações MCP antes de habilitar
– Verificar cuidadosamente a lista de servidores MCP definidos pelo projeto.
– Evitar usar configurações globais que ativem todos os servidores sem consentimento granular.
4. Gerenciar chaves de API com rigor
– Nunca reutilizar a mesma chave para múltiplos projetos ou ambientes.
– Rotacionar chaves periodicamente e sempre que houver suspeita de comprometimento.
– Restringir escopo e permissões de cada chave, limitando o impacto em caso de vazamento.
5. Isolar ambientes de desenvolvimento críticos
– Separar ambientes de teste/inovação de ambientes que acessam código ou dados sensíveis.
– Usar usuários e credenciais diferentes para projetos experimentais.
—
Medidas recomendadas para empresas e equipes de segurança
Para organizações que adotam assistentes de IA em escala, é importante ir além da proteção individual do desenvolvedor:
– Políticas de confiança de projeto
– Definir quais tipos de repositório podem ser abertos com assistentes de IA.
– Bloquear, por padrão, integrações externas em projetos recém-clonados.
– Auditoria de configurações de IA em repositórios internos
– Incluir análise de arquivos como `.claude/settings.json` em pipelines de segurança (SAST/DevSecOps).
– Criar templates seguros para projetos, com configurações mínimas e auditadas.
– Monitoramento de uso de API de IA
– Acompanhar volume, horários e padrões de uso das chaves de API.
– Implementar alertas para picos anormais de requisições ou acessos a recursos incomuns.
– Treinamento específico para desenvolvedores
– Incluir nos programas de conscientização o tema “segurança em ferramentas de IA”, abordando exatamente riscos como os descritos.
– Mostrar exemplos práticos de configurações maliciosas para facilitar identificação precoce.
—
Para onde caminha a segurança em ferramentas de IA
Os incidentes envolvendo o Claude Code funcionam como um aviso antecipado para toda a indústria: à medida que assistentes de programação ganham mais autonomia e privilégios, a fronteira entre “ferramenta de apoio” e “agente com poder de execução” se dissolve.
Algumas tendências devem se consolidar:
– Modelos mais rígidos de consentimento: fluxos em múltiplas etapas, diferenciando claramente configurações locais, integrações remotas e execução de comandos.
– Sandboxes nativas: execução de ações de IA em ambientes confinados por padrão, com acesso limitado ao sistema de arquivos e à rede.
– Políticas declarativas de segurança: arquivos de política que definem o que uma ferramenta de IA pode ou não fazer em cada projeto, aprovados por equipes de segurança.
– Melhor visualização e transparência: interfaces que mostram, de forma clara, quais comandos, hooks e servidores externos estão ativos em tempo real.
—
Conclusão: abrir projeto não é mais ato inocente
As falhas corrigidas nas versões 1.0.87, 1.0.111 e 2.0.65 do Claude Code ilustram um ponto de virada: em ambientes com forte presença de IA, o simples gesto de abrir um projeto deixa de ser algo neutro e passa a carregar implicações de segurança tão sérias quanto executar um binário desconhecido.
Para quem desenvolve, administra ou regula essas ferramentas, o recado é direto:
– arquivos de configuração são agora parte integral da superfície de ataque;
– chaves de API de IA precisam ser tratadas como segredos de alto impacto;
– fluxos de consentimento, se mal desenhados, se transformam em atalhos para RCE e roubo de credenciais.
Ajustar processos, ferramentas e mentalidade a essa nova realidade é passo obrigatório para manter a segurança em um cenário em que a inteligência artificial está cada vez mais entrelaçada ao ciclo de desenvolvimento de software.