Você abre um repositório. Só isso. Nenhum clique, nenhum aviso, nenhuma confirmação. E pronto: código malicioso já está rodando na sua máquina com as suas permissões. Não é enredo de filme: é uma vulnerabilidade real no Cursor, o editor de código com IA mais hypado do momento, que afeta mais de 7 milhões de usuários.

E o pior? A empresa sabe do problema há mais de 7 meses. Já lançou 197 versões novas nesse período. E a falha continua lá.

O que aconteceu (e por que você deveria se preocupar)

Em dezembro de 2025, pesquisadores da Mindgard, uma empresa britânica de segurança em IA, descobriram algo perturbador. No Windows, quando você abre um projeto no Cursor, o editor procura o binário do Git em vários lugares, incluindo a raiz do próprio repositório. Se encontrar um git.exe ali, executa sem perguntar nada.

Leia de novo: executa sem perguntar nada.

O ataque é ridiculamente simples. Um atacante coloca um git.exe malicioso dentro de um repositório aparentemente legítimo. Você clona, abre no Cursor, e acabou. O editor roda comandos como git rev-parse --show-toplevel usando aquele binário plantado. E não é uma vez só: o Cursor executa o binário repetidamente enquanto o projeto estiver aberto.

Para demonstrar, os pesquisadores renomearam a Calculadora do Windows como git.exe e colocaram na raiz de um projeto. Resultado: várias instâncias da calculadora apareceram sozinhas assim que o Cursor abriu o repositório.

# O que o Cursor faz internamente (simplificado)
# 1. Abre o projeto
# 2. Procura git em vários paths, incluindo ./
# 3. Encontra ./git.exe no repo
# 4. Executa: ./git.exe rev-parse --show-toplevel
# 5. Repete periodicamente enquanto o projeto está aberto

Agora troque a calculadora por um ransomware, um keylogger ou um stealer de credenciais. A superfície de ataque é enorme.

A resposta do Cursor (ou a falta dela)

A Mindgard reportou a falha em 15 de dezembro de 2025, pelo email security-reports@cursor.com. O que aconteceu depois é um estudo de caso de como não lidar com um vulnerability disclosure.

Sete meses. Quase 200 releases. Zero correção. Zero comunicação.

O mais irônico? O Cursor é o editor que devs escolhem justamente por ser moderno e “developer-first”. Mas quando um pesquisador de segurança reporta uma falha crítica, a resposta é… silêncio?

Não foi só essa: DuneSlide e o CVSS 9.8

Se a história parasse por aí já seria ruim o bastante. Mas não para.

Em julho de 2026, o Cato AI Labs divulgou duas falhas ainda mais graves, batizadas de DuneSlide: CVE-2026-50548 e CVE-2026-50549. Score CVSS? 9.8 de 10. Praticamente o máximo.

Essas vulnerabilidades permitem execução remota de código via prompt injection, sem nenhum clique do usuário. O conceito é assustador: um atacante planta instruções maliciosas em fontes de dados que o agente de IA do Cursor lê automaticamente (como servidores MCP ou resultados de busca na web). O agente processa essas instruções e escapa do sandbox.

CVE-2026-50548: Abuso do diretório de trabalho

O Cursor tem uma ferramenta chamada run_terminal_cmd com um parâmetro working_directory. O sandbox permite escritas dentro da pasta de trabalho do comando. O problema: quando o agente define esse parâmetro para um caminho diferente, o Cursor adiciona esse caminho à lista de permissões sem questionar.

O ataque explora isso para redirecionar escritas para arquivos do sistema, sobrescrevendo o próprio helper do sandbox. No macOS, o caminho é:

/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox

Sobrescreve o sandbox, desativa a proteção. Próximo comando roda com suas permissões completas.

CVE-2026-50549: Bypass via symlink

