RCE en Cursor al clonar repos: qué debe revisar tu empresa

Clonar y abrir un repositorio en Cursor puede ejecutar código arbitrario en el equipo del desarrollador antes de escribir una sola línea o lanzar un prompt a la IA. El fallo no está en el modelo de lenguaje, sino en la arquitectura heredada de VS Code: tareas definidas en tasks.json, extensiones recomendadas y configuraciones de servidores MCP se cargan automáticamente al abrir la carpeta del proyecto. Cursor no siempre exige la confirmación de Workspace Trust que Visual Studio Code impone por defecto desde 2020, y esa diferencia es la puerta de entrada. En Windows, el proceso hijo que ejecuta el código malicioso nace de un binario firmado (cursor.exe), lo que reduce las alertas de antivirus y EDR tradicionales. Para una empresa que empieza a repartir Cursor, Windsurf o cualquier IDE con IA integrada entre sus desarrolladores, esto cambia la superficie de ataque: ya no basta con vigilar qué le preguntan a la IA, hay que vigilar qué pasa en el instante en que se abre una carpeta.

Cursor es un fork de VS Code, y hereda buena parte de su motor de configuración por carpeta: cualquier repositorio puede incluir un archivo .vscode/tasks.json que defina tareas con la propiedad runOptions.runOn establecida en folderOpen. Microsoft documenta esta función como legítima -sirve para instalar dependencias o levantar un entorno automáticamente-, pero su efecto colateral es que, si el usuario ya ha marcado la carpeta como confiable o Workspace Trust está desactivado, la tarea se ejecuta sin ninguna confirmación adicional. Un atacante que consigue que un desarrollador clone un repositorio -vía una oferta de colaboración, un fork de un proyecto popular, un paquete compartido en un foro- solo necesita que ese archivo llegue con el código. No hace falta phishing dirigido ni que el desarrollador interactúe con el chat de IA: el vector es el propio acto de abrir la carpeta en el editor. La técnica no es nueva ni exclusiva de Cursor -se documenta el abuso de tasks.json y extensiones recomendadas en VS Code desde que Microsoft introdujo Workspace Trust en 2020-, pero la proliferación de IDEs con IA ha multiplicado el número de desarrolladores que clonan repositorios de terceros con más frecuencia y menos escrutinio, precisamente para que la IA los analice o los complete.

MCP: la puerta trasera con nombre propio (MCPoison y CurXecute)

El Model Context Protocol (MCP) añade una segunda superficie de ataque específica de los IDEs con IA. Un repositorio puede incluir una configuración MCP que registre un servidor local -por ejemplo, uno que ejecute un script de la propia carpeta- y Cursor pide aprobación la primera vez que lo detecta. En 2025, investigadores de Check Point Research documentaron una técnica bautizada MCPoison: el atacante consigue que el desarrollador apruebe una configuración MCP inofensiva y, después, modifica silenciosamente el comando que ejecuta ese servidor dentro del propio repositorio; cuando el desarrollador reabre el proyecto, Cursor confiaba en la aprobación previa y ejecutaba el comando nuevo sin volver a preguntar. Por separado, Aim Security describió ese mismo año otra ruta -CurXecute- en la que una respuesta manipulada de una herramienta MCP conseguía que el propio agente de IA escribiera en su archivo de configuración, encadenando una inyección de prompt con ejecución de código en el sistema. Ambos casos comparten un patrón: la confianza se otorga una vez y se asume indefinidamente, sin revalidar el contenido en cada apertura del proyecto.

La reacción natural de muchos responsables de IT al hablar de seguridad en herramientas de IA para desarrollo es pensar en fuga de datos: código propietario que sale hacia un modelo en la nube, o un prompt injection que hace que la IA revele secretos. Es un riesgo real, pero no es el que está en juego aquí. El mecanismo descrito no necesita que nadie escriba un prompt ni que el modelo razone sobre nada: el punto de entrada es el propio editor actuando como intérprete de configuración de carpeta, algo que existe desde antes de la IA generativa. La consecuencia práctica es que las políticas centradas solo en qué puede ver o hacer la IA -bloquear el envío de código a la nube, limitar el contexto, auditar prompts- dejan sin cubrir el vector más directo, que es la ejecución de código nativo del sistema operativo disparada por abrir una carpeta. Cualquier empresa que audite sus herramientas de IA de codificación solo desde el ángulo del modelo de lenguaje se deja la mitad del problema fuera del análisis.

