Abrir um repositório no Cursor, no Windows, e encontrar um arquivo chamado git.exe na raiz do projeto é suficiente para que ele seja executado.
Sem clique, sem caixa de aprovação, sem aviso de que algo na pasta está prestes a ser executado.
O binário roda com os privilégios do usuário, acessando o código-fonte, as chaves SSH e os tokens de nuvem.
Enquanto o projeto permanecer aberto, o Cursor continua executando o arquivo repetidamente.
Não há prompt injection, nem agent, nem model no meio do caminho, e não é preciso ter acesso prévio à máquina.
Basta abrir a pasta.
Esse é o exploit completo, com resultado de execução arbitrária de código como o usuário autenticado.
A empresa de segurança em IA Mindgard informou a falha ao Cursor em 15 de dezembro de 2025 e publicou os detalhes técnicos completos na terça-feira, sete meses depois.
Até agora, não há patch, e o Cursor também não publicou um aviso oficial sobre o caso.
O mecanismo cabe em uma frase.
Quando um projeto é carregado, o Cursor procura o binário do Git em vários locais, e um deles é o próprio workspace.
A saída do Process Monitor mostrada no relatório indica que o Cursor.exe inicia o binário na raiz do repositório com a linha de comando git rev-parse --show-toplevel.
Esse é o mesmo tipo de verificação da raiz do repositório descrita na documentação do VS Code da Microsoft.
O relatório não diz se o Cursor faz essa busca por conta própria ou se passa um git sem qualificação para o Windows e deixa a ordem de busca decidir.
A proof of concept da Mindgard foi o Windows Calculator, renomeado para git.exe, e enviado para a raiz do projeto.
Foi só clonar e abrir.
A captura de tela mostra várias janelas do Calculator surgindo sozinhas enquanto o projeto permanecia aberto.
A condição inicial parece ser a parte difícil: um binário do atacante dentro da raiz do seu projeto.
Mas não é.
Clonar o repositório de um desconhecido é justamente como binários chegam ao disco, e desenvolvedores, assim como seus agents, fazem isso o tempo todo.
O atacante não precisa de ponto de apoio para começar.
É essa a distância que a falha cobre: de um repositório que qualquer pessoa pode publicar até código sendo executado como você.
Há uma limitação na evidência.
A confirmação datada mais recente da Mindgard é de 30/04/2026, contra o Cursor 3.2.16, enquanto a versão atual é a 3.11, lançada em 10/07.
O texto diz que a falha continua presente na versão mais recente testada, mas não informa qual era essa versão.
O The Hacker News revisou os 33 avisos de segurança publicados pelo Cursor e não encontrou entrada cobrindo o caso até 15/07.
Nenhum CVE foi atribuído.
O Caveira Tech entrou em contato com o Cursor para pedir qual versão corrige o problema e com a Mindgard para informar qual foi a última versão testada.
A reportagem será atualizada se houver resposta.
O que fazer
Não há patch, então tudo abaixo é paliativo.
Em frotas gerenciadas de Windows, a Mindgard recomenda regras de negação no AppLocker ou no Windows App Control que bloqueiem o executável por nome e caminho sob raízes de workspace, no estilo de %USERPROFILE%\source\repos\*\filename.exe.
Regras por caminho, não por hash, já que os binários do atacante variam de hash.
O Windows não tem uma regra nativa geral que bloqueie um processo filho apenas quando um pai específico o inicia, observa a empresa, então a aplicação consciente do processo pai normalmente exige EDR.
Para o restante dos usuários, a recomendação é abrir repositórios não confiáveis em uma VM descartável ou no Windows Sandbox.
Combine isso com a orientação da Cymulate de inspecionar um repositório clonado ou um arquivo compactado extraído antes de abrir.
git.exe, npx.exe, node.exe e where.exe não têm motivo para estar na raiz de um projeto.
O que aconteceu com o relatório é o restante da história.
A página de segurança do Cursor diz que a empresa reconhece “relatórios de vulnerabilidade em até 5 dias úteis”.
A primeira resposta substancial à Mindgard veio um mês após o envio de dezembro, do CISO do Cursor, que explicou que uma automação falhou ao convidar a empresa para o programa privado no HackerOne.
O relatório reenviado foi encerrado no dia seguinte como informativo e fora de escopo.
Depois, foi reaberto após a contestação da Mindgard e a reprodução pelo HackerOne.
O HackerOne confirmou o recebimento em 20/01.
Depois disso, vieram pedidos de atualização em fevereiro, março e abril, sem retorno.
Lendo o histórico de avisos do Cursor à luz da linha do tempo da Mindgard, o processo funcionou para outros pesquisadores enquanto o relatório da Mindgard ficou parado.
Em 13/02/2026, o Cursor publicou o GHSA-8pcm-8jpx-hv8r, uma fuga de sandbox em hook do Git, identificada como
CVE-2026-26268
, relatada pela Novee sob divulgação coordenada e corrigida no Cursor 2.5.
Três dias depois, em 16/02, a Mindgard pediu uma atualização sobre seu próprio relatório relacionado ao Git.
Não houve resposta.
Mais dois avisos do Cursor foram publicados em 14/07, no mesmo dia em que a divulgação completa veio a público.
“A divulgação completa é a opção nuclear da divulgação de vulnerabilidades”, escreveu a Mindgard, reservando-a para casos em que todos os outros caminhos falharam.
O autor, Aaron Portnoy, passou anos do outro lado dessa equação: ele dirigiu a Zero Day Initiative e criou as seis primeiras edições do Pwn2Own.
A mesma falha, em três outros fornecedores
A Mindgard não foi a primeira empresa a encontrar isso, nem a primeira a ouvir a resposta do Cursor.
Em junho, a Cymulate publicou conclusões sobre a mesma classe de problema em ferramentas de IA: no Windows, várias delas resolvem executáveis auxiliares usando a ordem padrão de busca, que verifica o diretório de trabalho antes dos caminhos confiáveis do sistema.
O GitHub Copilot CLI executou um git.exe da workspace na inicialização, antes mesmo de aparecer o prompt de confiança da pasta.
O Gemini CLI fez o mesmo quando foi iniciado a partir da workspace.
O aplicativo desktop do Codex se comportou da mesma forma ao abrir a pasta, assim como o Cursor.
Na data da publicação da Cymulate, em 04/06, nenhum desses fornecedores havia lançado correção.
O GitHub classificou o relatório, pagou uma recompensa e depois rebaixou a gravidade para baixa.
O Google concordou que a constatação do Gemini CLI era válida, mas não lançou patch.
A OpenAI encerrou o relatório do Codex como não aplicável, argumentando que um atacante capaz de substituir git.exe já teria acesso ao sistema.
Esse não era o cenário relatado.
O Cursor encerrou o relatório da Cymulate sobre o Cursor CLI como informativo, oito dias depois, sob a alegação de que achados que exigem um binário malicioso “carecem de vetor de ataque”.
Essa pesquisa produziu uma correção, mas em outro caso.
A AWS atribuiu
CVE-2026-10591
ao achado da Kiro, creditou a Cymulate e corrigiu o problema na Kiro 0.11.
Mas era uma falha diferente: um erro de gravação de arquivo pelo agent que permitia a execução automática de um .vscode/tasks.json adulterado ao abrir a pasta.
Nenhum dos relatos sobre o plantio de binários resultou em correção.
A classe é anterior a tudo isso.
Um caminho de busca não confiável é a fraqueza; colocar um binário onde a busca vai encontrá-lo é o ataque.
O Windows verificar o diretório atual antes de %PATH% foi o que quebrou o Git Credential Manager Core em 2020, na
CVE-2020-26233
: um git.exe malicioso na raiz de um repositório era executado no lugar do verdadeiro durante um clone recursivo.
A correção veio no GCM 2.0.289.
A proof of concept da Blaze Information Security naquela época também foi o calc.exe renomeado para git.exe.
Seis anos depois, a mesma técnica volta a funcionar contra um IDE que faz a verificação por você assim que a pasta é aberta.
Quatro fornecedores já foram confrontados com um binário de workspace que se executa sozinho no Windows assim que o desenvolvedor aponta a ferramenta para um repositório clonado.
Dois concluíram que isso nem sequer era uma vulnerabilidade; dois concordaram que era, mas, até o relato da Cymulate em junho, ainda não haviam lançado correção.
A decisão, então, recai sobre os defensores.
No Windows, a postura segura é tratar um repositório clonado como conteúdo executável, porque é exatamente isso que ele passa a ser.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...