Antes de escrever arquivos, o Cursor resolve links simbólicos para verificar se o destino está dentro do projeto. A falha: quando essa verificação falha (porque o alvo não existe ou o atacante removeu permissão de leitura de uma pasta no caminho), o Cursor desiste da verificação e confia no caminho aparente do symlink.

# Pseudocódigo do bypass
# 1. Atacante cria symlink: ./safe_file -> /path/to/cursorsandbox
# 2. Remove permissão de leitura no path intermediário
# 3. Cursor tenta resolver: FALHA
# 4. Cursor assume que ./safe_file é seguro (está "dentro" do projeto)
# 5. Escrita vai direto pro sandbox helper
# 6. Sandbox desativado

O resultado de ambas as falhas é o mesmo: o próximo comando roda como você. Isso significa controle total da máquina do desenvolvedor, mais qualquer workspace cloud ou SaaS que o editor tenha acesso.

A boa notícia: essas duas foram corrigidas no Cursor 3.0, lançado em 2 de abril. A má notícia: se você está em qualquer versão anterior, está vulnerável. E muita gente não atualiza.

CVE-2026-26268: Git hooks como vetor de ataque

Tem mais. O CVE-2026-26268, descoberto pelo pesquisador da Novee, explora uma interação entre o Cursor e os Git hooks. O mecanismo é parecido com o da Mindgard, mas usa uma abordagem diferente: em vez de plantar um git.exe falso, o atacante embute um bare repository dentro de um repositório legítimo com hooks maliciosos (como pre-commit).

Quando o agente de IA do Cursor executa operações Git automaticamente dentro desse repositório, os hooks são disparados. O detalhe crucial: o agente de IA faz operações Git autonomamente, sem pedir permissão. Ele commita, faz checkout, executa merges. E cada uma dessas operações pode disparar um hook malicioso.

Esse é o problema fundamental dos editores com IA: o agente tem acesso ao terminal e executa comandos por conta própria. A superfície de ataque não é mais só “o que o dev clica”, é “tudo que a IA decide fazer sozinha”.

O padrão que preocupa

Três falhas críticas. Duas descobertas de forma independente por equipes diferentes. Todas exploram a mesma fraqueza fundamental: o Cursor confia demais no conteúdo dos repositórios.

Esse é um problema que vai além do Cursor. Qualquer IDE com agentes de IA que executam comandos automaticamente tem essa superfície de ataque. O VS Code com Copilot, o Windsurf, o Zed com assistente. A diferença é que o Cursor, por ser o mais agressivo na execução autônoma de comandos, fica mais exposto.

E não é como se o Cursor fosse uma ferramenta de nicho. Estamos falando de mais de 7 milhões de usuários ativos, sendo mais de 1 milhão diários e mais de 1 milhão pagantes. É o editor de código com IA mais popular do mercado. Quando uma ferramenta desse tamanho tem falhas de segurança críticas, o impacto potencial é massivo.

Pensa no cenário de supply chain attack: um atacante contribui com um PR aparentemente legítimo para um projeto open source popular. O código parece limpo, passa no code review. Mas no repositório tem um git.exe escondido ou um bare repo com hooks maliciosos. Todo dev que clonar e abrir no Cursor está comprometido. É um vetor de propagação viral.

Como se proteger agora

Se você usa Cursor no dia a dia (e muita gente usa), algumas medidas práticas:

1. Atualize para o Cursor 3.0 ou superior

Isso corrige as falhas DuneSlide. Verifique sua versão em Help > About. Se estiver abaixo de 3.0, atualize imediatamente.

2. No Windows: configure AppLocker ou Windows App Control

Crie políticas que neguem execução a partir de diretórios de workspace. Uma regra como essa já resolve bastante:

