DuneSlide: duas CVEs criticas no Cursor abrem RCE zero-click via prompt injection em CI e MCP servers

Duas vulnerabilidades criticas no Cursor, um dos editores de codigo com IA mais populares entre desenvolvedores, permitem execuçao remota de codigo no sistema operacional a partir de simples prompt injections. Batizadas de DuneSlide pela Cato Networks e rastreadas como CVE-2026-50548 e CVE-2026-50549 (CVSS 9.8), as falhas exploram a execuçao automatica de comandos no terminal integrado do IDE – sem qualquer confirmaçao do usuario. Basta abrir uma issue, um pull request ou qualquer conteudo controlado pelo atacante para o agente cair na armadilha.

O que aconteceu

A Cato Networks divulgou nesta semana a analise de duas vulnerabilidades que quebram o modelo de sandbox do Cursor, permitindo que atacantes escapem do isolamento do IDE e executem código arbitrário no sistema operacional da vitima. As duas falhas foram batizadas em conjunto de DuneSlide e receberam CVEs no inicio de junho.

A primeira, CVE-2026-50548, atinge a fronteira de seguranca do sandbox. O Cursor implementa uma política que restringe execuçao de comandos ao working directory atual do projeto. Mas ao receber um valor não padrão para o parâmetro working_directory – algo que um MCP server malicioso pode injetar via prompt – o caminho e adicionado indevidamente a allow list. Um atacante consegue, então, sobrescrever o executavel cursorsandbox, garantindo que comandos futuros rodem sem restriçao. A partir desse ponto, o próprio agente vira o veiculo para RCE fora do sandbox.

A segunda, CVE-2026-50549, e independente da primeira. Ela vive na logica de resoluçao de caminhos de arquivo do IDE. Ao criar um link simbolico dentro do diretorio do projeto apontando para um arquivo externo, um atacante consegue enganar a canonicalizaçao de path do agente, que passa a considerar o alvo como sendo interno ao projeto. Resultado: o mecanismo de out-of-bounds write protection e contornado e o agente escreve fora da área permitida, abrindo caminho para persistência e escalonamento.

Por que e zero-click e quem esta em risco

O detalhe critico do DuneSlide e que ele não exige interaçao do desenvolvedor. Uma vez que o Cursor esteja configurado para ingerir contexto externo – via MCP servers, integracoes com repositorios, issues ou pull requests – basta que uma dessas fontes contenha o prompt injection para que o ataque dispare automaticamente. O terminal do Cursor, por padrao, executa comandos sem pedir aprovacao ao usuario. E ai que o atacante ganha shell.

As vulnerabilidades DuneSlide permitem ataques de prompt injection zero-click que escapam do sandbox do Cursor e executam codigo arbitrario no sistema operacional subjacente.

Cato Networks

Como o Cursor e o segundo IDE mais popular em pesquisas de desenvolvedores em 2026, com base instalada estimada em milhoes de máquinas, o escopo do risco e amplo. Desenvolvedores que aceitam PRs de terceiros, times que trabalham em open source, engenheiros freelancers que abrem projetos de clientes desconhecidos – todos entram no perfil de vitima. Ambientes corporativos que ja adotaram Cursor internamente ficam em posicao ainda mais delicada porque o comprometimento pode servir de pivo para lateralizacao na rede de desenvolvimento.

Quem esta afetado

• Desenvolvedores usando Cursor com integracoes MCP habilitadas em versoes anteriores ao patch de junho.
• Times DevOps e SRE que rodam Cursor em maquinas com acesso privilegiado a clusters, cofres de segredos ou pipelines de CI.
• Empresas com politica de BYOD para engenharia que permitem instalaçao livre do IDE.
• Mantenedores de projetos open source que abrem PRs de contribuidores externos com Cursor.
• Consultores e freelancers que alternam entre repositórios de multiplos clientes.

Analise: o novo perimetro chama-se prompt

DuneSlide nao e um bug isolado. E um sintoma de uma classe inteira de vulnerabilidades que vai dominar 2026 e 2027: falhas em agentes de IA que confiam demais em conteudo externo. A logica dos assistentes de codigo modernos parte do principio de que qualquer texto ingerido pelo modelo e informacao, nao instruçao. Na pratica, no entanto, todo prompt injection e uma tentativa de reprogramar o agente em tempo real.

A Cato ja havia divulgado, semanas antes, o trabalho relacionado sobre truques antigos de Bash exploraveis contra agentes de codificacao (ataques de supply chain via aliases e globbing). Somando os dois relatorios, fica claro que o sandbox do Cursor foi projetado para um mundo em que o desenvolvedor era o unico input trusted. Esse mundo acabou. MCP servers, agents chain-of-thought e integracoes automatizadas quebraram a fronteira de confianca.

Do lado positivo, o Cursor patchou as duas CVEs antes da divulgaçao publica e o processo de disclosure foi coordenado. O ponto de atençao permanente e outro: enquanto fornecedores de IDEs com IA continuarem executando comandos por padrao sem confirmaçao explicita do usuario, a proxima DuneSlide e questao de tempo.

Recomendacoes praticas

• Atualizar imediatamente para a ultima versao do Cursor lançada apos junho de 2026, que corrige CVE-2026-50548 e CVE-2026-50549.
• Desabilitar auto-run de comandos de terminal no Cursor e exigir aprovacao explicita para toda execucao gerada pelo agente.
• Revisar quais MCP servers estao conectados; remover os que nao sao estritamente necessarios para o fluxo de trabalho.
• Restringir capacidades de escrita do Cursor por diretorio via allowlist explicita, evitando reliance no working_directory default.
• Isolar Cursor em ambientes com acesso privilegiado: use máquinas de desenvolvimento sem credenciais de produçao carregadas.
• Auditar logs de execuçao do agente em busca de comandos triggerados por prompt injection nas ultimas semanas.
• Politica de PR: não executar automaticamente o Cursor sobre PRs de contribuidores externos sem sandboxing adicional (containers descartaveis, ambientes ephemeral).

Fonte: SecurityWeek