Assistentes de codificação por IA, como Claude Code, Cursor e Grok Build, podem executar comandos arbitrários no instante em que um desenvolvedor abre um repositório não confiável, sem qualquer clique ou aviso. A falha surge da maneira como essas ferramentas invocam o recurso core.fsmonitor do Git para escanear os arquivos de um projeto.

Por que o problema é importante agora

Os desenvolvedores estão dependendo cada vez mais de agentes de IA para sugerir código, refatorar funções ou até escrever módulos inteiros. Esses agentes precisam de um snapshot rápido do workspace, por isso executam git status nos bastidores. Quando o Git lê o arquivo .git/config de um repositório, qualquer valor atribuído a core.fsmonitor é tratado como um comando de shell que o Git executará. Um ator malicioso pode colocar um comando manipulado nessa entrada de configuração, e a chamada de Git em segundo plano da IA o acionará antes mesmo de o usuário digitar uma única linha de código.

O código é executado com as próprias permissões do desenvolvedor, contornando o sandbox no qual o agente de IA normalmente opera. Na prática, um repositório comprometido pode instalar malware, exfiltrar credenciais ou alterar arquivos de origem, tudo isso enquanto o desenvolvedor acredita que o assistente está apenas oferecendo sugestões.

Como o ataque se desenrola

  1. Preparação – Um invasor cria um repositório cujo .git/config contém uma linha como core.fsmonitor = /caminho/para/script/malicioso.
  2. Entrega – O repositório é entregue como um arquivo zip, copiado de um pendrive, sincronizado por meio de um drive compartilhado ou colocado de outra forma na máquina da vítima com a pasta .git já presente.
  3. Gatilho – O desenvolvedor abre a pasta em uma IDE habilitada para IA. O assistente executa git status para coletar contexto. O Git lê a configuração local, executa o comando core.fsmonitor e o script malicioso é executado imediatamente.

Um simples git clone não expõe esse risco porque o clone cria um diretório .git novo que não possui a configuração adulterada. O ataque só funciona quando o invasor consegue fornecer uma pasta .git pré-existente.

O que está em jogo

  • Desenvolvedores individuais podem ter suas máquinas comprometidas sem perceber, perdendo quaisquer dados que o agente de IA possa acessar.
  • Equipes que compartilham código por meio de drives internos ou arquivos zip de terceiros podem espalhar o payload por várias estações de trabalho.
  • Fornecedores de ferramentas correm o risco de danos à reputação se os usuários atribuírem a violação ao assistente de IA em vez da interação subjacente com o Git.

Como o comando malicioso herda os direitos do usuário, ele pode modificar qualquer arquivo que o desenvolvedor possa, incluindo chaves SSH, scripts de build ou credenciais de implantação.

Etapas de mitigação que os desenvolvedores podem adotar hoje

  • Não confie nas configurações locais do Git. A configuração de um repositório substitui os valores globais toda vez que um assistente de IA consulta o projeto.

  • Inspecione a entrada core.fsmonitor antes de abrir uma pasta com um assistente: 

    git config --get core.fsmonitor

    Se qualquer valor aparecer, trate-o como suspeito.

  • Remova a entrada com: 

    git config --local --unset core.fsmonitor

  • Verifique outras chaves de risco que o Git pode executar: hooksPath, sshCommand, pager, editor, filter. Use o mesmo padrão git config --get para verificar se estão vazias.

  • Prefira clones limpos para qualquer código que você pretenda fornecer a uma ferramenta de IA. Se você precisar trabalhar com um zip ou pasta transferida, exclua o diretório .git e reinicialize o repositório, ou execute as verificações acima primeiro.

Onde reside a responsabilidade

A vulnerabilidade não é uma falha nos modelos de linguagem que alimentam o Claude Code, Cursor ou Grok Build; é uma consequência de como essas ferramentas coletam informações de arquivos. Alguns fornecedores começaram a isolar (sandbox) as chamadas de Git de forma mais rigorosa, mas o comportamento padrão ainda confia nas configurações locais do repositório. Até que a indústria adote um padrão que remova ou ignore entradas de configuração potencialmente perigosas quando um agente de IA escaneia um workspace, os desenvolvedores devem permanecer como a última linha de defesa.

O que observar a seguir

  • Atualizações de ferramentas que sanitizam explicitamente a configuração do Git antes de invocar git status.
  • Diretrizes orientadas pela comunidade para o desenvolvimento seguro assistido por IA, que provavelmente incluirão verificações de pré-execução recomendadas.
  • Pesquisas de segurança que podem descobrir chaves de configuração adicionais do Git capazes de execução de código, expandindo a lista de verificação além das cinco destacadas acima.

Em resumo: um assistente de IA pode ser um parceiro de programação conveniente, mas ele executará prontamente qualquer comando oculto na configuração do Git de um repositório. Verifique o workspace antes de permitir que o assistente o toque.