# Exemplo de regra AppLocker (PowerShell)
# Nega execução de qualquer .exe dentro de pastas de projeto
New-AppLockerPolicy -RuleType Path `
  -Path "%USERPROFILE%\source\repos\*\*.exe" `
  -Action Deny `
  -User Everyone

3. Abra repos desconhecidos em ambientes isolados

Use Windows Sandbox, uma VM, ou containers descartáveis para inspecionar repositórios de fontes não confiáveis antes de abrir no seu ambiente principal.

4. Revise as permissões do agente de IA

No Cursor, verifique as configurações de quais ações o agente pode executar automaticamente. Desabilite execução automática de comandos de terminal se possível. O modo “ask before running” adiciona um passo extra, mas esse passo pode ser a diferença entre um sistema seguro e um comprometido.

5. Cuidado com servidores MCP de terceiros

As falhas DuneSlide exploram dados vindos de servidores MCP. Só conecte a servidores MCP que você confia. Revise a lista em Settings > MCP. Se você não sabe de onde veio um servidor MCP na sua config, remova primeiro e investigue depois.

6. Inspecione repositórios antes de abrir

Antes de abrir um repo desconhecido, faça uma verificação rápida:

# Checar se existe algum executável na raiz do repo
find . -maxdepth 1 -name "*.exe" -o -name "*.bat" -o -name "*.cmd"

# Checar se existem git hooks customizados
ls -la .git/hooks/ | grep -v ".sample"

# Checar bare repos embutidos
find . -name "HEAD" -path "*/.git/*" | head -20

Se encontrar algo suspeito, não abra no Cursor (ou em qualquer editor com IA).

O elefante na sala: IA + IDE = superfície de ataque nova

Eu acompanho segurança em ferramentas de desenvolvimento há um bom tempo, e o que está acontecendo com os editores de código com IA é uma mudança de paradigma na superfície de ataque.

Antes, um editor de texto era relativamente passivo. Você abria um arquivo, editava, salvava. O máximo de risco era uma extensão maliciosa do marketplace, e mesmo isso era raro. Agora, o editor tem um agente que lê seus arquivos, executa comandos no terminal, faz requests HTTP, interage com APIs externas, instala dependências e até faz deploy. Tudo automaticamente, tudo com as suas credenciais.

O modelo de ameaça mudou completamente. O VS Code Extensions marketplace já teve problemas com extensões maliciosas, mas o dano era limitado: a extensão precisava de permissões específicas e o usuário podia revogar. Com agentes de IA, o “agente” tem acesso a basicamente tudo que você tem. Suas chaves SSH, seus tokens de API, suas credenciais de cloud. Se o sandbox falha (como nas falhas DuneSlide), é game over.

Isso cria um vetor de ataque completamente novo: prompt injection como execução remota de código. O atacante não precisa mais encontrar um buffer overflow ou uma falha de memória. Basta plantar instruções no lugar certo (um arquivo .md, um comentário de código, uma resposta de API) e esperar que a IA obedeça.

A pergunta que todo dev deveria fazer: “eu confiaria em um estagiário com acesso root ao meu sistema para abrir qualquer repo da internet sem supervisão?” Porque é basicamente isso que um agente de IA sem sandbox adequado faz.

O que esperar daqui pra frente

A Mindgard fez full disclosure em junho porque não teve outra opção. Sete meses sem resposta não deixa muita alternativa. Isso vai pressionar o Cursor a agir, mas levanta uma questão maior: como a indústria de ferramentas de IA lida com segurança?

Estamos num momento em que a corrida por features está muito à frente da preocupação com segurança. Cada novo release traz mais “agentic capabilities”, mais autonomia para a IA. E a segurança? Fica para a próxima sprint. Sempre a próxima sprint.

Se você é dev e usa qualquer editor com IA, mantenha a paranoia saudável. Atualize sempre. Não abra repos aleatórios no seu ambiente principal. E lembre que o agente de IA no seu editor é, no fim das contas, um programa executando comandos com as suas permissões.

Trate ele com o mesmo cuidado que você trataria qualquer outro software com acesso ao seu sistema.

Fonte de inspiração: Cursor 0day: When Full Disclosure Becomes the Only Protection Left (Mindgard)