Es tentador, tras leer esto, concluir que la solución es bloquear Cursor y herramientas similares hasta nueva orden. En Blurtek no lo recomendamos como primera medida: el salto de productividad que reportan los equipos que usan IA integrada en el IDE es real, y renunciar a él por un riesgo mitigable es una decisión cara y, a menudo, temporal -los desarrolladores encuentran la forma de usarlo igualmente desde su equipo personal, fuera de cualquier control corporativo, que es el escenario peor. La alternativa razonable es tratar estas herramientas como lo que son: software que ejecuta código de terceros por diseño, igual que un gestor de paquetes o un pipeline de CI/CD, y aplicarles el mismo nivel de desconfianza por defecto. Eso implica aceptar fricción adicional en el onboarding de cada herramienta nueva, no solo firmarla en una política de seguridad que nadie aplica en el día a día. La pregunta que debe hacerse un CTO no es si se permite Cursor sí o no, sino qué repositorio puede abrir cada desarrollador y con qué privilegios en esa máquina.

• Confirmar que Workspace Trust está activo y configurado para no confiar por defecto en carpetas nuevas ni en subcarpetas de un repo ya confiado.
• Desactivar o auditar la ejecución automática de tareas (runOn: folderOpen) a nivel de política del editor, no solo por proyecto.
• Revisar manualmente .vscode/tasks.json, .vscode/launch.json y .cursor/mcp.json antes de abrir cualquier repositorio externo o de un fork no verificado.
• Restringir qué servidores MCP puede registrar un desarrollador y bloquear la auto-aprobación silenciosa de cambios posteriores en su configuración.
• Ejecutar el clonado y primera apertura de repos externos en una máquina virtual, contenedor o WSL sin credenciales corporativas ni acceso a la red interna.
• Aplicar mínimo privilegio en la cuenta de desarrollo: sin permisos de administrador local por defecto en el equipo donde corre Cursor.
• Añadir reglas de EDR que alerten cuando cursor.exe lance procesos hijos como powershell.exe o cmd.exe fuera del patrón habitual del desarrollador.
• Mantener Cursor y extensiones actualizadas y suscribirse a los avisos de seguridad del fabricante, no solo a las notas de versión de funcionalidades.

Configuración mínima recomendada en Windows

• Política de grupo o MDM que impida deshabilitar Workspace Trust a nivel de usuario individual.
• Cuenta de desarrollo sin privilegios de administrador local, con UAC en modo estricto.
• Carpeta de trabajo para repos externos separada físicamente (otra unidad o VM) del entorno con credenciales de producción o VPN corporativa.
• Registro centralizado de procesos hijos de cursor.exe vía Sysmon o el EDR corporativo, con alerta específica para powershell.exe -enc o cmd.exe /c inusuales.

Si tu empresa ya lleva meses con Cursor u otro IDE de IA repartido entre el equipo sin ninguna de estas comprobaciones, el primer paso no es entrar en pánico ni desinstalarlo de golpe: es hacer un inventario real de qué máquinas lo tienen, con qué privilegios corre la cuenta de cada desarrollador y qué repositorios externos se han abierto en los últimos meses. A partir de ahí, prioriza cerrar el privilegio de administrador local en los equipos de desarrollo -es la medida individual que más limita el daño de cualquier RCE, con IA o sin ella- y activa Workspace Trust de forma centralizada antes de tocar nada más. La revisión retroactiva de repos ya abiertos tiene rendimientos decrecientes: es más rentable invertir ese tiempo en blindar hacia delante que en perseguir un compromiso que, si ocurrió, probablemente ya dejó rastro en el EDR o no dejó ninguno por falta de monitorización, y perseguirlo entonces no cambia el resultado. Documenta la política resultante en una sola página que el equipo de desarrollo pueda seguir sin fricción, porque una política que nadie lee no protege nada.