DuneSlide: una inyección de prompts escapa del sandbox de Cursor hasta el RCE

¿Qué es esto?

El 1 de julio de 2026, Cato AI Labs (el equipo de Itay Ravia, antes Aim Security) publicó DuneSlide, dos fallos críticos de ejecución remota de código en el editor de código con IA Cursor. Ambos tienen una puntuación de 9,8 (CVSS 3.1) y producen el mismo efecto: permiten que un único prompt de apariencia corriente escape del sandbox del terminal de Cursor y ejecute comandos arbitrarios en la máquina del desarrollador. No hay clic que caiga ni cuadro de aprobación que ignorar — los investigadores lo llaman ataque «zero-click».

El punto de entrada es la inyección de prompts. El atacante nunca toca su Cursor. Coloca sus instrucciones dentro de algún contenido que su agente lee en su nombre — un servicio conectado mediante el Model Context Protocol (MCP), o una página devuelta por una búsqueda web — y esas instrucciones ocultas viajan junto a su pregunta legítima. Cato reportó ambos problemas el 19 de febrero de 2026; se corrigieron en Cursor 3.0 (publicado el 2 de abril), y los identificadores de vulnerabilidad se asignaron el 5 de junio. Todas las versiones anteriores a la 3.0 están afectadas. Según el fabricante, más de la mitad de las empresas del Fortune 500 usan la herramienta.

Cómo funciona

Desde la rama 2.x, Cursor ejecuta los comandos de terminal que emite su agente dentro de un sandbox por defecto y sin solicitar aprobación — una decisión de diseño deliberada para evitar la fatiga de aprobación y, a la vez, impedir que una instrucción descarriada dañe la máquina. DuneSlide consiste en salir de esa caja. Ambos fallos siguen el mismo patrón: inducir al agente a escribir un archivo que no debería poder escribir y, con esa escritura, apagar el sandbox. Aquí no se reproduce ningún payload; el mecanismo se describe a nivel arquitectónico, conforme al análisis de Cato.

El primer fallo abusa de un parámetro de herramienta. El sandbox de Cursor concede acceso de escritura al directorio de trabajo de un comando, y ese directorio es un argumento opcional (working_directory) de la herramienta run_terminal_cmd. Cuando el agente le asigna un valor no predeterminado, Cursor añade esa ruta a la lista de escrituras permitidas sin cuestionarla. Las instrucciones inyectadas pueden dirigir al agente hacia un archivo del sistema en lugar del proyecto — por ejemplo, el propio binario del sandbox (en macOS, /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox). Una vez sobrescrito, todos los comandos posteriores se ejecutan sin sandbox alguno. Los archivos de arranque del shell como ~/.zshrc o ~/Library/LaunchAgents también sirven como objetivos.

El segundo fallo abusa de una comprobación de seguridad. Antes de escribir, Cursor resuelve los enlaces simbólicos para confirmar que el destino real está dentro del proyecto. El error está en el repliegue: cuando la canonicalización falla — porque el destino no existe, o porque el atacante retira el permiso de lectura de un directorio de la ruta — Cursor se rinde y confía en la ruta del enlace simbólico que queda dentro del proyecto. El atacante crea un enlace simbólico de solo escritura que apunta fuera del proyecto, fuerza el fallo de la comprobación y Cursor escribe directamente a través de él hasta el mismo binario del sandbox. La misma evasión, otra puerta.

La lección común: en el software clásico, un atacante remoto no puede fijar su directorio de trabajo ni plantar enlaces simbólicos en su disco. En un agente de codificación, una inyección de prompts se convierte en el pasadizo hacia exactamente esas primitivas.

Por qué importa

Una vez neutralizado el binario del sandbox, el siguiente comando se ejecuta en su nombre. Eso es el control de la máquina del desarrollador, más cualquier espacio de trabajo en la nube o SaaS al que el editor esté conectado — todo a partir de un único prompt de apariencia inofensiva. No hay indicios de explotación real; Cato presenta esto como investigación, y el registro público no refleja abuso conocido a la fecha de divulgación.

