IDEsaster: cuando las funciones del IDE base se vuelven primitivas de RCE
Ari Marzouk reveló una clase de vulnerabilidades en la que la inyección de prompts lleva a los agentes de código a abusar de las funciones nativas del editor subyacente — hasta la exfiltración y la ejecución de código en casi todos los IDE con IA.
¿Qué es esto?
El 6 de diciembre de 2025, el investigador de seguridad Ari «MaccariTA» Marzouk publicó IDEsaster, resultado de unos seis meses analizando editores de código potenciados con IA. No es un fallo aislado, sino una clase de vulnerabilidades: una inyección de prompt que lleva a un agente de código a abusar de las funciones nativas del editor subyacente — funciones anteriores a la IA y consideradas seguras — para lograr la exfiltración de datos y la ejecución remota de código.
Las cifras marcan el tono. Más de 30 vulnerabilidades reportadas, 24 identificadores asignados, un boletín de seguridad de AWS y una actualización de la documentación de Claude Code que reconocen el riesgo. Todas las aplicaciones que Marzouk probó eran vulnerables a la nueva cadena — GitHub Copilot, Cursor, Windsurf, Kiro, Zed, Roo Code, JetBrains Junie, Cline, Gemini CLI, Claude Code y más. Como el fallo reside en el editor base compartido y no en un producto concreto, una sola técnica compromete todo un ecosistema a la vez.
Cómo funciona
Los ataques anteriores seguían cadenas conocidas: un prompt envenenado dirige una herramienta vulnerable, o lleva a herramientas comunes a modificar los ajustes del agente (su configuración MCP, su lista de aprobación automática) para obtener ejecución. IDEsaster añade un tercer eslabón que la mayoría de los editores había dejado fuera de su modelo de amenazas: inyección de prompt → herramientas → funciones del editor base. La herramienta de escritura de archivos del agente hace justo aquello para lo que sirve — escribir un archivo — pero ese archivo activa una función heredada con efectos secundarios peligrosos. Marzouk ilustra tres casos; aquí no se reproduce ningún prompt de explotación, y el investigador retuvo deliberadamente las cargas exactas mientras algunos editores siguen sin parchear más allá de los 90 días.
El primer caso abusa de los esquemas JSON remotos. Muchos editores permiten que un archivo .json referencie un esquema de validación en una URL externa, y lo descargan automáticamente. Un agente inducido a escribir un archivo JSON cuyo $schema apunta a un dominio del atacante — con los datos robados añadidos como parámetro — provoca la petición por sí solo. Cabe destacar que la descarga se dispara incluso en el modo de vista previa de diferencias (diff-preview), sorteando algunos controles humanos.
El segundo caso es la sobrescritura de ajustes del IDE para ejecutar código. A diferencia de reportes anteriores que alteraban un ajuste del agente, este apunta a los ajustes del editor base, por lo que se aplica a todos los productos que comparten ese editor. En los editores derivados de VS Code, el agente escribe una carga en un archivo ejecutable siempre presente (un ejemplo de hook de Git, por caso) y luego apunta un ajuste de ruta de validador hacia él; abrir un tipo de archivo correspondiente ejecuta de inmediato el binario. Los editores JetBrains ofrecen una vía equivalente a través de su configuración de proyecto.
El tercer caso, los espacios de trabajo multirraíz, muestra la profundidad de la clase: un archivo de definición de espacio de trabajo puede añadir carpetas arbitrarias como raíces del proyecto, disolviendo la condición de que «el archivo ya debe estar en el espacio de trabajo» y reactivando la sobrescritura de ajustes incluso donde llegó el primer parche. Se cierra una función y aparece otra — que es justamente la cuestión.
Por qué importa
El techo de impacto es la ejecución remota de código en la máquina del desarrollador, más la exfiltración silenciosa de todo lo que el agente pueda leer, desencadenada por contenido que el agente simplemente procesó — un README envenenado, un archivo de reglas, una URL pegada con caracteres invisibles, un servidor MCP comprometido. Millones de desarrolladores usan los productos afectados, y todos los probados estaban expuestos. Marzouk atribuye la causa raíz a un principio de diseño ausente que llama «Secure for AI»: los editores se diseñaron seguros para humanos, pero añadir un agente autónomo capaz de leer, escribir y ejecutar convierte funciones heredadas benignas en primitivas de ataque que nadie reevaluó. La inyección es inevitable; la corrección duradera consiste en reducir lo que un agente secuestrado puede alcanzar.
Defensas
Para quienes usan IDE con IA: ejecute agentes solo en proyectos de confianza, ya que el contenido de los archivos e incluso sus nombres son vectores de inyección; conéctese solo a servidores MCP de confianza y vigile sus cambios; revise manualmente cualquier URL o texto que añada como contexto en busca de instrucciones ocultas o invisibles; y mantenga la validación humana activada allí donde la herramienta lo permita.
Para los equipos que construyen agentes: aplique el mínimo privilegio a cada herramienta — limite read_file al espacio de trabajo (sin traversía, sin enlaces simbólicos, bloqueando dotfiles y rutas de credenciales), restrinja write_file a los directorios de código y exija confirmación para archivos de configuración o dotfiles, y prefiera la aprobación humana o una lista blanca de dominios para http_fetch. Asuma la brecha: exija confirmación para toda acción sensible, aísle los comandos ejecutados (sandbox) e imponga controles de egress en la capa del IDE para que los efectos secundarios de exfiltración (como una descarga automática de esquema) se bloqueen de forma global. Por último, incorpore el conjunto de funciones del editor base al modelo de amenazas y pruebe las herramientas de forma continua — la superficie no deja de crecer.
Estado
| Elemento | Referencia | Notas |
|---|---|---|
| Divulgación IDEsaster | Ari Marzouk (MaccariTA), 2025-12-06 | 30+ vulns, 24 CVE, principio «Secure for AI» |
| Esquema JSON remoto (exfil) | CVE-2025-49150 (Cursor), CVE-2025-53097 (Roo Code), CVE-2025-58335 (Junie) | Descarga automática de una URL $schema controlada por el atacante |
| Sobrescritura de ajustes del IDE (RCE) | CVE-2025-53773 (Copilot), CVE-2025-54130 (Cursor), CVE-2025-53536 (Roo Code), CVE-2025-55012 (Zed) | Un ajuste del editor base apunta un validador a un ejecutable plantado |
| Espacio de trabajo multirraíz (RCE) | CVE-2025-64660 (Copilot), CVE-2025-61590 (Cursor), CVE-2025-58372 (Roo Code) | El archivo de espacio de trabajo añade raíces arbitrarias, eliminando precondiciones |
| Reconocimientos de editores | AWS-2025-019; doc. de Claude Code actualizada | Algunos productos corregidos sin CVE; algunos sin parchear más allá de 90 días |
| Explotación observada | Según el investigador, en la divulgación | Ninguna reportada; cargas retenidas para proteger a los usuarios |
La lección trasciende a los editores: todo agente autónomo injertado sobre un software que lo precede hereda cada una de sus funciones como primitiva potencial. La inyección de prompt es el vector de entrega inevitable — la defensa consiste en asumir que tiene éxito y restringir lo que el agente puede hacer después.