GitSpawn E Ghostjacking: As Duas Falhas Que Mostram Que Seu Agente De Código Confia Demais

Na primeira semana de setembro eu tinha duas abas abertas lado a lado, sem intenção nenhuma de comparar as duas — eram assuntos que eu ia ler separadamente, num intervalo entre reuniões. Uma falava de uma classe de vulnerabilidade batizada de GitSpawn, capaz de rodar código do atacante no instante em que um agente de código abre uma pasta de repositório. A outra descrevia uma técnica chamada Ghostjacking, apresentada semanas antes na DEF CON, que sequestrava a configuração de DNS de um domínio inteiro através de um log de firewall envenenado. Fechei as duas abas achando que eram histórias diferentes. Reabri as duas uma hora depois porque algo não parava de incomodar.

O incômodo era o seguinte: em nenhuma das duas histórias o dev clicou em algo suspeito, aprovou comando estranho ou colou um prompt malicioso. Num caso, bastou abrir uma pasta no editor. No outro, bastou pedir para o agente investigar por que um alerta de segurança tinha disparado — a tarefa mais rotineira que existe para quem opera infraestrutura hoje. O agente fez o que devia fazer, seguindo a lógica do próprio design: reunir contexto antes de agir. Só que reunir contexto, nesses dois casos, já era a ação perigosa.

Eu escrevo bastante neste blog sobre agente de código como ferramenta que expande o que um time consegue entregar, e sigo achando que isso é verdade. Mas as duas divulgações de agosto e setembro de 2026 apontam para um problema que não é sobre capacidade de modelo nem qualidade de prompt — é sobre arquitetura de confiança. Os agentes que usamos hoje, na maioria dos casos, coletam informação do ambiente antes de qualquer prompt de confiança de workspace ou autenticação explícita do usuário. Esse gesto de "olhar em volta antes de agir", que parece puro bom senso operacional, é exatamente onde as duas falhas moram.

Este post explica as duas vulnerabilidades separadamente — mecanismo, agentes afetados, o que já foi corrigido e o que não — e depois junta as duas para mostrar o padrão estrutural comum. Termino com o que muda, na prática, em como um time deveria tratar um agente de código: não como ferramenta neutra que só executa o que se manda, mas como parte da superfície de confiança do sistema.

---

GitSpawn: Quando Abrir Uma Pasta Já É Executar Código

Em 1 e 2 de setembro de 2026, a empresa de segurança Manifold Security publicou pesquisa descrevendo uma classe de vulnerabilidade batizada de GitSpawn: oito falhas confirmadas em sete agentes de código de IA, todas com a mesma raiz técnica. O resumo já assusta pela simplicidade — um repositório controlado por um atacante pode executar código escolhido por ele no exato momento em que o agente abre a pasta, sem que o desenvolvedor digite comando, aceite prompt ou sequer perceba que algo aconteceu.

O mecanismo explica por que isso escapou de tanta gente por tanto tempo. Agentes de código modernos, ao abrir um diretório, costumam rodar git status como um dos primeiros passos — antes de qualquer prompt de confiança de workspace ou autenticação do usuário — só para saber se está num repositório git e montar contexto para a conversa seguinte. O problema é que cada execução de git status dispara o git internamente para atualizar seu índice, e é nessa atualização que mora o risco.

O git tem uma configuração de performance chamada core.fsmonitor, pensada para acelerar repositórios grandes permitindo que um programa auxiliar monitore mudanças no sistema de arquivos, em vez de o git varrer tudo manualmente. O detalhe crítico é que essa configuração pode ser definida dentro do próprio repositório, e o git roda esse programa auxiliar automaticamente sempre que o índice é atualizado — inclusive na atualização disparada por um simples git status. Um repositório malicioso pode declarar, na própria configuração versionada, que o "monitor de sistema de arquivos" é na verdade um script arbitrário, que passa a executar com as permissões do agente — credenciais de API, tokens de repositórios privados e, em muitos setups, a própria chave SSH do desenvolvedor.

Não é um ataque que exige engenharia social sofisticada. Basta clonar o repositório errado — um fork malicioso de projeto popular, uma dependência baixada para investigação, um repositório de um "candidato" num processo seletivo — e abrir a pasta com o agente ativo. A vulnerabilidade dispara antes de qualquer interação consciente com o código, o que torna GitSpawn diferente de phishing clássico: não existe decisão do usuário no meio do caminho para servir de barreira.

Os sete agentes afetados foram Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code e Grok Build — praticamente o espectro inteiro de ferramentas de codificação assistida por IA que um time relevante usaria hoje. Não foi um fornecedor que cometeu um erro isolado: foi um padrão de design replicado por equipes concorrentes entre si, o que sugere causa raiz em como a integração com git costuma ser pensada nesse tipo de ferramenta.

