Fallo en Cursor ejecuta git.exe desde la raíz del proyecto en Windows

Una vulnerabilidad zero-day en Windows en Cursor puede desencadenar la ejecución de código arbitrario con solo abrir un repositorio, según la firma de seguridad Mindgard. El problema es sencillo: cuando Cursor carga un proyecto, busca binarios de Git en varios lugares, incluido el propio espacio de trabajo. Si un repositorio contiene un git.exe malicioso en su raíz, Cursor lo ejecuta automáticamente sin aviso, sin advertencia y sin interacción del usuario.

Mindgard afirma que identificó el error por primera vez el 15 de diciembre de 2025 y lo notificó ese mismo día. Más de siete meses después, y tras 197+ nuevas versiones, la firma asegura que la falla sigue existiendo en la versión más reciente que probó. Verificó por última vez el comportamiento el 30 de abril de 2026 contra Cursor versión 3.2.16 en Windows.

Para demostrar el problema, Mindgard usó una prueba de concepto inofensiva: la Calculadora de Windows renombrada a git.exe y colocada en la raíz del repositorio. Abrir ese proyecto en Cursor fue suficiente para lanzarla. La firma afirma que Cursor continuó reejecutando el binario mientras el proyecto permanecía abierto.

Mindgard incluyó un registro de Process Monitor de Sysinternals que muestra a Cursor.exe creando git.exe con la línea de comandos git rev-parse --show-toplevel. En un ataque real, el binario de la Calculadora podría ser reemplazado por código controlado por el atacante y ejecutarse con los privilegios del usuario actual.

Recomendado

Los enlaces t.me de Telegram vuelven tras un contratiempo por sanciones

Cronología y respuesta del proveedor

Según Mindgard, el proceso de divulgación se estancó repetidamente. Tras los correos iniciales a la dirección indicada en el security.txt de Cursor, el CISO de la compañía dijo más tarde que una falla de automatización interna había bloqueado el flujo de trabajo esperado en HackerOne. Mindgard fue invitada al programa privado de bug bounty de Cursor y volvió a enviar el informe el 15 de enero de 2026.

El informe fue inicialmente marcado como Informative y fuera de alcance, y luego reabierto el 16 de enero de 2026 tras su reproducción. HackerOne confirmó la entrega a Cursor el 20 de enero de 2026, dijo Mindgard, pero las solicitudes de seguimiento del 16 de febrero, 3 de marzo, 1 de abril y 1 de junio de 2026 no produjeron ninguna actualización significativa. La firma publicó su divulgación completa el 14 de julio de 2026.

Mitigaciones temporales para usuarios de Windows

Mindgard recomienda distintas medidas de mitigación según el entorno:

• En sistemas Windows empresariales o gestionados, los administradores pueden usar AppLocker o Windows App Control para bloquear la ejecución del nombre de ejecutable afectado desde los directorios de espacio de trabajo de desarrolladores.
• La firma recomienda reglas de denegación basadas en la ruta, aplicadas a las raíces de repositorios o espacios de trabajo, en lugar de reglas basadas en hash, ya que los binarios de los atacantes pueden cambiar.
• En sistemas de consumo, aconseja abrir repositorios no confiables solo en una máquina virtual aislada, Windows Sandbox u otro entorno desechable hasta que Cursor publique una corrección.

Mindgard plantea el caso como un fallo en la divulgación coordinada, argumentando que los usuarios merecen saber cuando una vulnerabilidad sencilla y de alto impacto permanece sin resolver mientras el software afectado sigue distribuyéndose. Con Cursor afirmando más de 7 millones de usuarios activos, más de 1 millón de usuarios diarios, más de 1 millón de usuarios de pago, uso por parte de más de 50 000 empresas y un valor de mercado reportado de 60 000 millones de dólares, el informe plantea una pregunta directa sobre cómo se están manejando los problemas de seguridad en una de las mayores plataformas de programación en Windows.