Abra un repositorio en Cursor en Windows y, si hay un archivo llamado git.exe en la raíz del proyecto, Cursor lo ejecuta. Sin clic, sin cuadro de diálogo de aprobación, sin advertencia de que algo en la carpeta está a punto de ejecutarse.
Cualquier cosa que haga ese binario, lo hace como usted, con su fuente, sus claves SSH y sus tokens de nube. El cursor sigue ejecutándolo mientras el proyecto permanezca abierto.
Sin inyección rápida, sin agente, sin modelo en el bucle y sin acceso previo a la máquina: abrir la carpeta es todo el exploit y el resultado es la ejecución de código arbitrario como usuario que ha iniciado sesión.
La empresa de seguridad de inteligencia artificial Mindgard informó la falla a Cursor el 15 de diciembre de 2025 y publicó los detalles técnicos completos el martes, siete meses después. Todavía no hay ningún parche y Cursor no ha publicado ningún aviso sobre el problema.
El mecanismo dura aproximadamente una frase. El cursor busca en varias ubicaciones un binario de Git cuando se carga un proyecto, y una de ellas es el propio espacio de trabajo. La salida de Process Monitor en el artículo muestra Cursor.exe generando el binario repo-root con la línea de comando git rev-parse –show-toplevel.
Esa es la misma sonda raíz del repositorio que describen los documentos VS Code de Microsoft. Si Cursor busca esas ubicaciones por sí mismo o le entrega a Windows un git no calificado y deja que elija el orden de búsqueda, el artículo no lo dice.
La prueba de concepto de Mindgard fue la Calculadora de Windows, renombrada como git.exe y comprometida con la raíz. Clonar, abrir y listo. La captura de pantalla muestra las ventanas de la Calculadora apilándose solas mientras el proyecto permanece abierto.
La condición previa parece la parte difícil: el binario de un atacante, ubicado en la raíz de su proyecto. No lo es. Clonar el repositorio de un extraño es la forma en que los archivos binarios llegan al disco, y los desarrolladores y sus agentes lo hacen todo el día. Para empezar, el atacante no necesita ningún punto de apoyo. Esa es la distancia que cubre este error: desde un repositorio, cualquiera puede publicar código que se ejecute como usted.
Un límite a la evidencia. La confirmación fechada más reciente de Mindgard es el 30 de abril de 2026, contra Cursor 3.2.16, y la versión actual es 3.11, enviada el 10 de julio. El artículo dice que el error sobrevive en la versión más reciente que probó, pero no nombra esa versión.
The Hacker News revisó los 33 avisos de seguridad que Cursor ha publicado y no encontró ninguna entrada que cubra el problema hasta el 15 de julio. No se ha asignado ningún CVE. Le pedimos a Cursor que nombrara cualquier versión que lo solucione y a Mindgard, qué versión probó por última vez. Esta historia se actualizará con cualquier respuesta.
Qué hacer
No existe ningún parche, por lo que todas las opciones siguientes son una solución alternativa. En flotas de Windows administradas, Mindgard sugiere reglas de denegación de AppLocker o Windows App Control que bloquean el ejecutable por nombre y ruta en las raíces del espacio de trabajo, como %USERPROFILE%sourcerepos*filename.exe.
Reglas de ruta, no hashes; Los binarios del atacante varían según el hash. Windows no tiene una regla general incorporada que bloquee un proceso secundario solo cuando un padre específico lo inicia, señala la firma, por lo que la aplicación de la ley a los padres generalmente significa EDR. Todos los demás: abran repositorios que no sean de confianza en una máquina virtual desechable o en un Sandbox de Windows.
Combínelo con el consejo de Cymulate de verificar un repositorio clonado o un archivo extraído antes de abrirlo. git.exe, npx.exe, node.exe y Where.exe no tienen nada que ver con la raíz del proyecto. Lo que pasó con el informe es el resto de la historia.
La página de seguridad de Cursor dice que la empresa reconoce “los informes de vulnerabilidad dentro de los 5 días hábiles”. La primera respuesta sustancial de Mindgard llegó un mes después del informe de diciembre, del CISO de Cursor, quien explicó que una automatización no había logrado invitar a la empresa al programa privado HackerOne.
El informe reenviado se cerró al día siguiente por ser informativo y fuera de alcance, luego se reabrió una vez que Mindgard rechazó y HackerOne lo reprodujo. HackerOne confirmó la entrega el 20 de enero. Después de eso: solicitudes de actualización en febrero, marzo y abril, y nada a cambio.
El registro de asesoramiento de Cursor, leído en comparación con la línea de tiempo de Mindgard, muestra el proceso funcionando para otros investigadores mientras se publicaba el informe de Mindgard. El 13 de febrero de 2026, Cursor publicó GHSA-8pcm-8jpx-hv8r, un escape de Git-hook sandbox (CVE-2026-26268) reportado por Novee bajo divulgación coordinada y corregido en Cursor 2.5. Tres días después, el 16 de febrero, Mindgard solicitó una actualización de su propio informe relacionado con Git. Ninguna respuesta. El 14 de julio, el día en que llegó la divulgación completa, se emitieron dos avisos más de Cursor.
“La divulgación completa es la opción nuclear de la divulgación de vulnerabilidades”, escribió Mindgard, reservándola para los casos en los que todos los demás caminos han fracasado. El autor, Aaron Portnoy, pasó años al otro lado de ese oficio: dirigió la Iniciativa Día Cero y creó los primeros seis concursos Pwn2Own.
El mismo error, otros tres proveedores
Mindgard no es la primera empresa en encontrar esto, ni la primera en obtener la respuesta de Cursor al respecto. En junio, Cymulate publicó hallazgos sobre la misma clase en todas las herramientas de IA: en Windows, varias de estas herramientas resuelven ejecutables auxiliares utilizando el orden de búsqueda predeterminado, que verifica el directorio de trabajo antes que las rutas confiables del sistema.
GitHub Copilot CLI ejecutó un espacio de trabajo git.exe al inicio, incluso antes de que se mostrara el mensaje de confianza de carpeta. Gemini CLI hizo lo mismo cuando se inició desde el espacio de trabajo. La aplicación de escritorio Codex lo hizo en una carpeta abierta, como Cursor.
Hasta el artículo de Cymulate del 4 de junio, ninguno de esos proveedores había enviado una solución. GitHub evaluó su informe y pagó una recompensa, luego lo bajó a nivel bajo. Google estuvo de acuerdo en que el hallazgo de Gemini CLI era válido y no lanzó ningún parche. OpenAI cerró el informe del Codex como No aplicable, razonando que un atacante que puede reemplazar git.exe ya tiene acceso al sistema. Ese no fue el escenario reportado. Cursor cerró el informe Cursor CLI de Cymulate como informativo ocho días después, con el argumento de que los hallazgos que requieren un binario malicioso “carecen de un vector de ataque”.
Esa investigación produjo una solución. AWS asignó CVE-2026-10591 por su hallazgo de Kiro, le dio crédito a Cymulate y lo parcheó en Kiro 0.11. Pero ese fue un error diferente: una falla de escritura de archivos del agente que permitió que un archivo .vscode/tasks.json envenenado se ejecutara automáticamente en una carpeta abierta. Ninguno de los informes de plantación binaria había producido uno.
La clase es anterior a todo esto. Una ruta de búsqueda que no es de confianza es la debilidad; Plantar un binario donde la búsqueda lo encontrará es el ataque. Windows verificar el directorio actual antes que %PATH% es lo que rompió Git Credential Manager Core en 2020 (CVE-2020-26233): un git.exe malicioso en el nivel superior de un repositorio, que se ejecuta en lugar del real durante un clon recursivo. Corregido en GCM 2.0.289.
El PoC de Blaze Information Security en aquel entonces también pasó a llamarse calc.exe git.exe. Seis años después, el mismo truco aterriza en un IDE que ejecuta la sonda por usted en el momento en que abre la carpeta.
A cuatro proveedores se les ha mostrado un binario de espacio de trabajo que se ejecuta solo en Windows tan pronto como un desarrollador apunta la herramienta a un repositorio clonado. Dos decidieron que no era una vulnerabilidad en absoluto; dos estuvieron de acuerdo en que así era y, según la cuenta de junio de Cymulate, no habían enviado nada de todos modos. Así que el llamado recae en los defensores, y en Windows, lo más seguro es tratar un repositorio clonado como contenido ejecutable, porque eso es lo que es.
