Se descubrieron dos vulnerabilidades críticas en el editor de código Cursor que permiten ejecutar comandos remotos en la computadora del usuario mediante la inyección de prompts. Estos fallos, llamados DuneSlide, logran evadir el entorno seguro (sandbox) sin requerir interacción del usuario. La solución ya está disponible en la versión 3.0, por lo que se recomienda actualizar inmediatamente.



Dos fallos en Cursor, un editor de código basado en IA, podrían permitir que un solo prompt de apariencia normal rompa el sandbox de seguridad del editor y ejecute cualquier comando en el ordenador de un desarrollador. No hay ningún clic en el que caer ni ninguna casilla de aprobación que ignorar.

Cato AI Labs encontró el par de vulnerabilidades y las llamó DuneSlide. Están registradas como CVE-2026-50548 y CVE-2026-50549, ambas calificadas con 9.8 sobre 10 (o 9.3 bajo la escala más reciente CVSS 4.0).

La solución ya está disponible. Ambos errores han sido parcheados en Cursor 3.0, lanzado el 2 de abril, y todas las versiones anteriores a la 3.0 están afectadas. El creador de Cursor afirma que más de la mitad de las empresas Fortune 500 utilizan la herramienta, así que si tú la usas, actualiza ahora.

Para qué servía el sandbox y cómo se rompió

A partir de la línea 2.x, Cursor ejecuta los comandos de terminal que emite su agente de IA dentro de un sandbox por defecto: una caja cerrada que limita lo que esos comandos pueden tocar, para que una instrucción errónea no pueda destrozar la máquina.

DuneSlide consiste en salir de esa caja. La vía de entrada es la inyección de prompts. El atacante nunca escribe en tu Cursor; plantan instrucciones dentro de algo que tu agente lee en tu nombre, como un servicio conectado a través del Model Context Protocol (MCP) o una página devuelta por una búsqueda web.

Tú haces una pregunta normal, las instrucciones ocultas viajan con ella y, como no requiere ningún clic ni aprobación tuya, el ataque es de "cero clics".

Ambos fallos utilizan el mismo truco: lograr que el agente escriba un archivo que no debería poder escribir y luego usar esa escritura para desactivar el sandbox.

* CVE-2026-50548 abusa de un ajuste. El sandbox permite escrituras en la carpeta de trabajo de un comando, y esa carpeta es un parámetro opcional, working_directory, en la herramienta run_terminal_cmd de Cursor. Cuando el agente lo establece en una ruta que no es la predeterminada, Cursor añade esa ruta a la lista de escritura permitida sin cuestionarla. Las instrucciones inyectadas lo dirigen a un archivo del sistema en lugar de al proyecto. Si se sobrescribe el propio asistente del sandbox (en macOS, /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox), los comandos posteriores se ejecutan sin ningún sandbox. Los archivos de inicio como ~/.zshrc también sirven como objetivos.
* CVE-2026-50549 abusa de una comprobación de seguridad. Antes de escribir, Cursor resuelve los accesos directos (symlinks) para confirmar que el destino real esté dentro de tu proyecto. El error es el sistema de respaldo: cuando esa comprobación falla, porque el objetivo no existe o el atacante elimina el acceso de lectura de una carpeta en la ruta, Cursor se rinde y confía en la ruta del acceso directo dentro del proyecto. Un atacante crea un acceso directo que apunta fuera del proyecto, fuerza el fallo de la comprobación y Cursor escribe directamente a través de él hacia el mismo asistente del sandbox. Mismo escape, puerta diferente. Una vez que el sandbox es neutralizado, el siguiente comando se ejecuta como si fueras tú. Eso significa el control de la máquina del desarrollador, además de cualquier espacio de trabajo en la nube o SaaS en el que el editor haya iniciado sesión. Todo deriva de un prompt que parece inofensivo.

No hay indicios de que esto se haya utilizado en ataques reales. Cato lo presenta como una investigación y no como una campaña activa, y el registro público de vulnerabilidades no muestra ninguna explotación conocida hasta la fecha de publicación.

Cato informó de ambos problemas el 19 de febrero. Según Cato, Cursor los rechazó cuatro días después, diciendo que su modelo de amenazas no cubría el mal uso de los servidores MCP, incluso los estándar como el espacio de trabajo oficial de Linear.

Cato insistió el 26 de febrero; Cursor reabrió los informes, los clasificó y lanzó ambas correcciones en la versión 3.0. Los IDs de CVE fueron asignados el 5 de junio.

Cursor publicó su propio aviso para el error de symlink, y su registro NVD ya está activo.

No es el primero, y probablemente no sea el último

DuneSlide es el último de una serie de errores de Cursor que comienzan con un prompt envenenado y terminan en la ejecución de código, cada uno derrotando una barrera de seguridad diferente:

* CurXecute (CVE-2025-54135, agosto de 2025) provino del mismo equipo, que entonces operaba como Aim Security. Un mensaje de Slack plantado reescribía la configuración ~/.cursor/mcp.json de Cursor y ejecutaba comandos incluso después de que el usuario rechazara la edición. Solucionado en la 1.3.
* MCPoison (CVE-2025-54136), de Check Point Research, permite que un atacante consiga que se apruebe una configuración de MCP una vez, y luego intercambie silenciosamente comandos maliciosos sin un segundo prompt.
* CVE-2026-26268 (febrero de 2026) ocultaba un hook de Git trampa en un repositorio que se activaba en el momento en que el agente ejecutaba un comando de Git. Parcheado en la 2.5. El sandbox en la línea 2.x fue la respuesta de Cursor a esa ola anterior. DuneSlide consiste en escapar de esa respuesta.

Cato afirma que está revelando fallos similares en otros agentes de codificación y argumenta que el problema es estructural en lugar de una serie de casos aislados.

Esto deja una pregunta abierta para cualquiera que lance un agente que lea la web abierta: si tratar cada entrada como hostil se convierte en el estándar o si seguirá siendo una lucha constante de parche por parche.

Fuente:
THN