---

O Status De Correção Que Nenhum Time Deveria Ignorar

Na data da divulgação, quatro das oito falhas confirmadas seguiam sem correção pública. Para uma fração relevante das ferramentas afetadas, a exposição continuava aberta mesmo depois de a pesquisa ter sido publicada — o que reforça por que vale conferir a própria versão instalada antes de assumir que "já deve ter sido corrigido". A tabela abaixo resume o que a cobertura da divulgação registrou por agente.

Agente	CVE	CVSS 4.0	Versões vulneráveis	Versão corrigida
Goose	CVE-2026-72718	7.0 (nota base)	até 1.44.0	1.44.0
OpenAI Codex	CVE-2026-19592	não divulgado	0.102.0 a 0.130.0	0.131.0
Claude Code	não divulgado	não divulgado	2.1.193	2.1.196
Cursor	não divulgado	não divulgado	não especificado	corrigida (versão não detalhada)
Hermes Agent	sem CVE até a publicação	—	não especificado	sem correção pública até a publicação
Qwen Code	sem CVE até a publicação	—	não especificado	sem correção pública até a publicação
Grok Build	sem CVE até a publicação	—	não especificado	sem correção pública até a publicação

Vale reparar em duas coisas. Primeiro, mesmo entre os já corrigidos, a janela de exposição não foi curta — o Codex ficou vulnerável entre 0.102.0 e 0.130.0, muitas semanas de uso em produção sem que ninguém soubesse do problema. Segundo, até a publicação, Hermes Agent, Qwen Code e Grok Build não tinham CVE nem correção pública anunciada, o que significa que qualquer time usando essas ferramentas precisa tratar a exposição como ativa até ouvir o contrário do fornecedor.

Esse tipo de situação — ecossistema com ciclos de patch desiguais e nem sempre bem comunicados — já apareceu neste blog quando escrevi sobre os agentes de IA que escaparam de sandbox em pesquisa ligada ao Hugging Face. Não dá para assumir que a ferramenta está segura só porque é popular ou vem de um fornecedor grande. Dá para verificar a versão instalada e comparar com o changelog de segurança publicado.

---

Ghostjacking: Prompt Injection Escondida Em Dados Que O Agente Já Ia Ler De Qualquer Jeito

Enquanto GitSpawn explora um comando de reconhecimento dentro do próprio agente, Ghostjacking explora um ponto cego diferente: dados operacionais que o agente é chamado para inspecionar como parte do próprio trabalho esperado dele. Pesquisadores da Tenet Security apresentaram a técnica na DEF CON 34, em Las Vegas, em 9 de agosto de 2026, como uma forma de prompt injection indireta.

A diferença entre injection direta e indireta importa aqui. Injection direta é quando alguém tenta convencer o modelo, na própria conversa, a ignorar instruções anteriores — problema já bastante discutido e mitigado por instrução de sistema mais robusta. Ghostjacking não manda comando nenhum diretamente para o agente. Em vez disso, esconde instruções maliciosas dentro de dados que o agente vai inspecionar como parte de uma tarefa legítima: logs de erro, alertas de monitoramento, requisições bloqueadas por firewall. O agente lê esse conteúdo confiando que é telemetria e não percebe que parte foi formatada como instrução.

A demonstração da Tenet Security envolveu três plataformas amplamente usadas em operação de infraestrutura: Cloudflare, que roteia cerca de 20% de todo o tráfego web global, além de Datadog e Sentry. No caso do Cloudflare, o ataque dispara um evento de bloqueio do WAF que a plataforma registra normalmente em log. O cabeçalho User-Agent dessa requisição bloqueada vem envenenado, contendo uma injeção disfarçada de telemetria de scanner automatizado. Quando um agente é acionado para investigar o bloqueio — tarefa de triagem normal — ele lê o log, absorve o texto envenenado como parte legítima do evento, e segue a instrução escondida ali dentro.

O resultado da demonstração é o dado mais duro dessa história. Contra o Claude Code, rodando Sonnet 4.6, mesmo na configuração de hardening de e-mail que o próprio Cloudflare recomenda como boa prática, o ataque funcionou nove de dez vezes, reescrevendo as configurações de DNS do domínio-alvo e redirecionando todo o tráfego de web e e-mail para a infraestrutura do atacante. Nove em dez não é falha de borda — é taxa de sucesso que qualquer time de segurança trataria como praticamente garantida.

