Cursor ejecuta git.exe desde la raíz del repositorio

Mindgard describe un error grave y sencillo en Cursor para Windows: si en la raíz de un proyecto hay un archivo llamado git.exe, el IDE lo ejecuta al abrir el repositorio sin solicitar confirmación ni emitir advertencia alguna, con los permisos del desarrollador. La divulgación inicial se produjo en diciembre de 2025, y la divulgación completa pública está prevista para el 14 de julio de 2026, aunque según la investigación, el fallo sigue sin parchearse.

Relacionado:
Puerta trasera en la cadena de suministro de npm/PyPI  /  
Filtraciones de código fuente y elusión de parches

El error en un párrafo

¿Qué es el error de Cursor-git.exe? Al cargar un proyecto, Cursor busca binarios de Git en múltiples ubicaciones, incluyendo el espacio de trabajo. Un git.exe ubicado en la raíz del repositorio se ejecuta como parte de la resolución de rutas. Los registros del Process Monitor muestran que Cursor.exe inicia git rev-parse –show-toplevel con el binario del espacio de trabajo. El PoC de Mindgard utiliza equipos con Windows donde calc.exe ha sido renombrado como git.exe. La calculadora se inicia y se reactiva en el sistema operativo.

No es inyección de *prompt*, ni *jailbreak* del modelo. Se trata de *Binary Planting* en el espacio de trabajo. Para los atacantes, basta con un repositorio manipulado: clonar, abrir con Cursor, y el código se ejecuta en el contexto del usuario del desarrollador. A menudo con acceso a tokens, claves SSH y paquetes internos.

Cronología y silencio del proveedor

Mindgard reportó el incidente el 15 de diciembre de 2025 a security-reports@cursor.com. A través de HackerOne y el canal del CISO se confirmó y se reprodujo el fallo, tras lo cual, según la investigación, hubo un prolongado silencio. El 14 de julio de 2026 se hizo pública la divulgación completa al no materializarse la remediación coordinada. A fecha de publicación de la investigación: ni parche ni aviso público por parte del proveedor.

Para los responsables de seguridad de la información (CISO), este hallazgo se suma al anterior: los acuerdos de nivel de servicio (SLA) del proveedor y la higiene en la divulgación de vulnerabilidades deben formar parte de la evaluación de las herramientas de codificación con IA. La productividad por sí sola no es un argumento de confianza. Cursor opera como TI en la sombra en muchas organizaciones de ingeniería. El horizonte para la solución sigue siendo desconocido.

Acciones que las empresas deben aplicar hasta que se publique el parche

Hasta que el proveedor publique un parche, las medidas siguen siendo operativas: inventario de usuarios de Cursor en Windows, políticas para repositorios no confiables y controles de punto final contra ejecutables de espacios de trabajo. La lista de verificación a continuación es el estándar mínimo para responsables de seguridad (CISO) y líderes de ingeniería.

AppLocker o WDAC (Windows Defender Application Control) deben aplicarse por ruta, no por hash. Los atacantes modifican el hash. No permitir ejecutables genéricos desde las raíces de los espacios de trabajo, en lugar de bloquear solo git.exe. El «Binary Planting» es un patrón conocido que afecta a múltiples IDEs con IA. Exigir únicamente «ningún CVE en el escáner» demuestra una falta de comprensión del riesgo. Fuente principal: Blog de Mindgard, 14.07.2026; verificaciones cruzadas con Dark Reading y The Hacker News.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿Afecta esto a macOS y Linux?

La explotación descrita se dirige a Windows y a git.exe en la raíz del repositorio. Es necesario evaluar otras plataformas por separado. Los desarrolladores de Windows son el principal foco de atención.

¿Basta con bloquear git.exe?

Este es el desencadenante actual. La resolución de rutas puede verificar otros nombres de herramientas. Mejor: no permitir ejecutables genéricos desde las raíces de los espacios de trabajo.

¿Es lo mismo que CVE-2026-26268 (Git-Hooks)?

No. Según los informes, el CVE-20268 afecta a los *Git Hooks* ocultos. El caso de Mindgard se refiere al *Binary Planting* de git.exe en la raíz. Mecanismo distinto, mismo resultado: ejecución de código.

¿Qué exigimos al proveedor?

Parche, aviso, política de rutas de búsqueda clara sin ejecución en el espacio de trabajo, así como unos SLA (acuerdos de nivel de servicio) transparentes para vulnerabilidades críticas en el programa de recompensas por errores.

¿Fuente principal?

Blog de Mindgard: «Cursor 0day: Cuando la divulgación total se convierte en la única protección posible» (14.07.2026).

Selección de la redacción

RecomendadoBypass de JWT en SharePoint abre sitios localesRecomendadoVulnerabilidad de BitLocker ante acceso físico en 2026RecomendadoNihon Kotsu: caída del despacho tras ataque de malware

Más de la red MBF Media

cloudmagazinAWS Cloud soberana: qué está realmente separadoMyBusinessFuturePasaporte digital de producto: qué deben hacer los fabricantes