La versión ruidosa dice: “un 0-day en un editor de IA ejecuta código solo”. La versión útil es más precisa. Mindgard afirma que Cursor en Windows puede ejecutar un git.exe situado en la raíz de un repositorio abierto mientras busca Git. Cursor responde que el riesgo es estrecho y forma parte de la responsabilidad compartida sobre entradas no confiables del workspace. La lección práctica: abrir un repositorio desconocido en una herramienta de desarrollo con IA ya no es una acción puramente pasiva.

Estación de trabajo de desarrollo con un ejecutable sospechoso aislado de los secretos

Según Mindgard, su prueba renombró Windows Calculator como git.exe, lo puso en la raíz del repositorio y Cursor lo lanzó al abrir el proyecto. No es prompt injection, no demuestra que todos los usuarios estén comprometidos y no confirma el mismo camino en macOS o Linux. Las condiciones importan: Windows, Cursor, un ejecutable malicioso llamado exactamente git.exe y comportamiento de carga que dispara el descubrimiento de Git.

Qué se sabe

Mindgard dice que Cursor prueba varias ubicaciones para encontrar Git y puede ejecutar el binario del workspace. Cyber Security News citó logs de Process Monitor con Cursor.exe lanzando el binario mediante git rev-parse --show-toplevel. The Hacker News añadió una salvedad: el material público no prueba si Cursor busca explícitamente esa ruta o si pasa un git sin ruta completa y Windows aplica su orden de búsqueda.

Para defensa, el resultado es parecido: un archivo dentro del proyecto cruza la línea entre lectura y ejecución antes de una decisión explícita de confianza. Es una clase antigua — untrusted search path / current-directory executable resolution — en un contexto nuevo: IDEs con agentes que inspeccionan y ejecutan más cosas por nosotros.

También hay un límite importante. The Hacker News informó que la última confirmación fechada de Mindgard era Cursor 3.2.16 del 30 de abril, mientras la versión actual mencionada era 3.11 del 10 de julio. En la revisión para este artículo no apareció un advisory oficial ni CVE específico sobre el git.exe de raíz. Eso obliga a verificar versión, changelog y controles, no a asumir certezas absolutas.

La posición de Cursor

Cursor calificó el informe como fuera del alcance de su bug bounty y habló de responsabilidad compartida: el cliente decide qué repositorios, prompts, servidores MCP, reglas y herramientas introduce; Cursor ofrece controles para gestionar esa frontera. La empresa dice que las condiciones son estrechas: Windows y una carpeta con un git.exe malicioso en la raíz. También señala Workspace Trust / restricted mode como mitigación y admite que no cerró bien la comunicación con el investigador.

La responsabilidad compartida tiene sentido, pero no elimina la responsabilidad del producto. “Abrí una carpeta para leer código” no es lo mismo que “aprobé ejecutar un binario de esa carpeta”. Cuanto más automatiza una IDE, más clara debe ser la separación entre leer y ejecutar.

Por qué importa sin pánico

Los comentarios en Hacker News reflejan el debate real. Algunos ven un ejecutable malicioso en un repo como peligro ya conocido en Windows. Otros responden que clonar y abrir repositorios es trabajo normal para maintainers, revisores y equipos de seguridad. La diferencia entre ejecutar un comando manualmente y que la IDE lance algo al abrir el proyecto es la frontera de confianza.

No hay evidencia pública, en las fuentes revisadas, de explotación activa. Eso baja la alarma, no la necesidad de controles. Un equipo no debería esperar a ver abuso real para aislar repositorios desconocidos.

No mezclar con DuneSlide

DuneSlide, CVE-2026-50548 y CVE-2026-50549, fue otro caso de Cursor: prompt injection que escapaba del sandbox, reportado por Cato AI Labs y corregido en Cursor 3.0 según The Hacker News. El caso git.exe de Mindgard es distinto: resolución local de ejecutables durante la carga del proyecto.

Qué hacer

Actualiza Cursor y revisa notas oficiales. Activa Workspace Trust o restricted mode para carpetas no conocidas. No abras repositorios arbitrarios en el host principal: usa Windows Sandbox, VM, devcontainer o entorno cloud desechable. Mira la raíz del proyecto antes de abrirlo en una IDE potente: ejecutables, scripts .cmd o .ps1, hooks, tasks y wrappers inesperados.

Para equipos, define una política usable: repos desconocidos en entornos aislados, credenciales de producción fuera de sesiones de desarrollo generales, agentes sin privilegios cloud amplios, y controles de confianza obligatorios. En Windows, evalúa AppLocker o Windows Defender Application Control por rutas de workspace, con piloto previo. EDR puede alertar cuando Cursor.exe lanza binarios desde carpetas de repositorio.

La lección

No es una razón para entrar en pánico por Cursor. Es una razón para tratar la estación de trabajo del desarrollador como superficie de ataque. Los repositorios desconocidos deben considerarse contenido ejecutable hasta que se demuestre lo contrario. Las herramientas con IA necesitan valores por defecto más seguros y fronteras de confianza visibles.