Zero-day do Cursor: por que a divulgação completa se tornou a única proteção restante

• O Cursor para Windows executa automaticamente o git.exe na raiz do workspace ao abrir um projeto, de modo que apenas abrir um repositório contendo um binário malicioso pode resultar em execução de código arbitrário sem interação do usuário
• O escopo de busca do caminho do Git inclui o interior do repositório e executa o arquivo sem aviso ou aprovação; além disso, enquanto o projeto permanece aberto, ele é reexecutado periodicamente
• A Mindgard reportou o problema em 15 de dezembro de 2025 e concluiu a reprodução e o encaminhamento via HackerOne, mas, mesmo após mais de 6 meses e mais de 197 novas versões, o problema ainda permanecia na versão de teste mais recente
• Ambientes Windows gerenciados devem aplicar regras de negação baseadas em caminho no AppLocker ou no Windows App Control, e usuários comuns devem abrir repositórios não confiáveis em uma VM ou no Windows Sandbox até que haja correção
• A Mindgard concluiu que o processo de divulgação coordenada não conseguiria reduzir o risco para os usuários e publicou todos os detalhes; ao escolher ferramentas de desenvolvimento com IA, a capacidade de resposta e comunicação em segurança do fornecedor também deve ser usada como critério de confiança

---

git.exe executado apenas ao abrir um repositório

• Ao carregar um projeto, o Cursor procura o binário do Git em vários locais, e o alvo da busca também inclui o workspace atual
• Se um invasor colocar um git.exe malicioso na raiz do repositório, o Cursor o executa automaticamente, sem aviso, caixa de diálogo de aprovação ou clique adicional
• O ataque começa apenas quando o desenvolvedor abre esse projeto; não são necessários prompt injection, manipulação de modelo, jailbreak, corrupção de memória nem cadeias complexas de exploit
• O código executado roda dentro do escopo de privilégios do usuário atual do Cursor

Processo de reprodução e registro de execução repetida

• Para uma prova de conceito segura, a Mindgard renomeou a Calculadora do Windows para git.exe e a colocou na raiz do repositório
• Ao abrir o repositório no Cursor, a Calculadora foi executada; quando o projeto permaneceu aberto, várias janelas adicionais apareceram
  • Não foi o pesquisador que abriu várias janelas manualmente
  • Não foi um comportamento único de inicialização, mas o resultado de uma reexecução periódica do executável no workspace durante o uso normal
• Em um ataque real, em vez da Calculadora, poderia ser colocado código controlado pelo invasor
• Registros do Sysinternals Process Monitor mostram o Cursor.exe executando o git.exe dentro do repositório e passando o seguinte comando

git rev-parse --show-toplevel

• A última verificação foi feita em 30 de abril de 2026, no Cursor 3.2.16 para Windows

Vulnerabilidade que permaneceu em uma grande base de usuários

• O Cursor é um ambiente de desenvolvimento assistido por IA usado na seguinte escala
  • Mais de 7 milhões de usuários ativos
  • Mais de 1 milhão de usuários diários
  • Mais de 1 milhão de usuários pagantes
  • Mais de 50 mil empresas usuárias
• O valor de mercado reportado é de US$ 60 bilhões
• A Mindgard descobriu a vulnerabilidade em 15 de dezembro de 2025 e a reportou no mesmo dia
• Pelo critério da abertura do texto, mesmo após mais de 6 meses e mais de 197 novas versões, a vulnerabilidade ainda permanecia na versão de teste mais recente
• O corpo do texto que trata do andamento da resposta registra que, enquanto novos recursos e anúncios continuavam, mais de 70 versões foram lançadas, mas o problema foi mantido
• Uma vulnerabilidade de execução de código arbitrário simples e fácil de reproduzir permaneceu sem correção por meses, afetando tanto indivíduos quanto organizações que implantaram o Cursor

Medidas temporárias aplicáveis antes do patch

• Em sistemas Windows gerenciados, é possível bloquear esse nome de executável nos diretórios de workspace de desenvolvimento usando políticas do AppLocker ou do Windows App Control
• Como o hash pode mudar para cada binário, regras de negação baseadas em caminho, limitadas à raiz do repositório/workspace, são mais adequadas do que listas de bloqueio baseadas em hash

%USERPROFILE%\source\repos\*\filename.exe

• O Windows não possui uma regra nativa geral que bloqueie executáveis filhos arbitrários apenas quando executados por um processo pai específico
  • Controles que reconhecem o processo pai exigem EDR ou produtos personalizados de segurança de endpoint
