El 1 de julio de 2026, el equipo de investigación Cato AI Labs hizo públicos dos fallos críticos en Cursor, uno de los editores de código con IA más usados. Los bautizaron DuneSlide, les asignaron los identificadores CVE-2026-50548 y CVE-2026-50549 y una puntuación crítica (9,8 en CVSS 3.1; 9,3 en CVSS 4.0). Lo que permiten, resumido, es que una inyección de prompt escape del entorno aislado del editor y ejecute comandos arbitrarios en el equipo del desarrollador, sin un solo clic adicional.
Lo interesante no es un fallo más en un editor. Es la confirmación de algo que llevábamos meses viendo llegar: la inyección de prompt ha dejado de ser una curiosidad académica para convertirse en una vía real hacia la ejecución de código, dentro de herramientas que los desarrolladores ya usan con acceso al código fuente, a los secretos y a la red interna. El parche existe, pero la lección dura más que el parche.
Qué es exactamente lo que falla
El agente de un editor con IA lee contenido en tu nombre: ficheros del proyecto, páginas web, respuestas de servicios conectados a través del protocolo MCP. Si ese contenido lleva instrucciones ocultas, lo que se conoce como inyección de prompt indirecta, el agente puede acabar actuando sobre ellas como si fueran tuyas. Para acotar el daño, Cursor ejecuta los comandos del agente dentro de un entorno aislado. DuneSlide trata, precisamente, de cómo salir de ese aislamiento. La descripción técnica de Cato lo detalla a nivel conceptual.
El primero de los fallos, CVE-2026-50548, se apoya en que el aislamiento confía en la carpeta de trabajo que elige el agente. Si unas instrucciones inyectadas apuntan esa carpeta a una ruta del sistema en lugar de al proyecto, se abre la puerta a sobrescribir el propio componente que impone el aislamiento, de modo que las órdenes posteriores se ejecutan ya sin ninguna barrera. Contado así, a grandes rasgos: se engaña al guardián para que se desactive a sí mismo.
El segundo, CVE-2026-50549, vive en una comprobación de seguridad sobre los enlaces simbólicos. Antes de escribir, el editor intenta resolver el enlace para confirmar que el destino real está dentro del proyecto; cuando esa comprobación falla, en lugar de negarse, el editor opta por confiar en la ruta aparente. Es el valor por defecto equivocado. Ambos fallos, como subraya The Hacker News, se disparan sin interacción deliberada: la víctima solo lanza una petición inofensiva que, sin saberlo, ingiere contenido controlado por el atacante.
El vector no es el usuario: es lo que el agente lee
Aquí está el cambio de mentalidad. El ataque no aterriza engañando a la persona, sino envenenando lo que el agente consume: la respuesta de un servidor MCP, una página devuelta por una búsqueda web. La intención del desarrollador es legítima; el contenido no confiable es el que trae la carga. Esa es la esencia de la inyección de prompt indirecta, y por eso no basta con formar a la gente para que no pulse enlaces raros.
Por qué esto es un problema de empresa, no de un desarrollador
Estos editores se ejecutan con los privilegios del desarrollador: leen y escriben en el código fuente, ven las credenciales y los tokens que hay en su entorno y alcanzan la red interna. Una fuga del aislamiento ahí no es una molestia en un portátil: es un punto de apoyo dentro de tu ciclo de desarrollo, con acceso a lo que de verdad importa.
A eso se suma que la adopción es amplia y muchas veces invisible para seguridad. Los desarrolladores instalan editores con IA y conectores MCP por su cuenta, sin pasar por ningún control. La pregunta de inventario, qué herramientas con agente tocan nuestro código y con qué permisos, es una que muchas organizaciones no saben responder. Es IA en la sombra dentro del propio desarrollo, y amplía la superficie de ataque por un flanco que casi nadie vigila.
Los datos, y lo que confirman
DuneSlide son dos vulnerabilidades, CVE-2026-50548 y CVE-2026-50549, ambas críticas, descubiertas por Cato AI Labs y corregidas en Cursor 3.0, publicado el 2 de abril de 2026. Toda versión anterior a la 3.0 está afectada. Conviene ser honesto con el matiz: el fallo se divulga ahora, pero el arreglo lleva disponible desde la 3.0; la urgencia está en comprobar qué versión corre tu equipo, no en un pánico de día cero. La cobertura de CSO Online enmarca bien por qué esto trasciende a Cursor.
Y no es un caso aislado. Investigaciones independientes describen la misma clase de problema: el trabajo de Straiker sobre el túnel remoto de Cursor y análisis académicos sobre editores con agente muestran que la inyección de prompt indirecta se puede armar a través de las propias funciones del editor. La historia no es un fallo suelto, sino el patrón. Hasta donde se sabe, la divulgación es de investigadores y no hay evidencia pública de explotación masiva en real; decirlo así es parte de informar bien.
Por qué los controles tradicionales se quedan cortos
No aterriza ningún binario malicioso: el malware, por así decirlo, es el texto que el agente lee. Las firmas del antivirus y del EDR no encajan con limpieza en algo que no es un fichero. La pasarela de correo y el WAF no están en el camino. La frontera de confianza que falla está dentro de la herramienta, entre lo que el modelo lee y lo que se le permite hacer. El pensamiento de perímetro clásico, sencillamente, no mira ahí.
Tampoco ayudan la identidad ni el MFA: el agente ya se ejecuta como el desarrollador legítimo. No hay un inicio de sesión sospechoso que bloquear, porque no hay inicio de sesión. Hay una herramienta de confianza haciendo algo que no debería, porque leyó algo que no debía.
Detección y contención concretas
Con visibilidad de endpoint en las estaciones de los desarrolladores sí hay señales aprovechables. Procesos hijo inesperados lanzados por el editor, escrituras en las rutas de la aplicación o de sus componentes internos, o conexiones salientes nuevas, especialmente un túnel remoto abierto de repente, son justo el tipo de anomalía que merece una alerta. Un agente de programación que empieza a escribir fuera del repositorio o a abrir un túnel es el evento a cazar.
El control del tráfico de salida en los entornos de desarrollo acota mucho el impacto: si el agente no puede exfiltrar ni descargar una segunda fase, la fuga del aislamiento vale bastante menos. Registrar y revisar qué servidores MCP se conectan, y tratar cada llamada a herramientas del agente, búsqueda web incluida, como entrada no confiable que cruza una frontera, convierte una caja negra en algo auditable.
Y la parte de inventario es ineludible. Saber qué editores con IA y qué versiones se usan, y contrastarlo con su estado de vulnerabilidades, es un trabajo de gestión de vulnerabilidades clásico aplicado a una categoría de herramienta nueva. No puedes proteger lo que no sabes que está instalado.
Defensa práctica
Lo primero es lo más aburrido y lo más eficaz: asegurar que Cursor y editores equivalentes corren versiones corregidas, la 3.0 o superior en el caso de Cursor, y hacerlo de forma centralizada donde se pueda. Añadir estas herramientas al inventario que ya gestionas evita que la próxima vulnerabilidad de esta familia te pille sin saber siquiera dónde está.
Después, mínimo privilegio para los agentes. No conviene ejecutarlos con acceso amplio al sistema de ficheros, a los secretos o a la red; acotar la carpeta de trabajo, mantener las credenciales fuera del entorno que el agente puede leer y exigir aprobación humana antes de ejecutar comandos, cuando la herramienta lo permita, cambia por completo el peor escenario.
También conviene limitar de qué se alimentan. Restringir qué servidores MCP y qué fuentes externas puede consumir un agente, preferir conectores de confianza y fijados, y desconfiar de los agentes que descargan contenido web arbitrario de forma automática reduce la materia prima del ataque.
Nada de esto sustituye a una política. Decidir qué herramientas de programación con IA están aprobadas, con qué configuración y qué permisos, y acompañarlo de una guía para el desarrollador, es lo que separa el uso gobernado del descontrol. Ya lo comentamos al hablar de LLMs, copilots y vibe coding en la empresa y de los controles de producción para MCP y agentes.
Y hace falta una respuesta preparada. Si se sospecha que una estación con un agente está comprometida, la respuesta a incidentes debe considerar en su alcance el acceso al código, los tokens presentes y el posible movimiento lateral desde ese equipo. El desarrollador es, a efectos de red, un usuario con muchas llaves.
Qué implica para NIS2 y DORA
La NIS2 espera medidas de seguridad en el desarrollo y en la cadena de suministro del software, y el gobierno de las herramientas con las que se construye ese software entra de lleno en ese terreno. DORA obliga a las entidades financieras a gestionar el riesgo tecnológico, incluido el de las herramientas y proveedores que intervienen en sus sistemas. En ambos marcos, una categoría de herramienta capaz de ejecutar código con los permisos del desarrollador no es un detalle de productividad: es riesgo tecnológico que hay que gestionar y documentar.
La conclusión honesta es que el parche es la parte fácil. El problema de fondo dura: a medida que los agentes ganan autonomía y leen más contenido no confiable, aquello de que la entrada es el exploit se convierte en una restricción de diseño permanente. La postura sensata es tratar como hostil toda fuente que un agente lee, hasta que se demuestre lo contrario, y darle a cada agente el menor poder que le permita seguir haciendo su trabajo.