GitSpawn: falha que permite executar comandos a partir de .git/config em ferramentas de IA

Uma equipe de pesquisa independente, Manifold Security, publicou um relatório que descreve uma classe de vulnerabilidade presente em várias ferramentas de assistência de programação baseadas em inteligência artificial: se um repositório recebido inclui sua pasta .git com uma configuração maliciosa, a própria configuração pode indicar um comando que a ferramenta executa na equipe do desenvolvedor fora da caixa de segurança e sem pedir confirmação. Manifold chamou o conjunto de achados "GitSpawn" e documentou oito rotas de exploração em sete agentes de linha de comandos; no momento de sua última verificação várias rotas seguiam sem adesivo. Ao mesmo tempo, o OpenAI publicou o CVE (s) que descreve um problema da mesma natureza no seu produto Codex.

Tecnicamente, a raiz é a interação entre como o Git armazena certas opções no arquivo .git/config de um repositório e como os agentes automatizados invocam operações do Git em segundo plano. Um ajuste em Git chamado core.fsmonitor Poderá conter um comando que o Git executa para acelerar a detecção de ficheiros alterados; o Git lê esse valor do próprio .git/ config do repositório. Quando um agente precisa de saber o ramo actual ou quais ficheiros mudaram as operações como o git status ou o git diff: esses comandos disparam a execução do binário configurado em core.fsmonitor. Se esse valor aponta para um executável controlado por um atacante, o comando corre com os mesmos privilégios do usuário e fora do ambiente restrito do agente.

O requisito operacional para a exploração é que o receptor obtenha a árvore de trabalho junto com a sua pasta .git intacta — por exemplo, através de um ficheiro comprimido partilhado, uma unidade de rede sincronizada, uma pasta de sincronização ou uma memória USB —; de acordo com os relatórios, nessas situações a configuração maliciosa é preservada. Manifold indica que um "clone" padrão não preserva exatamente a mesma condição em todos os casos apontados pelo pesquisador, e portanto nem sempre expõe o usuário, mas os cenários de entrega mencionados sim o fazem.

Que produtos e versões são afetados (confirmado por Manifold e/ou por advisories públicos): goose (todas as versões anteriores a 1.44.0, corrigido em 1.44.0); Codex CLI e Codex Desktop (intervalo de versões afetadas e correções publicadas até 0.131.0 / números de build concretos para macOS/Windows); Claude Code (ruta core.fsmonitor mitigada em 2.1.196, mas outra rota chamada "claude ultrareview" foi confirmada ativa em 2.1.252); Cursor CLI (documentado por Manifold com execução prévia ao diálogo de confiança); Hermes Agent, Qwen Code e Grok Build também foram confirmados por Manifold como executando comandos fornecidos pelo repositório em datas recentes e estavam pendentes de adesivo na última reverificação. OpenAI publicou pelo menos um CVE (CVE-2026-19592) que descreve o mesmo padrão em Codex; o GitHub nomeou CVE-2026-72718 à falha em goose com uma qualificação CVSS relatada.

Os efeitos práticos são claros e severos: a execução de comandos com privilégios do usuário permite que um atacante leia, modificar ou apagar arquivos locais, roubar credenciais, exfiltrar segredos (tokens, chaves SSH) e, em geral, tomar medidas não autorizadas no ambiente local. Manifold documentou casos em que a execução ocorre mesmo Antes de o utilizador ver ou aceitar a janela de "workspace trust", ou mesmo antes de o utilizador se autentique no agente — condições que pioram o risco porque eliminam fases de mitigação humana.

Atos confirmados: Manifold publicou detalhes técnicos e testes de conceito de várias rotas; alguns fornecedores já enviaram adesivos para rotas concretas (por exemplo, goose, partes de Claude Code e Cursor); OpenAI publicou CVE (s) aplicáveis ao Codex. Não há registros públicos verificados de exploração na natureza relacionados a esses achados até a data das verificações públicas citadas, e a lista de vulnerabilidades conhecidas exploradas por CISA não incluía esses CVE em sua última revisão consultada.