• Usuários comuns devem abrir repositórios não confiáveis apenas em uma VM isolada, no Windows Sandbox ou em um ambiente descartável até que a IDE seja corrigida
• Como o hash pode mudar sempre que o binário for alterado, não se deve confiar em listas de bloqueio por hash de arquivo para esta vulnerabilidade

Processo de coordenação que parou após o reporte

• O primeiro reporte foi enviado ao e-mail de segurança indicado no security.txt do Cursor, mas não houve confirmação de recebimento
• A Mindgard tentou encontrar a pessoa responsável por segurança por meio de e-mails de acompanhamento e de um pedido público de contato
• O CISO do Cursor respondeu que uma falha de automação interna impediu o início do processo previsto no HackerOne e convidou manualmente a Mindgard para o programa privado de bug bounty
• O relatório reenviado pelo HackerOne foi inicialmente encerrado como Informative e fora de escopo
  • A Mindgard contestou essa decisão
  • Depois que o HackerOne reproduziu o problema, o relatório foi reaberto, e foi confirmado que os detalhes haviam sido encaminhados ao Cursor
• Depois disso, pedidos de atualização, escalonamentos via HackerOne e contatos diretos com o CISO e a liderança do Cursor não receberam respostas significativas
• A Mindgard não recebeu evidências de que uma correção tivesse sido iniciada, de que a equipe de engenharia estivesse investigando ou de que o risco tivesse sido comunicado aos usuários afetados

Linha do tempo do reporte até a divulgação completa

• 15 de dezembro de 2025

  • A Mindgard descobriu a vulnerabilidade
  • Reportou para [e-mail]

• 18 de dezembro de 2025

  • Enviou um contato de acompanhamento pedindo confirmação de recebimento

• 13 de janeiro de 2026

  • Publicou no LinkedIn para encontrar um contato no Cursor
  • Nos comentários, um usuário indicou o CISO do Cursor

• 15 de janeiro de 2026

  • O CISO do Cursor informou uma falha na automação do convite ao bounty privado no HackerOne e fez o convite manualmente
  • A Mindgard submeteu a vulnerabilidade via HackerOne

• 16 de janeiro de 2026

  • O relatório foi encerrado como Informative e fora de escopo
  • A Mindgard contestou a decisão
  • Após reprodução bem-sucedida, o relatório foi reaberto

• 20 de janeiro de 2026

  • O HackerOne confirmou que havia encaminhado o relatório ao Cursor

• 16 de fevereiro e 3 de março de 2026

  • A Mindgard pediu atualizações, mas não recebeu resposta

• 17 de março de 2026

  • Pediu atualização diretamente ao CISO do Cursor

• 18 de março de 2026

  • O HackerOne informou que havia contatado o Cursor

• 1º de abril de 2026

  • A Mindgard voltou a pedir atualização, mas não recebeu resposta
  • O HackerOne também confirmou que não havia atualização do Cursor

• 1º de junho de 2026

  • A Mindgard informou ao HackerOne a intenção de divulgar

• 3 de junho de 2026

  • O HackerOne forneceu orientações de divulgação

• 14 de julho de 2026

  • Publicou o post com os detalhes da vulnerabilidade

Por que a divulgação coordenada não levou à proteção dos usuários

• Uma divulgação coordenada típica segue a sequência de reporte, conversa, discussão de severidade, investigação de engenharia, desenvolvimento de correção, proteção dos usuários e divulgação
• Esse processo funciona quando todos os participantes compartilham o objetivo de reduzir o risco
• Neste caso, durante 7 meses não houve participação significativa do fornecedor, e o processo não avançou até a etapa de redução de risco
• Plataformas grandes e que mudam rapidamente podem levar tempo para corrigir problemas, mas é difícil continuar esperando quando não há comunicação, atualizações ou progresso visível por meses
• Restaram apenas duas opções ao pesquisador
  • Manter o silêncio, permitindo que usuários continuassem trabalhando sob a falsa premissa de que estavam seguros
  • Divulgar para que organizações pudessem entender o risco e decidir como responder
• A Mindgard escolheu a divulgação completa, usada quando todos os outros caminhos falham

Perguntas deixadas pelos programas de bug bounty e pela resposta de segurança em IA

• Sobre a causa do atraso na resolução, são levantadas as seguintes possibilidades
  • Se programas modernos de bug bounty estão sobrecarregados
  • Se modelos mais capazes, como o Mythos, tornaram o volume de reportes difícil de administrar
  • Se o Cursor reduziu a prioridade da segurança dos usuários enquanto se concentrava na aquisição da SpaceX
  • Se, em um cenário envolvendo bilhões de dólares, a segurança dos usuários é de fato uma preocupação