El punto de fondo es dónde reside la vulnerabilidad. La inyección es solo el mecanismo de entrega, pero los fallos reales son clásicos: confianza no verificada en un parámetro de herramienta y un repliegue defectuoso en la canonicalización de rutas. La inyección de prompts atravesó la capa del modelo para iluminar rutas de código que nadie consideraba parte de la superficie de ataque. Es además la última de una serie de evasiones del sandbox y de la configuración de Cursor (CurXecute, MCPoison y un fallo de Git-hook manipulado a principios de 2026), cada una sorteando una salvaguarda distinta. Cato afirma estar divulgando problemas similares en otros agentes de codificación y sostiene que el problema es estructural, no una sucesión de casos aislados.

Defensas

1. Actualice ya. Lleve cada instalación de Cursor a la 3.0 o superior; ambos fallos están corregidos allí y todas las versiones previas son vulnerables. Es la acción de mayor impacto.
2. Trate todo contenido que lea el agente como no confiable. Las respuestas de los conectores MCP y los resultados de búsqueda web son controlables por un atacante. El modelo de amenazas original de Cursor no cubría explícitamente el abuso de un servidor MCP estándar (ni siquiera la integración oficial de Linear) — no herede esa suposición. Restrinja qué servidores MCP puede alcanzar el agente y prefiera conectores de solo lectura o auditados.
3. Proteja los artefactos de la frontera de confianza. Un sandbox vale lo que valga la integridad del binario que lo aplica. Deje los binarios del sandbox, los archivos de configuración del agente y los de arranque del shell (~/.zshrc, ~/.zshenv, ~/Library/LaunchAgents) en solo lectura o bajo monitorización de integridad, para que una escritura fuera de límites sea detectable aunque se sortee una salvaguarda.
4. Mantenga a un humano en el bucle para las acciones irreversibles. La ejecución automática sin aprobación cambia seguridad por comodidad. Para un agente que opera sobre entradas no confiables, exija confirmación en toda escritura fuera del directorio del proyecto y en cualquier comando que toque los componentes internos de la aplicación.
5. Vigile la evasión, no solo la inyección. La telemetría de endpoint que señale escrituras en los directorios de recursos de la aplicación, nuevos LaunchAgents o cambios en los archivos rc del shell detectará la fase posterior a la inyección de esta clase de ataque, sea cual sea el prompt utilizado.
6. Asuma que el patrón se generaliza. Todo agente que lea la web abierta y pueda ejecutar comandos comparte esta exposición. Inventaríe su parque de agentes de codificación y aplique los mismos controles antes de la próxima divulgación.

Status

Elemento	Referencia	Fecha	Notas
Divulgación DuneSlide	Cato AI Labs	2026-07-01	Dos fallos RCE, CVSS 9,8 (3.1)
Fallo del directorio de trabajo	CVE-2026-50548	2026-06-05 (ID asignado)	working_directory añadido a la lista blanca sin validación
Fallo de canonicalización de enlace	CVE-2026-50549 / GHSA-3v8f-48vw-3mjx	2026-06-05 (ID asignado)	El repliegue confía en la ruta del enlace dentro del proyecto
Reporte a Cursor	Cato AI Labs	2026-02-19	Rechazado primero el 2026-02-23, reabierto tras escalada el 2026-02-26
Corrección publicada	Cursor 3.0	2026-04-02	Todas las versiones anteriores a la 3.0 afectadas
Explotación real	NVD / Cato	2026-07-01	Ninguna conocida a la fecha de publicación

El encuadre correcto no es «un editor con IA tenía un bug». Es que la inyección de prompts es ya una vía fiable para alcanzar vulnerabilidades clásicas dentro de entornos autónomos de ejecución de comandos — y corregir la capa de inyección no corrige las rutas de código a las que puede llegar. Actualice a la 3.0 y trate como hostil cada entrada que lea su agente.