Estimações e elementos ainda incertos: Manifold assinala que o padrão aparece em mais agentes dos que nomeou; isso sugere que o alcance real poderia ser maior, mas não se dispõe de uma lista pública completa. Há imprecisão sobre quais versões posteriores (em particular do Claude Code para a segunda rota) já resolveram todas as rotas: Manifold confirmou a segunda rota ainda ativa na 2.1.252, e não houve confirmação pública universal de fechamento em releases posteriores ao momento do relatório. Além disso, em algum caso os fornecedores fecharam relatos como duplicados de pesquisas paralelas, o que complica traçar uma linha temporal única e pública de mitigações.

Por que isso acontece agora: não é uma falha do modelo de IA, mas do "plumbing" — as chamadas ao sistema que os agentes lançam ao iniciar uma sessão para detectar contexto do repositório. Modernas ferramentas automáticas chamam Git em segundo plano para identificar ramo e mudanças; Git, por design, permite executar hooks ou processos colaboradores configuráveis. Essa flexibilidade de Git, combinada com a automação, torna uma característica legítima em um vetor de execução remota local.

O que deve fazer um desenvolvedor ou equipamento agora mesmo (ações concretas e verificáveis): inspeccionar qualquer pasta recebida antes de abri-lo com um agente de IA; verificar a configuração de fsmonitor e valores suspeitos; desactivar o fsmonitor por omissão se não for necessário; e atualizar as ferramentas afetadas às versões adesivos. Comandos úteis (executar num ambiente seguro): abrir e revisar .git/config em qualquer pasta recebida; executargit config --get core.fsmonitordentro do repo para ver um valor activo; auditar a configuração global comgit config -- global -- list | grep fsmonitor; e, se for caso disso, desactivar por defeito comgit config -- global core.fsmonitor false. Os vendedores mitigam em alguns casos invocando Git em background com um flag que anula a variável perigosa, p. ex.git - c core.fsmonitor=false status, uma prática recomendada até serem confirmados adesivos.

Recomendações operacionais adicionais: não abrir pastas recebidas de origem não confiável em um IDE ou agente com acesso irrestricto sem antes inspecioná-las; usar ambientes isolados (máquinas virtuais ou contentores) ao explorar repositórios de terceiros; manter actualizadas as ferramentas cliente (verificar e aplicar as versões que os fornecedores tenham publicado como adesivo); e, para equipamentos, auditar fluxos de troca de código (compressão, sincronização de pastas, uso de discos externos) para prevenir que .git maliciosos seja acidentalmente testado.

Recursos de referência e contexto técnico: a documentação oficial da configuração do Git sobre opções como core.fsmonitor explica o propósito e formato dessa chave —ver https://git-scm.com/docs/git- config —. Para colocar este padrão em história, vulnerabilidades anteriores relacionadas ao bypass do diálogo de confiança em editores e ambientes foram catalogadas (por exemplo, CVE-2021-43891), cujo registro pode ser consultado em https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43891. CISA mantém um catálogo de vulnerabilidades exploradas conhecidas que convém rever periodicamente para ver se emergem explorações activas: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

Conclusão: a vulnerabilidade descrita por Manifold não requer modelos manipulados ou falhas na IA; explora a combinação da flexibilidade do Git e da automação de agentes. Embora vários fornecedores já corrigissem rotas concretas, os vetores abertos persistem em ferramentas-chave e a exposição real depende de como os desenvolvedores repositórios (por exemplo, arquivos compartilhados ou unidades externas). Até que as ferramentas fiquem todas sistemaadas e a prática de invocar o Git em segundo plano seja consideravelmente segura, a defesa mais eficaz é a inspeção prévia, a desactivação preventiva de core.fsmonitor e o uso de ambientes isolados para analisar código desconhecido.