• A disseminação de produtos de IA está aumentando muito o número de descobertas de segurança, e muitas delas não se encaixam claramente nas classificações tradicionais de vulnerabilidades
• Os processos de classificação e triagem dos quais a indústria dependeu por cerca de 20 anos estão falhando rapidamente no ambiente de IA, à medida que suas premissas de base são abaladas
• Se o pipeline de divulgação está sobrecarregado, o setor deve comunicar isso com transparência para que pesquisadores, clientes e usuários possam avaliar a situação
• Empresas em hipercrecimento devem resolver falhas de segurança e, ao mesmo tempo, tratar os usuários como clientes valiosos, não como sujeitos de experimentos de compra

Condições para confiar em ferramentas de desenvolvimento com IA

• Empresas de IA pedem acesso sem precedentes a código, repositórios, terminal, segredos e fluxos de trabalho, e a fronteira entre sugestão e execução também está ficando cada vez mais difusa
• Usuários estão confiando a software em produção seu código-fonte, credenciais, propriedade intelectual proprietária e funcionalidades cada vez mais autônomas
• Não se deve confiar em um sistema apenas porque ele aumenta a produtividade; a confiança precisa ser conquistada pela resposta a reportes de segurança, pela comunicação com usuários afetados e pela priorização de correções
• Confiança exige responsabilidade, e responsabilidade exige comunicação, mas é difícil verificar essa responsabilidade quando usuários, pesquisadores e plataformas públicas ficam meses sem sequer atualizações básicas de status
• A Mindgard publicou todos os detalhes para dar às organizações a oportunidade de avaliar a exposição, aplicar controles compensatórios e julgar a postura de segurança
• Quando continuar escondendo informações passa a proteger o silêncio, não os usuários, é preciso priorizar a segurança dos usuários, ainda que isso seja desconfortável

[GN⁺]

Opiniões do Hacker News

• Do ponto de vista de quem recebe relatórios de segurança, há uma enxurrada difícil de suportar de relatórios de baixa qualidade gerados por LLMs, geralmente sem entender o design do produto ou o escopo de segurança. De vez em quando também há relatórios muito bons, então é preciso verificar todos manualmente, mas enviar ainda mais “justificativas” prolixas criadas por LLM não é solução; este texto também parece ter sido escrito em grande parte por LLM
  Neste caso, se a situação é a de colocar um binário malicioso em um ambiente onde o software pode executar código ou binários arbitrários, então, a menos que o Cursor diga que também se responsabiliza pela segurança do ambiente do usuário, isso parece estar mais próximo da responsabilidade de quem isola e protege o workspace
  Ao criar relatórios de CVE com LLMs, espero que elas sejam usadas no processo decisivo de reprodução, enquanto o texto seja escrito diretamente e de forma concisa, removendo os adjetivos desnecessários e os exageros típicos de LLM

  • Um binário não deveria ser executado automaticamente dentro de um repositório recém-clonado só porque ele foi aberto no Cursor
  • A variável PATH existe justamente para controlar esse tipo de problema. Se entendi corretamente, o Cursor adiciona imediatamente o repositório ao PATH sem aprovação do usuário
  • Não há solução fácil; se segurança é prioridade, é preciso alocar mais pessoas para revisão de acordo com o novo ambiente. Acrescentar mais uma etapa de verificação por LLM não resolve

• A raiz do problema está no fato de o Cursor não tratar a clonagem de repositório e a execução de código como fronteiras de segurança distintas. Por padrão, o Cursor desativa o Workspace Trust[0], e só de abrir um repositório que contenha "runOn": "folderOpen" em .vscode/tasks.json, código arbitrário já é executado[1]
  [0] https://cursor.com/docs/agent/security#workspace-trust
  [1] https://www.oasis.security/blog/cursor-security-flaw

