Prompt injection de zero-click expõe Cursor IDE a execução remota de código

O Zero-Click é um vetor de ataque que não exige interação explícita do usuário, nem clique, nem confirmação, nem abertura intencional de arquivo. No caso do Cursor IDE, ele se materializa quando o agente de IA processa um prompt contaminado vindo de fontes aparentemente legítimas: um servidor MCP malicioso ou um resultado de busca web envenenado. O perigo está na cadeia: o LLM interpreta o input como instrução válida, aciona ferramentas de execução (como run_terminal_cmd), e essas ferramentas, por falhas de validação de parâmetros ou resolução de caminhos, ignoram os limites do sandbox. A consequência não é só uma RCE isolada: é a substituição silenciosa do binário cursorsandbox, desabilitando permanentemente o sandbox para todos os comandos subsequentes dentro da mesma sessão.

Isso não é um problema de 'prompt mal escrito', é uma falha arquitetural em como o Cursor lida com contexto externo. A primeira vulnerabilidade (CVE-2026-50548) permite que o atacante manipule o parâmetro working_directory para injetar caminhos fora do projeto e escrever diretamente no executável do sandbox. A segunda (CVE-2026-50549) explora uma falha de fallback na resolução de symlinks: quando o sistema não consegue canonicalizar um caminho (ex.: falta de permissão de leitura), ele usa o caminho original, e não o destino real, para validar se está dentro dos limites. Um symlink write-only apontando para /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox burla toda a proteção.

A cobertura CEVIU anterior já havia mapeado dois padrões recorrentes no Cursor: sandbox breakout via parser shouldB (abril/2026) e sobrescrita de .zshenv via prompt injection indireta (abril/2026). Mas as vulnerabilidades DuneSlide são mais graves porque não dependem de abertura de repositório ou de hooks, elas ativam-se com qualquer prompt que ingira conteúdo externo, mesmo sem o desenvolvedor perceber. Também é a primeira vez que o Cursor reconheceu oficialmente falhas em seu modelo de ameaça ao MCP: inicialmente rejeitou o relatório (23/fev), mas após escalonamento, incorporou correções profundas na versão 3.0 (lançada em 02/abr), incluindo restrições rígidas no uso de working_directory e revisão completa da lógica de canonicalização de symlinks.

Desenvolvedores confiam no Cursor como ambiente seguro para integração contínua com SaaS, mas DuneSlide mostra que o sandbox não é um muro, é uma porta com fechadura que pode ser enganada por lógica defeituosa. Quando um agente de IA ganha autonomia para executar comandos, cada parâmetro passado à ferramenta vira superfície de ataque. Isso força uma mudança radical: segurança não pode mais ser responsabilidade exclusiva do LLM ou do sandbox; precisa estar embutida nas camadas inferiores de execução, validação estrita de caminhos, bloqueio de escrita em diretórios críticos do aplicativo e isolamento real de binários auxiliares. Empresas que usam Cursor em pipelines CI/CD ou em ambientes regulados (como finanças ou saúde) devem priorizar atualização imediata para 3.0 e revisar políticas de uso de servidores MCP não auditados.