Mozilla revela como um repositório limpo transforma seu agente de IA

A equipe de segurança 0din da Mozilla acabou de mostrar algo que merece a atenção de todo desenvolvedor. Em uma prova de conceito, ela conduziu o Claude Code, o agente de codificação da Anthropic, a executar malware a partir de um repositório do GitHub aparentemente limpo. Além disso, todo o processo ocorreu durante uma configuração de projeto que parecia rotineira. Ou seja, a máquina do desenvolvedor foi comprometida enquanto a instalação seguia seu curso normal.

Portanto, vale entender cada etapa desse ataque. Assim, você consegue reconhecer o mesmo padrão no seu próprio fluxo de trabalho.

Mozilla acende o alerta para quem confia em agentes de codificação

A demonstração começou de forma simples. Primeiro, os pesquisadores pediram ao Claude Code para inicializar um projeto a partir de um repositório. De acordo com o relatório, esse repositório continha apenas alguns arquivos de estrutura básica. Além disso, ele exibia uma aparência inofensiva à primeira vista.

Contudo, a Mozilla apresentou o caso como uma prova de conceito. Portanto, os relatos disponíveis apontam para um experimento controlado, realizado dentro de um ambiente seguro. Ainda assim, a técnica revela um risco real para quem adota ferramentas agênticas no dia a dia.

Como a cadeia de configuração abriu uma janela para o atacante

O ataque dependia de um comportamento esperado do agente. Basicamente, o Claude Code seguia as instruções de configuração do projeto. Depois de clonar o repositório, ele processava um arquivo Markdown com um passo aparentemente legítimo.

Esse arquivo instruía o agente a inicializar um ambiente Python↳Python56 conteúdosVSCode + Python + Alexa: Desenvolva e teste skills para alexa localmente com pythonDev (Back & Front) · out 2025Dominando decoradores em Python: um guia completo com exemplosDev (Back & Front) · jan 2025Desenvolvimento de software: diferenças entre Python, JavaScript e JavaGestão Dev & TI · nov 2024Ver tudo em Dev (Back & Front) → com o Axiom, uma ferramenta real de monitoramento. Entretanto, o repositório também trazia um script de inicialização falso do Axiom. Quando esse script falhava, o agente buscava uma solução por conta própria. Em seguida, ele executava outro comando: python3 -m axiom init.

O registro TXT de DNS como esconderijo perfeito para a carga maliciosa

Aqui está o ponto mais engenhoso do ataque. Esse comando acionava um script de shell. Logo depois, o script lia registros TXT de DNS de um domínio criado para a demonstração, o _axiom-config.m100.cloud.

Normalmente, registros TXT de DNS servem para tarefas de configuração, inclusive ajustes de email. Nesse caso, porém, o registro guardava uma string codificada em base64. Assim que o agente decodificava e executava essa string, um shell reverso se abria na máquina.

Dessa forma, o atacante ganhava acesso remoto por comando ao computador do desenvolvedor. Enquanto isso, a instalação parecia terminar com sucesso. Tanto a vítima quanto o agente viam apenas uma mensagem de ambiente pronto.

Três camadas de indireção mantiveram o repositório aparentemente limpo

O método combinou três níveis de indireção. Primeiro, um repositório com aparência limpa. Depois, um pacote que falhava durante a instalação e solicitava um comando de inicialização. Por fim, um registro TXT de DNS que entregava a carga em tempo de execução.

Consequentemente, a carga maliciosa permanecia fora do repositório clonado. Em vez disso, ela chegava mais tarde, através do registro TXT de DNS. Portanto, o comando perigoso ficava longe dos arquivos que a maioria das pessoas revisa antes de instalar.

Esse detalhe importa bastante para as ferramentas de segurança. Afinal, testes estáticos de aplicação e verificações de software bill of materials focam nos arquivos e nas dependências presentes no repositório. Como a carga vivia fora dele, o comando executado em runtime permanecia separado dos arquivos versionados.

Do shell reverso ao acesso total: o que o atacante realmente conquista

Assim que o shell reverso fica ativo, o atacante opera com os mesmos privilégios da conta que iniciou o agente. Portanto, o alcance do estrago cresce rapidamente.

Segundo o relatório da 0din, esse acesso pode incluir segredos, chaves de API, código, documentos, sessões de navegador e senhas. Além disso, o atacante consegue instalar mais malware para manter o acesso ao longo do tempo. Logo, um único descuido na configuração abre uma porta bastante ampla.

Números que dimensionam o problema para o ecossistema de desenvolvimento

Os dados de mercado reforçam a urgência do tema. Por exemplo, o relatório State of Secrets Sprawl 2026 da GitGuardian registrou 28,65 milhões de novos segredos embutidos em commits públicos do GitHub em 2025. Isso representa um aumento de 34% em relação ao ano anterior.

Ademais, a GitGuardian apontou um crescimento de 81% nos vazamentos de serviços 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 →. Enquanto isso, a pesquisa da Stack Overflow de 2025 mostrou que 84% dos respondentes usam ou pretendem usar ferramentas de IA no desenvolvimento. Da mesma forma, a JetBrains identificou que o Claude Code alcançou 57% de reconhecimento entre desenvolvedores em 2026.

Portanto, a superfície de exposição cresce junto com a adoção. Quanto mais equipes abraçam agentes de codificação, mais atraente esse vetor se torna.

Mozilla: Permissões, sandbox e as defesas que o Claude Code já oferece

Felizmente, o Claude Code traz controles para gerenciar permissões de ferramentas. Segundo a documentação da Anthropic, você visualiza e gerencia essas regras pelo comando /permissions. Assim, a interface mostra as regras aplicadas e os arquivos de configuração que as originam.

Além disso, a documentação descreve um Bash tool em sandbox. Basicamente, ele oferece isolamento de sistema de arquivos e de rede para a execução autônoma do agente. Vale lembrar que, na prova de conceito, a carga chegou através de um registro TXT de DNS durante a configuração. Portanto, o controle de rede se mostra tão importante quanto o controle de arquivos.

A OWASP reforça essa lógica no seu Top 10 para aplicações com LLM. Lá, o excessive agency aparece como risco ligado a sistemas com autonomia ou acesso amplos demais.

O que os pesquisadores recomendam para blindar sua configuração de projeto Mozilla

Os pesquisadores deixaram orientações bem práticas. Em primeiro lugar, trate qualquer repositório desconhecido como código a inspecionar com cuidado. Da mesma forma, mantenha o olhar crítico sobre cada instrução de configuração, mesmo quando um agente executa o trabalho.

Além disso, a 0din defende que agentes de codificação exibam toda a cadeia de execução antes de rodar comandos de configuração. Ou seja, o desenvolvedor precisa enxergar os scripts e o código que chegam de forma dinâmica em runtime. Igualmente, os pesquisadores recomendam restrições de rede durante a inicialização e pontos de aprovação humana para etapas automáticas.

Em resumo, a lição da Mozilla soa direta. Inspecione quais comandos vão rodar, o que esses comandos chamam e como cada dado externo chega durante a configuração. Assim, você mantém o poder dos agentes de codificação e ainda protege sua máquina e seus segredos.

Acompanhe nosso perfil no Instagram!