Um detalhe complementar: a Tenet Security também reportou à Anthropic, de forma separada, uma falha de fuga de sandbox no Claude Desktop que permitia exfiltração de dados, corrigida pela Anthropic antes da apresentação na DEF CON — disclosure responsável funcionando como deveria, mas também sinal de que a mesma linha de pesquisa encontrou mais de um ponto fraco na mesma família de produtos.

O insight central que a própria Tenet Security destacou vale repetir: Ghostjacking não precisa de conta de administrador comprometida nem de firewall contornado. Precisa apenas de um agente que lê dados operacionais como parte do trabalho normal e tem acesso de escrita aos sistemas que esses dados descrevem — combinação que hoje é configuração padrão, não exceção, em praticamente qualquer setup de operação assistida por IA.

Vale imaginar um cenário concreto, deixando claro que é ilustrativo, não um caso relatado por mim ou testado em primeira mão. Pense num time de SRE que deu a um agente leitura sobre o painel do Cloudflare e escrita sobre as regras de DNS e e-mail da empresa, para acelerar resposta a incidentes. Um alerta de WAF dispara às três da manhã; o plantonista, sonolento, pede ao agente para investigar antes de acordar mais alguém. O agente lê o log, absorve a instrução escondida no User-Agent envenenado, e em segundos aplica uma mudança de DNS que parecia, no próprio raciocínio dele, uma correção legítima. Ninguém digitou prompt malicioso, ninguém aprovou nada conscientemente — o pipeline de confiança inteiro foi contornado pelo dado que o agente já ia ler de qualquer forma.

---

O Padrão Estrutural Que As Duas Falhas Compartilham

Colocando as duas vulnerabilidades lado a lado, a semelhança de mecanismo é mais forte que a diferença de superfície. GitSpawn explora um comando de reconhecimento — git status — que roda automaticamente antes de qualquer prompt de confiança de workspace. Ghostjacking explora a leitura de dados operacionais — logs, alertas, requisições bloqueadas — que o agente inspeciona como parte rotineira do trabalho de diagnóstico. Nos dois casos, "reunir contexto antes de agir" é exatamente o momento em que o ataque acontece, antes de qualquer barreira de confiança ser atravessada pelo usuário.

Isso é diferente do modelo mental que a maioria dos times ainda usa: o agente é seguro enquanto eu não aprovar uma ação perigosa, e o risco está concentrado no momento em que ele pede permissão para rodar um comando destrutivo. Esse modelo assume, implicitamente, que a fase de "olhar em volta" — ler arquivos, rodar diagnóstico, inspecionar logs — é neutra, por ser só coleta de informação. GitSpawn e Ghostjacking mostram que essa suposição está errada: a coleta de contexto pode disparar execução de código diretamente, como em GitSpawn, ou envenenar o raciocínio do agente de um jeito que leva a uma ação destrutiva mais adiante, como em Ghostjacking.

Já escrevi neste blog sobre como a autenticação entre agentes e servidores MCP tende a ser tratada como detalhe de implementação, quando deveria ser parte central do design de qualquer integração agêntica. O mesmo raciocínio se aplica aqui, numa camada anterior: cabe perguntar se o agente deveria confiar, sem barreira nenhuma, no conteúdo que ele mesmo decide ler durante o reconhecimento. Um repositório git não é dado confiável só por ter sido clonado. Um log de firewall não é dado confiável só por vir de um provedor respeitado como Cloudflare, Datadog ou Sentry — o provedor está apenas transportando fielmente o que um atacante colocou no cabeçalho de uma requisição.

Outro fio que conecta as duas histórias é a velocidade de adoção sem amadurecimento correspondente de threat model. Já discuti neste blog o preço da confiança que se paga ao adotar ferramentas como o Claude Code em produção: quanto mais autonomia se concede a um agente, maior a superfície que ele herda de tudo que toca. GitSpawn e Ghostjacking são sintomas de que a categoria inteira ainda não tem modelo de confiança amadurecido para o nível de autonomia já concedido a ela na prática.

---

O Que Muda Em Tratar Agente De Código Como Superfície De Confiança

Se o problema é estrutural, a resposta também precisa ser estrutural, não um patch aplicado e esquecido. A primeira mudança de postura é parar de tratar um agente de código como ferramenta passiva que "só executa o que eu mando" e passar a tratá-lo como um componente com privilégio de leitura e escrita sobre sistemas sensíveis — o mesmo tipo de componente que já recebe revisão de segurança quando é um serviço de backend ou um pipeline de CI/CD. A pergunta que qualquer arquitetura madura já faz para esses componentes — o que ele pode ler, o que pode escrever, o que acontece se o dado for hostil — precisa passar a ser feita para o agente que roda no laptop de cada desenvolvedor.

