Qué encontró Cato en Cursor
Cato AI Labs ha revelado dos vulnerabilidades críticas en Cursor, el editor de código con IA que, según su fabricante, usa más de la mitad de las Fortune 500. Bautizadas como DuneSlide y registradas como CVE-2026-50548 y CVE-2026-50549, ambas tienen una puntuación CVSS de 9,8 sobre 10, o de 9,3 en la escala más reciente, la 4.0. Están corregidas en Cursor 3.0, publicado el 2 de abril de 2026, y toda versión anterior está afectada.
En el momento de la divulgación no constaba ninguna explotación activa. El camino hasta la corrección no fue liso. Cato comunicó el problema el 19 de febrero, el fabricante lo rechazó primero el 23 de febrero, luego reabrió el caso, entregó una corrección el 1 de abril y la segunda el 1 de junio. Los números CVE se asignaron el 5 de junio.
Cómo una página web se convierte en un comando
La técnica es la inyección de instrucciones sin un solo clic. El desarrollador nunca escribe una orden maliciosa. Es el agente el que lee contenido en nombre del usuario: la respuesta de un servidor Model Context Protocol conectado, una página devuelta por una búsqueda web o un archivo del propio proyecto. Ese contenido lleva órdenes ocultas que el modelo acaba obedeciendo.
El primer fallo abusa del parámetro working_directory. Cuando el agente lo fija en una ruta distinta de la habitual, Cursor añade esa ruta a su lista de escritura permitida sin comprobarla. Así, una instrucción inyectada puede sobrescribir un archivo del sistema, como el binario ayudante de la sandbox o un perfil de shell. El segundo fallo aprovecha una comprobación de enlaces simbólicos que cede ante el fallo: cuando Cursor no consigue resolver un acceso directo, se fía de la ruta interna del proyecto y escribe directamente sobre ese mismo ayudante. Sobrescrito el ayudante, el siguiente comando se ejecuta fuera de la sandbox con todos los derechos del desarrollador.
La lista de lectura es ahora la superficie de ataque
El cambio incómodo está en qué cuenta como entrada. Durante años, el modelo de amenaza de un editor de código era el código que se escribía y las extensiones que se instalaban. Un agente autónomo lo amplía a todo lo que lee por su cuenta: el README de una dependencia, la respuesta de una herramienta, una página descargada. Cada una de esas cosas es hoy instrucción ejecutable, y el radio de impacto es el sistema operativo y no una pestaña del navegador.
Para una empresa que ha desplegado asistentes de programación con IA entre sus ingenieros, esto convierte la herramienta en un componente de la cadena de suministro con alcance hasta la máquina, no en un accesorio de productividad. Bajo NIS2 en la UE, y bajo los deberes equivalentes que las empresas británicas ya asumen, la seguridad del software que reparte a su plantilla es responsabilidad del consejo, y un agente sin parchear que confía en contenido no verificado entra de lleno en ese deber.
Qué deberían hacer los dueños esta semana
El paso inmediato es la higiene de versiones. Confirme que cada desarrollador está en Cursor 3.0 o posterior, porque nada anterior es seguro, y haga la misma pregunta sobre cualquier otro editor con agente o asistente de IDE en uso. Establezca qué herramientas de IA tienen permiso autónomo para escribir archivos o ejecutar comandos, y quién lo aprobó.
El paso duradero es tratar las fuentes de lectura de un agente como no fiables por defecto. Limite qué servidores Model Context Protocol puede conectar un equipo, mantenga a los agentes lejos del contenido externo sin revisar siempre que pueda y exija aprobación humana para cualquier escritura fuera del proyecto de trabajo. La herramienta merece conservarse. Los permisos que la rodean necesitan ahora la misma disciplina que ya aplica a cualquier componente capaz de tocar una máquina en producción.
Leer a continuación: Una IA ejecutó sola todo un ataque de ransomware | Un fallo de 29 años en Squid filtra logins en claro