• A Mindgard diz que descobriu a vulnerabilidade pela primeira vez em 15 de dezembro de 2025 e a reportou no mesmo dia e várias outras vezes depois, mas que ela ainda permanece na versão mais recente do Cursor mesmo após 6 meses e mais de 197 novas versões
  No início, o relatório foi encerrado como informativo/fora de escopo; depois de uma contestação, o HackerOne o reabriu, reproduziu e encaminhou ao Cursor, mas desde então pedidos de atualização, perguntas adicionais, escalonamento via HackerOne e até contatos enviados à liderança do Cursor ficaram todos sem resposta. É difícil entender por que o Cursor está lidando com isso dessa forma

  • O próprio processo de tratamento de CVEs está quebrado. Com o avanço da IA agentiva, os programas de divulgação de vulnerabilidades de empresas e o HackerOne passaram a receber, ao mesmo tempo, um grande aumento tanto de relatórios de baixa qualidade quanto de relatórios realmente excelentes; como a mesma IA escreve ambos, é quase impossível distingui-los apenas pela aparência
    Como resultado, as empresas já não respondem como antes, e na conferência de cibersegurança de junho também havia um forte clima de que a divulgação responsável está morta ou morrendo, então seria melhor tornar tudo público. Os casos da Microsoft e do Nightmare Eclipse foram citados com frequência
  • Também vem à mente a possibilidade de ser um backdoor intencional. Se a NSA ou o FBI colocarem um git.exe em um repositório voltado a um alvo e fizerem o alvo cloná-lo, o payload pode ser executado
    Como o Cursor é baseado no VS Code, fico curioso se a mesma coisa também acontece no VS Code

• É difícil concordar totalmente que isso seja uma vulnerabilidade grave. Para explorá-la de fato, o invasor primeiro teria que colocar um executável malicioso chamado git.exe na pasta de código do usuário, o que é parecido com chamar de vulnerabilidade alterar o .bashrc para criar um alias em que ls execute /tmp/mega-big-virus.sh
  É verdade que é um caminho de ataque, mas, se esse arquivo já entrou no sistema de arquivos, dá para considerar que houve uma comprometimento prévio

  • Basta clonar um repositório do GitHub e abri-lo no Cursor, o editor padrão, para ser infectado. É como inserir um CD e o autorun.exe ser executado, infectando o Windows
    Pode-se dizer que o usuário deveria examinar manualmente, em um ambiente isolado, todos os arquivos do repositório e binários suspeitos como git.exe, mas, na prática, quem controla isso não é o usuário, e sim uma política de segurança que impede execução automática; o Cursor também deveria desativar isso da mesma forma
  • Diferentemente do .bashrc, pastas de código são frequentemente obtidas de fontes não confiáveis. Abrir um projeto do GitHub para analisá-lo não deveria permitir também execução arbitrária de código
    Dito isso, nos principais IDEs essa fronteira já foi rompida há muito tempo, e os recursos remotos de SSH e devcontainer do VS Code também permitem execução remota de código por design
  • Desde o primeiro parágrafo da página, o texto afirma claramente em duas frases que, depois que o Cursor abre um projeto, ele procura o binário do Git em vários locais, incluindo o workspace atual, e que, se um git.exe malicioso for colocado na raiz do repositório, ele é executado sem entrada ou confirmação do usuário. Não é um texto que esconde o comportamento central
  • Só de clonar um repositório e abri-lo no IDE, você acaba dando ao dono do repositório permissão de execução remota de código, e é difícil ver isso como um contrato implicitamente incluído no ato de abrir uma pasta
  • Mesmo 30 anos atrás, já havia ataques de ordem de busca de DLL em que uma DLL substituta infectada era colocada em uma pasta de MP3s ou fotos para ser carregada pelo Winamp ou pelo Visualizador de Fotos do Windows; este caso é muito parecido

• É estranho o Cursor executar arquivos arbitrários sem confirmação, e também é preocupante que os pesquisadores não tenham recebido uma resposta adequada durante meses
  Ainda assim, o exemplo de abrir a calculadora pode ser um pouco enganoso. Entendo que o executável malicioso precisa já ter sido baixado no sistema e, quando o Cursor tentar executá-lo, o ACL entraria em ação e pediria permissão para executar pela primeira vez um novo app não assinado. Para exploração real, talvez o ACL precise estar completamente desativado

  • Se a janela de confirmação disser “Deseja executar git.exe?”, há uma boa chance de a pessoa achar que o Cursor precisa do Git e que há algum problema na configuração de permissões, e simplesmente aprovar
  • O mesmo pode acontecer se você usa um PS1 que mostra o branch atual do Git e inclui o diretório atual no PATH. Nesse caso, fica a dúvida se também seria preciso enviar um CVE de alto risco contra o Bash

