Dos RCE 9.8 en Cursor muestran cómo la inyección de prompt se convirtió en un vector de ejecución remota en IDE de IA

Cato AI Labs divulgó este miércoles, 1 de julio, dos vulnerabilidades críticas en Cursor, IDE de código impulsada por IA utilizada por más de la mitad de la Fortune 500, según la propia fabricante. Las fallas, rastreadas como CVE-2026-50548 y CVE-2026-50549, y ambas con CVSS 9.8, permiten ejecución remota de código en el host del desarrollador a partir de contenido malicioso plantado en un servicio conectado por el Model Context Protocol (MCP) o en una página que el agente de Cursor carga durante una búsqueda en la web. El ataque es zero-click: el desarrollador no teclea nada, el agente lee la instrucción envenenada y ejecuta.

Anysphere, fabricante de Cursor, corrigió los dos errores en la versión 3.0, publicada el 2 de abril. La ventana entre el parche y la divulgación pública es típica de un disclosure coordinado, pero afecta a toda la base instalada anterior a la 3.0. Este universo, según Cursor, incluye equipos de ingeniería en consultorías y bancos que han estandarizado la herramienta en pipelines de agentes de código en los últimos doce meses.

Cómo se rompió la sandbox

El CVE-2026-50548 explora un comportamiento de la sandbox. Cuando el agente ejecuta la herramienta run_terminal_cmd, Cursor permite escritura en el directorio de trabajo declarado. El parámetro working_directory es opcional y controlado por el propio modelo de lenguaje. Una inyección de prompt que consigue establecer este parámetro a un camino fuera del proyecto, apuntando al binario cursorsandbox o al instalador de Cursor, transforma un comando sandboxado en escritura arbitraria, y una escritura arbitraria en el helper de la sandbox se convierte en RCE completa en el siguiente ciclo.

El CVE-2026-50549 rompe la resolución de caminos. Cursor crea un symlink dentro del directorio del proyecto, intenta canonicalizar el objetivo y, cuando la canonicalización falla, hace un fallback al camino original del symlink sin validarlo. Una inyección de prompt que consigue plantar el symlink apuntando fuera del proyecto derriba la misma traba. Las dos cadenas entregan el mismo desenlace: compromiso total de la máquina y del espacio de trabajo SaaS conectado.

La inyección de prompt deja de ser un problema de LLM

El punto que el equipo de Cato plantea en el informe reformatea la discusión sobre seguridad de agentes. La inyección de prompt dejó de ser un problema del modelo de lenguaje, contenido en la conversación entre usuario y chatbot, y pasó a alcanzar errores clásicos en el código auxiliar de la IDE: sandbox, canonicalización, manejo de working_directory. Ninguno de estos componentes fue diseñado asumiendo que el parámetro llegaría de un MCP externo cargado durante la ejecución autónoma. El agente es el intermediario que legitima la entrada hostil.

Una investigación de Pillar Security publicada esta semana sobre una cadena paralela, apodada NomShub, explora la función de Remote Tunnel de Cursor en el mismo espíritu. Según los investigadores, el pipeline de agentes se ha convertido en el nuevo perímetro de seguridad de la estación de desarrollador. Los equipos de seguridad de aplicaciones que pasaron años escribiendo reglas para detectar dependencias vulnerables en CI ahora necesitan revisar qué MCPs los desarrolladores conectan en sus propias workstations y bajo qué política de aprobación.

Qué cambia para consultorías y bancos

Para operaciones de ingeniería distribuida, el problema es de geometría. Equipos de entrega en Bangalore, Cracovia y São Paulo corren Cursor sobre el mismo backlog de tickets, con MCPs que tiran contexto de Jira, Slack y Confluence del cliente. Una instrucción envenenada dentro de un ticket, plantada por un insider malicioso o por un atacante con credenciales robadas, se propaga a cualquier estación con versión pre-3.0. Consultorías con centros de desarrollo en terceros países son las que cargan mayor blast radius, porque estandarizaron Cursor sin inventariar cuántos desarrolladores actualizaron a 3.0 en los últimos tres meses.

Los bancos que integraron Cursor a pipelines internos de revisión de código tienen otra pregunta que hacer, en la línea del cumplimiento regulatorio. Si Cursor ejecuta código dentro de la sandbox bajo la orientación de un LLM que responde a un MCP externo, y si ese MCP externo es aprobado por el propio desarrollador sin un ticket de cambio formal, la operación es una alteración de superficie de ataque que exigiría aprobación de cambio bajo DORA en Europa y bajo la Regla 15c3-5 de la SEC en EE. UU. Ninguno de estos regímenes fue escrito para agentes autónomos. El DuneSlide es el tipo de incidente que fuerza la lectura conservadora de ambos.