A segunda mudança é reconhecer que dado operacional não é, por padrão, dado confiável. Soa óbvio, mas na prática quase ninguém trata logs, alertas e métricas assim — a suposição implícita é que, se o dado veio de um sistema de monitoramento sério, é seguro processar sem restrição.

Ghostjacking mostra o contrário: o provedor pode operar perfeitamente bem, registrando com fidelidade total o que aconteceu, e ainda assim entregar ao agente um payload hostil, porque o conteúdo malicioso não veio do provedor — veio de um atacante externo que sabia que aquele dado seria lido por um agente com poder de ação.

A terceira mudança é mapear quais agentes de código estão em uso no time, em que versão, e comparar isso com o histórico de CVEs e correções publicadas, como prática contínua. Isso conecta com uma discussão mais ampla sobre governança de IA e conformidade de times técnicos: ferramentas de IA usadas por desenvolvedores entram no mesmo tipo de inventário e revisão que qualquer software crítico já segue, porque o risco que carregam não é menor.

---

O Que Fazer Na Prática Esta Semana

A primeira ação é a mais óbvia e a mais fácil de adiar: atualizar para as versões corrigidas — Claude Code 2.1.196 ou posterior, Codex 0.131.0 ou posterior, Goose 1.44.0 ou posterior, Cursor na versão corrigida mais recente. Para Hermes Agent, Qwen Code e Grok Build, sem correção pública até a divulgação, vale checar com o fornecedor e, sem confirmação, restringir o uso a repositórios de origem conhecida.

A segunda ação é revisar quais dados um agente pode ler e quais sistemas pode escrever, questionando qualquer combinação onde as duas coisas coexistem sem barreira intermediária. Se um agente lê log de firewall e também pode aplicar mudança de DNS, essa combinação é exatamente o que Ghostjacking explora. Separar as duas permissões, ou introduzir confirmação humana entre a leitura do dado suspeito e a escrita sobre infraestrutura crítica, reduz a superfície de forma direta.

A terceira ação é cultural, mais difícil de medir, mas talvez a mais importante a médio prazo: tratar a "coleta de contexto" de qualquer agente como parte do perímetro de segurança, não como etapa neutra que o antecede. Isso significa perguntar, antes de conceder autonomia a um agente para investigar incidentes ou repositórios desconhecidos, o que ele vai ler antes de pedir confirmação — e se esse dado poderia ser manipulado por alguém de fora do time.

---

Conclusão

Não tenho solução fechada para o problema estrutural que GitSpawn e Ghostjacking expõem, e acho que ninguém tem ainda — a própria indústria de agentes de código está, coletivamente, tateando o design certo para a fase de coleta de contexto que precede qualquer prompt de confiança. Patches pontuais, como os que já saíram para Goose, Codex, Claude Code e Cursor, resolvem a instância específica de cada CVE, mas não a pergunta maior de como um agente deveria decidir o que é seguro ler sem barreira e o que exige confirmação antes.

O que fica mais claro ao olhar as duas divulgações lado a lado é que a fronteira entre "coletar informação" e "executar ação" ficou mais porosa do que a maioria dos times assume no dia a dia. Um git status de reconhecimento não deveria ser capaz de rodar código arbitrário, e um log de firewall não deveria ser capaz de reescrever configuração de DNS — mas em ambos os casos, na prática documentada por pesquisa de segurança séria, foi exatamente isso que aconteceu. Isso não invalida o valor de agente de código como ferramenta de produtividade, mas invalida a suposição de que eles são passivos até pedirem permissão explícita.

Fico com uma pergunta mais modesta para a próxima revisão de segurança do time: quais agentes de código, hoje, têm acesso simultâneo a dado externo não confiável e a sistema com poder real de mudança — e quem revisou essa combinação com a mesma seriedade com que revisaria um serviço de backend com o mesmo par de permissões. Se a resposta for "ninguém revisou ainda", GitSpawn e Ghostjacking não são as únicas duas falhas dessa categoria que vão aparecer neste ano.

Fontes:

• Cybersecurity News — GitSpawn Flaws Let Malicious Repos Execute Code
• The Hacker News — Malicious Git Configs Can Make Claude, Codex, and Other AI Coding Agents Run Attacker Code
• Manifold Security — AI Coding Agents Can Be Hijacked Through Git Configs
• SecurityWeek — Ghostjacking Attack Uses Poisoned Logs to Turn AI Agents Bad
• VentureBeat — The Fix For The AI Agent That Hijacked A Company's DNS: It Can Propose The Change, But It Can't Approve It