Falha Cursor git.exe 2026: RCE ao abrir pasta clonada
A falha Cursor git.exe que a Mindgard descreveu é do tipo que incomoda qualquer dev. Você abre uma pasta clonada do GitHub só para dar uma olhada rápida antes da call, sem aceitar sugestão de agente nenhum, sem digitar prompt, sem clicar em nada além de “abrir pasta”. E isso, segundo o relatório, já é o bastante para executar código arbitrário no Windows.
Uma ressalva antes de seguir: o caso foi divulgado com um número de CVE e uma cronologia específica. Antes de tratar qualquer detalhe como definitivo (versão corrigida, data exata de patch, texto oficial do CVE), confira a fonte primária e o changelog do Cursor no momento em que você ler isto. Relatórios de disclosure mudam de status rápido, e prefiro te mandar checar a fonte viva do que repetir um número que pode já estar desatualizado quando este texto chegar até você.
Isso dito, a mecânica técnica relatada é o que interessa, porque ela não depende de nenhum modelo de IA aprontando. Não é prompt injection, não é o agente alucinando um comando perigoso. É o editor reintroduzindo um erro clássico de resolução de binário.
A mecânica: do clone à execução sem clicar em nada
O Cursor usa o Git do sistema por baixo dos panos para várias operações de rotina (status do repositório, blame inline, histórico de commits na barra lateral). Para chamar esse binário, ele precisa decidir onde está o git.exe.
O problema está na ordem de busca. Em certas condições, segundo a Mindgard, o Cursor prioriza um git.exe presente na raiz da pasta aberta antes de ir atrás do Git instalado oficialmente no PATH do sistema. Se o repositório clonado trouxer um arquivo chamado git.exe na raiz (um binário malicioso disfarçado de ferramenta legítima), o editor chama esse arquivo pensando que é o Git de verdade assim que dispara qualquer rotina interna que dependa dele.
Repare no que isso tira da equação: nenhum agente de IA precisa estar envolvido. Você não precisa ter o chat do Cursor aberto, não precisa aceitar diff nenhum, não precisa de assistente ativado. O gatilho é o próprio editor fazendo o trabalho de sempre (mostrar status do Git na interface) ao abrir a pasta.
Na prática, o cenário de ataque é bem chato de tão banal: alguém manda um fork de uma issue, um template de curso, o teste técnico de uma vaga. Dentro da pasta, empacotado como se fosse parte do projeto, vai o git.exe forjado. A vítima abre no Cursor só para inspecionar o código antes de rodar qualquer coisa, e o binário já executou com as permissões do usuário logado.
O precedente que ajuda a entender o bug (sem ser a conclusão da história)
Quem mexe com segurança no Windows reconhece o cheiro: é parente do velho DLL hijacking, aquele padrão em que uma aplicação procura uma DLL primeiro no diretório atual e só depois nos locais confiáveis do sistema. Esse tipo de problema de ordem de busca é conhecido e catalogado há tempos pela comunidade de segurança, com orientação consolidada sobre o assunto: nunca resolva um executável a partir de uma pasta que o usuário não controla totalmente, resolva a partir de locais fixos e assinados no PATH.
Cito esse precedente não porque “é tudo a mesma coisa de sempre” (seria preguiça intelectual tratar um bug atual como mera repetição de manual antigo), mas porque ele explica por que esse tipo de erro é bem conhecido e evitável. O Cursor não inventou uma técnica nova de ataque. Ele deixou passar, numa ferramenta vendida como editor de ponta com IA embutida, uma regra de resolução de caminho que a indústria sabe escrever corretamente há anos. A novidade aqui não está na técnica, está em onde ela apareceu.
Teste rápido para saber se a sua instalação está exposta
Antes de confiar cegamente no changelog oficial, que às vezes só diz “correções de segurança diversas” sem detalhar nada, dá para fazer uma checagem manual.
Primeiro, confira a versão instalada em Help > About e compare com o histórico de releases e com a cobertura mais recente do caso, procurando a última versão listada como vulnerável. Depois, se quiser confirmar na prática, monte o teste em ambiente descartável: crie uma pasta de teste, coloque um executável inofensivo renomeado para git.exe na raiz (algo que só abra uma calculadora ou grave um log em texto) e abra essa pasta no Cursor dentro de uma máquina virtual, nunca na máquina principal. Rode o Process Monitor do Sysinternals em paralelo para ver exatamente qual git.exe foi chamado e de onde veio.
Se não tiver tempo nem ambiente para montar isso, trate a mitigação abaixo como obrigatória até confirmar o patch, porque instalação desatualizada provavelmente segue exposta.
Como reduzir o risco sem parar de clonar repositório de estranho
Dá para trabalhar com bem menos exposição sem travar a rotina. Isole a primeira abertura de qualquer repositório desconhecido (PR de candidato, fork de issue, template baixado do GitHub) numa VM descartável ou contêiner, nunca direto no Cursor da máquina de trabalho. Antes disso, uma olhada rápida noutro editor (VS Code puro, Notepad++, ou só cat/less no terminal) já ajuda a flagrar arquivo suspeito, principalmente .exe, .bat ou .ps1 soltos na raiz do projeto sem motivo aparente. Um dir *.exe /s no Windows ou find . -iname "*.exe" no Linux expõe candidato a git.exe forjado antes de você sequer abrir a pasta.
Mantenha também o PATH do sistema bem configurado, com o Git oficial instalado em local padrão tipo C:\Program Files\Git\, o que reduz ambiguidade na resolução. E, se o Cursor permitir, desative recursos que disparam operações automáticas de Git assim que a pasta é aberta, mesmo perdendo um pouco de conveniência.
Isso tudo funciona melhor como política de time do que como escolha individual. Documenta no onboarding: repositório de candidato, fork externo, template de terceiro, tudo isso abre em ambiente isolado, sem exceção. Nenhuma dessas medidas depende do Cursor lançar patch, e valem para praticamente qualquer editor que chame binário externo por baixo dos panos.
O que isso muda na forma de avaliar segurança de editores com IA embutida
A ideia comum é que o risco de segurança num editor com IA mora no modelo: prompt injection, comando destrutivo sugerido, vazamento de dado para o provedor do LLM. Tudo isso é real e já apareceu em outros contextos. Mas esse caso aponta para outro ângulo, menos comentado: por baixo da camada de agente e chat existe um IDE tradicional, cheio de integração com Git, terminal, extensão e sistema de arquivos, carregando os mesmos riscos clássicos de qualquer software desktop, sem IA nenhuma envolvida no vetor de ataque.
Time que audita ferramenta de dev costuma revisar extensão de VS Code, plugin de terceiro, permissão de marketplace. Poucos pensam em auditar o próprio binário do editor como superfície relevante. “Editor com IA” não é uma categoria de risco isolada e nova, é software desktop convencional com todas as falhas estruturais que isso implica, mais uma camada de modelo em cima. Avaliar só a camada de cima e esquecer a de baixo é meio caminho andado para um incidente, e esse foi um lembrete de que essa camada precisa de atenção própria, não de uma auditoria de IA genérica que não olha para onde o editor realmente vai buscar os binários que executa.