Contexto técnico
Rara vez veo un fallo tan terrenal y desagradable: Cursor en Windows puede lanzar por sí mismo un git.exe malicioso si se encuentra en la raíz del repositorio abierto. Sin clics, sin inyección de prompts, sin ataques elegantes de IA. Simplemente abres la carpeta y listo.
Precisamente con estas historias evalúo la madurez de la implementación de IA en una empresa. Si una herramienta de desarrollo se rompe al buscar un binario en el espacio de trabajo, el problema no está en el modelo ni en el agente, sino en la higiene básica del producto.
Según Mindgard, la raíz del error está en la lógica de búsqueda de Git: Cursor considera varias rutas y captura un ejecutable directamente del directorio del proyecto. A continuación se produce una ejecución de código arbitrario con los privilegios del usuario actual. La demostración fue casi burlona: renombraron la calculadora como git.exe y Cursor la ejecutó en silencio.
Lo que me preocupó no fue solo la ejecución de código, sino el silencio a su alrededor. Sin advertencia, sin confirmación, sin la menor pista de que el IDE está tocando un binario de un repositorio no confiable.
La historia empeora por el momento. Mindgard informa que enviaron el informe el 15 de diciembre de 2025, luego insistieron repetidamente, incluso a través de HackerOne, y la vulnerabilidad seguía siendo reproducible al menos en la versión 3.2.16, verificada el 30 de abril de 2026. Si las cifras son correctas, son más de seis meses y más de 197 versiones sin corrección.
Hoy, 15 de julio de 2026, la noticia ya no es fresca como “acaban de encontrarla”, sino más bien un análisis ejemplar de cómo la divulgación completa se convierte en la última defensa cuando el proveedor se demora. Cursor declaró a Dark Reading que están “abordando” el problema, pero el hecho mismo de la divulgación pública dice mucho sobre el proceso de respuesta.
Qué cambia para el negocio y la automatización
Pierden los equipos que abren repositorios externos en las máquinas Windows de producción de los desarrolladores sin aislamiento. Ganan quienes desde hace tiempo separan entornos confiables de los no confiables y mantienen la automatización de IA y las herramientas de desarrollo dentro de límites de políticas.
Mi conclusión práctica es simple: todos los IDE e agentes de IA deben incluirse en el mismo modelo de amenazas que el navegador, el correo electrónico y el cliente RDP. Si un desarrollador trae código del exterior, necesita un sandbox, y en Windows, al menos AppLocker o Windows App Control.
Y sí, esto afecta no solo a la seguridad, sino a la arquitectura de procesos. Revisaría dónde reside exactamente su integración de IA para el desarrollo, quién puede abrir proyectos externos localmente y qué binarios pueden ejecutarse desde el espacio de trabajo.
Si su equipo ya depende de Cursor, Copilot, agentes y herramientas internas, no esperaría la próxima historia similar. En Nahornyi AI Lab ayudamos precisamente a construir la automatización de IA y las restricciones de protección para que los desarrolladores no pierdan velocidad y el negocio no pague por una carpeta abierta accidentalmente. Si lo desea, revisemos juntos su entorno y armemos un esquema sólido sin magia innecesaria.