O risco mais interessante do GitSpawn não é um prompt malicioso nem uma resposta torta da IA. É bem mais banal: um projeto chega como pasta, ZIP, drive compartilhado ou backup com a pasta .git dentro. Você abre aquilo com um agente de código. Antes mesmo de pedir qualquer coisa, a ferramenta roda comandos de Git para entender o projeto.
Segundo a pesquisa da Manifold Security, esse detalhe pode ser suficiente para executar código localmente em alguns agentes. O problema está no encontro entre duas coisas que parecem normais separadamente: agentes coletando contexto em segundo plano e o Git respeitando configurações do próprio repositório.
Para quem trabalha com TI, a leitura prática é simples: repositório recebido como arquivo não deve ser tratado igual a repositório clonado de uma origem confiável. Com agente de IA aberto por cima, essa diferença ficou mais séria.
O ataque não começa no modelo
Quando um agente de código abre uma pasta de projeto, ele costuma montar contexto automaticamente. Isso pode incluir comandos como git status, git diff ou variações usadas para descobrir branch, arquivos modificados e histórico recente.
O GitSpawn explora justamente essa etapa. A pesquisa descreve casos em que agentes rodavam comandos de Git em segundo plano, sem limpar configurações perigosas do repositório. Uma dessas configurações é o core.fsmonitor, um recurso legítimo do Git que permite apontar um programa auxiliar para acelerar a detecção de mudanças em arquivos.
O detalhe é o seguinte: se a configuração estiver dentro da própria pasta .git/config, o Git pode chamar esse programa durante a atualização do índice. Se a pasta veio de alguém mal-intencionado, esse “programa auxiliar” pode ser um comando arbitrário. E ele roda como o usuário que abriu o projeto.
Não é a IA “decidindo atacar”. É a ferramenta chamando Git para se localizar, e o Git obedecendo uma configuração local que não deveria ter sido confiada naquele contexto.
Por que o ZIP muda a conversa
Um ponto importante: esse ataque não vem pelo clone normal de um repositório. A própria Manifold frisa que git clone, fetch e pull não transportam uma configuração local maliciosa de .git/config desse jeito.
O caminho perigoso é outro, e por isso ele é tão realista em ambiente de trabalho: projeto enviado como ZIP, pasta sincronizada, drive compartilhado, pendrive, backup ou pacote entregue por cliente. Nesses casos, a pasta .git pode vir junto. Se ela vier junto, também pode vir uma configuração local feita para disparar comando.
É o tipo de fluxo que acontece todo dia. Um freela recebe “o projeto atual” por arquivo. Um consultor pega um dump de repositório. Um dev abre uma pasta exportada por alguém do time. Um candidato recebe um teste técnico empacotado. Parece só bagunça operacional, mas agora essa bagunça encosta direto em execução local.
O que os pesquisadores encontraram
A Manifold diz ter encontrado a classe de falha em vários agentes de linha de comando. O texto cita casos envolvendo Claude Code, Goose, Hermes Agent, Qwen Code e Grok Build. Também afirma que Codex e Cursor tiveram variantes relacionadas e foram corrigidos após reports independentes.
O ponto editorial aqui não é decorar uma lista de ferramentas vulneráveis, até porque status de patch muda rápido. O aprendizado mais útil é o padrão: quando um agente roda comandos de Git sozinho para montar contexto, ele precisa tratar a configuração do repositório como entrada não confiável.
Se a ferramenta executa git status ou git diff usando a configuração local do projeto, um detalhe que antes era só “configuração de repo” vira superfície de ataque. E como esse comando pode rodar antes de prompt, antes de aprovação e até antes de login em alguns fluxos, o usuário talvez nem perceba que algo aconteceu.
O que isso tem a ver com Plugin4Shell
Plugin4Shell, divulgado pela Air Security, atacava outro pedaço do ecossistema: o sistema de plugins e o uso de SHA pinning como garantia de que o agente instalaria exatamente o código revisado. Ali, o problema era confiar que o pin foi realmente verificado depois do checkout.
GitSpawn é diferente, mas conversa com o mesmo alerta maior. Agentes de código estão puxando arquivo, plugin, repositório, configuração e comando para dentro do fluxo de trabalho. A cada etapa, existe uma pergunta que muita ferramenta ainda precisa responder melhor: “isso aqui foi tratado como dado ou como algo que pode mandar na máquina?”
O risco não está só no modelo. Está no encanamento em volta dele.
Checklist prático antes de abrir projeto recebido em agente
Para quem usa agente de código no dia a dia, a defesa começa com hábitos simples:
- Prefira clonar de uma origem conhecida em vez de abrir projeto recebido como ZIP ou pasta pronta.
- Se recebeu uma pasta com
.gitdentro, inspecione.git/configantes de abrir no agente. - Desconfie de configurações que apontam para comandos, scripts locais, hooks ou programas auxiliares.
- Abra material desconhecido primeiro em ambiente isolado, sem tokens de cloud, SSH e credenciais sensíveis carregadas.
- Evite rodar agente de código com acesso amplo ao seu diretório pessoal inteiro.
- Mantenha agentes atualizados e acompanhe advisories das ferramentas que você usa.
- Em empresa, trate “pasta de projeto enviada por terceiro” como artefato não confiável, não como simples anexo.
Do lado de quem cria ferramenta, a recomendação é mais técnica: comandos de Git usados para coleta de contexto precisam sanitizar configuração local perigosa. O próprio post da Manifold cita como exemplo desabilitar explicitamente core.fsmonitor em chamadas de contexto, em vez de aceitar tudo que veio dentro do repositório.
O hábito antigo ficou mais caro
Muita gente em TI já sabia que abrir arquivo desconhecido é arriscado. A novidade é que o arquivo agora pode ser uma pasta de projeto, e o “programa que abre” pode ser um agente com acesso ao seu código, ao terminal, a chaves locais e a variáveis de ambiente.
Isso muda a régua. O fluxo “baixa o ZIP e abre no agente para ele explicar o projeto” é conveniente, mas não pode ser tratado como inofensivo. Antes de pedir para a IA entender o código, vale entender o pacote que você acabou de colocar na máquina.
O bom uso de agentes não depende só de prompt melhor. Depende de higiene operacional: menos confiança automática, mais isolamento e uma dose saudável de desconfiança com qualquer repositório que chegou pronto demais.