• Parece estar relacionado não tanto a um bug exclusivo do Cursor, mas à ordem de busca específica do Windows, em que o Windows procura executáveis no diretório de trabalho atual antes de consultar o PATH. É bem provável que vários programas no Windows estejam expostos a ataques semelhantes

  • Softwares que levam segurança a sério já corrigiram esse problema
    Como explicado em https://go.dev/blog/path-security, Command e LookPath procuram programas nos diretórios listados no PATH atual seguindo as convenções do sistema operacional, mas hoje o comportamento de incluir o diretório atual costuma ser inesperado e pode levar a problemas de segurança
    https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
  • Isso pode ser mitigado facilmente procurando o executável real do Git em caminhos conhecidos do sistema ou permitindo que o usuário configure o caminho; pelo que sei, o VS Code também trata isso dessa forma
  • É uma armadilha de segurança antiga e bem conhecida contra a qual é obrigatório se defender ao desenvolver software para Windows
  • Então, no fim das contas, isso soa como um bug e uma vulnerabilidade na versão do Cursor para Windows

• É comum demais, e lamentável mas até compreensível, que empresas não priorizem segurança. Também é compreensível que uma startup de segurança, cansada de esperar, torne o caso público para recuperar ao menos parte do custo investido em forma de divulgação, e há momentos em que a divulgação pública de vulnerabilidades é necessária
  Ainda assim, se realmente quisessem ajudar a resolver o problema, parece que poderiam ter feito mais do que insistir no HackerOne e enviar uma mensagem no LinkedIn ao CISO. Agora fica uma sensação amarga, como se ninguém realmente se importasse de verdade

  • Não está claro o que seria ajudar de verdade a resolver o problema, nem quais seriam exatamente os custos irrecuperáveis mencionados aqui. No geral, soa vago demais

• Fico curioso por que o Cursor executa automaticamente arquivos executáveis e em qual fluxo de decisão esse comportamento surgiu. O Vim também teve problemas de executar código inesperado ao carregar arquivos por causa de recursos explícitos como %{expr}, mas é difícil entender por que o Cursor procura especificamente por git.exe e para quem essa funcionalidade ajuda
  Mesmo sem nunca ter usado o Cursor, dá curiosidade saber por que existe um CVE duplicado que parece simples de corrigir

  • Um fluxo comum é pedir ao Cursor para resumir um repositório existente e escrever um README; depois de ler o repositório e o código, o Cursor executa comandos Git para também fornecer metadados como a branch de desenvolvimento ou tags anteriores
    O problema é que, ao pedir para ele avaliar um repositório remoto, depois de clonar o repositório e executar git ... no diretório de trabalho, o Windows pode decidir que o arquivo git naquele diretório é o alvo de execução. Código também pode ser executado imediatamente ao alternar para um repositório não confiável ou uma branch comprometida
    A solução usual é usar o caminho completo do Git instalado no sistema; embora seja trabalhoso para uma pessoa digitar, para o Cursor é algo trivial
  • Parece que a intenção é encontrar o Git real do usuário para que o agente integrado leia contexto em várias branches e worktrees. Há formas mais seguras de fazer isso, mas esse tipo de pequeno atalho é um ponto fácil de dar errado em fluxos de trabalho assistidos por IA, e também é um ponto em que alertas podem passar despercebidos na triagem de bugs com IA

• Como é comum dar a agentes de desenvolvimento permissão para buscar e enviar repositórios Git, isso se torna uma enorme rota de ataque à cadeia de suprimentos. Se um agente do Cursor em execução buscar os arquivos mais recentes e um invasor tiver inserido um executável no projeto, de repente centenas de milhares de pessoas podem executar um EXE arbitrário com permissões de usuário padrão

• O relatório parece um pouco texto escrito por IA. Para explorar, o payload malicioso já teria que estar no PC por meio de clone, download etc., então entendo a gravidade, mas espera-se, antes de tudo, não acabar em uma situação dessas

  • Agentes de codificação modernos, quando recebem perguntas sobre APIs cuja documentação não é clara, também podem clonar repositórios e ler o código; portanto, essa vulnerabilidade é de fato explorável
  • O payload malicioso pode estar em um repositório remoto. Basta dar git clone no repositório e abri-lo no Cursor para que o comprometimento esteja concluído
  • Se você é desenvolvedor open source, também pode receber um pull request contendo git.exe
  • Normalmente não se pensa que baixar um repositório e olhar o código-fonte equivale a ativar um payload malicioso, e é exatamente essa parte que preocupa. Mesmo que o estilo de IA incomode, a crítica deve ser ao conteúdo da vulnerabilidade, não à forma de escrita
  • É difícil afirmar que o payload precisa já estar no PC. Se uma injeção de prompt conseguir induzir um comando como download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;), existe a possibilidade de o agente baixar e executar git.exe