Se ha descubierto una vulnerabilidad crítica y sin parchear en Cursor, el editor de código con IA utilizado por más de 7 millones de desarrolladores. Este fallo permite que atacantes logren la ejecución arbitraria de código en sistemas Windows. El riesgo es elevado ya que basta con abrir un repositorio malicioso para activar la ejecución, sin necesidad de clics, confirmaciones o autorizaciones del usuario.

Una vulnerabilidad crítica sin parchear en Cursor, el popular editor de código impulsado por IA utilizado por más de 7 millones de desarrolladores, permite que los atacantes logren la ejecución de código arbitrario en sistemas Windows.

Basta con abrir un repositorio malicioso para activar esta ruta de ejecución, sin requerir clics del usuario, confirmaciones de avisos ni aprobaciones de autorización.

El fallo fue descubierto por la empresa de seguridad Mindgard el 15 de diciembre de 2025 y reportado al equipo de seguridad de Cursor el mismo día.

A pesar de los 197 lanzamientos de versiones posteriores, la vulnerabilidad sigue presente en la última compilación probada, lo que llevó a Mindgard a hacer pública la información tras siete meses de silencio por parte del proveedor.

Fallo Crítico de Día Cero en Cursor

La vulnerabilidad se deriva de cómo Cursor resuelve los binarios de Git al cargar un proyecto de desarrollo. Entre las ubicaciones que Cursor busca se encuentra la propia raíz del espacio de trabajo.

Si un atacante coloca un archivo malicioso llamado git.exe en ese directorio raíz, Cursor lo ejecuta automáticamente como parte de su rutina normal de resolución de rutas. Debido a que el editor realiza esta búsqueda de forma implícita, activa la ejecución sin ningún aviso de seguridad ni advertencia al usuario.

El impacto estructural de este bucle de ejecución automática se analiza en el informe de día cero de Mindgard. Durante las pruebas, Mindgard demostró este problema utilizando un binario de la Calculadora de Windows renombrado como una prueba de concepto inofensiva.

El simple hecho de abrir el directorio del proyecto en Cursor provocó ejecuciones repetidas del binario, generando múltiples instancias de la Calculadora con el tiempo, ya que el IDE invocaba el archivo durante la ejecución rutinaria en segundo plano.

Los registros de Sysinternals Process Monitor confirmaron que el proceso padre Cursor.exe generó el binario plantado a través de una consulta estándar git rev-parse --show-toplevel, verificada por última vez en la versión 3.2.16 de Cursor.

En un escenario real, este ejecutable de la Calculadora sería reemplazado por un vector de amenaza activo, como un cargador de ransomware, un recolector de credenciales o un keylogger que operaría silenciosamente bajo el nivel de privilegios actual de la víctima.

La comunicación de Mindgard siguió los protocolos estándar de divulgación coordinada de la industria:

• 15 de diciembre de 2025: Se envió el informe inicial de la vulnerabilidad a través del correo electrónico de security.txt publicado por Cursor, seguido de repetidas solicitudes de estado.
• Enero de 2026: Tras no recibir respuesta, Mindgard inició una búsqueda pública en LinkedIn para localizar un contacto válido. El CISO de Cursor respondió, atribuyendo el retraso a un error de automatización de HackerOne, e invitó manualmente a Mindgard a su programa privado de recompensas.
• Evaluación de Recompensa: El informe se cerró inicialmente como "Informativo" y fuera de alcance. Esta evaluación fue revertida solo después de que Mindgard impugnara la decisión y el personal de triaje de HackerOne reprodujera con éxito el error.
• Enero – Junio de 2026: Mindgard envió múltiples solicitudes de estado a través de HackerOne y realizó intentos directos de contactar con el liderazgo de Cursor. Todos los mensajes quedaron sin respuesta, incluso mientras el proveedor seguía lanzando docenas de nuevas versiones de producción.

Este prolongado retraso en la priorización de vulnerabilidades críticas en entornos de desarrollo refleja preocupaciones más amplias en la industria sobre cómo los scripts de terceros no asegurados pueden comprometer los endpoints de los desarrolladores.

Debido a que actualmente no hay un parche oficial disponible del proveedor, tú, como administrador o usuario final, debes confiar en controles de seguridad compensatorios para limitar tu exposición.

Los grupos de seguridad empresarial que gestionan endpoints de Windows deben implementar reglas de denegación basadas en rutas en lugar de controles basados en hash:

• AppLocker / Windows App Control: Crea reglas de denegación de rutas dirigidas a los directorios de espacio de trabajo (por ejemplo, %USERPROFILE%\source\repos*\git.exe). Dado que los binarios proporcionados por el atacante varían según el hash, las reglas de bloqueo deben dirigirse a la ruta del archivo y no a la firma del mismo.
• Integración de EDR: Debido a que Windows carece de un bloqueo de aplicaciones nativo consciente del proceso padre, la mitigación completa requiere configurar anulaciones de reglas especializadas de detección y respuesta de endpoints (EDR) para monitorear los procesos hijos de Cursor.exe.

Si eres un desarrollador individual, debes tomar precauciones estrictas de contención al tratar con repositorios externos:

• Aislamiento en Sandbox: Evita abrir repositorios no confiables o recién clonados directamente en un sistema operativo anfitrión. Abre los proyectos exclusivamente dentro de una Máquina Virtual (VM) desechable o una sesión de Windows Sandbox hasta que se publique un parche de seguridad formal.
• Auditoría de Procesos: Monitorea los administradores de tareas activos en busca de procesos hijos no autorizados. Los equipos de seguridad deben auditar proactivamente los endpoints para defenderse contra capas de ejecución no confiables que podrían evadir el aislamiento tradicional del host.

Vector de Vulnerabilidad	Componente Implicado	Acción Desencadenante	Mitigación Inmediata
Búsqueda de Git en Espacio de Trabajo	Ruta de búsqueda del directorio raíz	Simplemente abrir un directorio de proyecto	Reglas de AppLocker basadas en rutas / Aislamiento en Windows Sandbox

Fuentes:
https://cybersecuritynews.com/critical-cursor-0-day-flaw/