Si abre un repositorio con Cursor en Windows y existe un archivo llamado git.exe en la raíz del proyecto, Cursor lo ejecutará. No hay clics, ni cuadros de diálogo de aprobación, ni advertencias de que algo en la carpeta está a punto de ejecutarse.
Independientemente de lo que haga ese binario, funciona igual que usted, utilizando sus fuentes, claves SSH y tokens de nube. El cursor seguirá reproduciéndose mientras el proyecto esté abierto.
Sin inyecciones inmediatas, sin agentes, sin modelos en bucle, sin acceso previo a la máquina. Simplemente abrir la carpeta completa el exploit, lo que resulta en la ejecución de código arbitrario por parte del usuario que inició 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 siete meses después, el martes. Aún no existe ningún parche y Cursor no ha publicado ningún aviso sobre este problema.
Este mecanismo tarda aproximadamente una frase. Cuando se carga un proyecto, el cursor busca en varias ubicaciones los archivos binarios de Git. Uno de ellos es el propio espacio de trabajo. La salida de Process Monitor en este artículo muestra Cursor.exe generando el binario raíz del repositorio usando la línea de comando git rev-parse –show-toplevel.
Esta es la misma sonda raíz del repositorio descrita en la documentación de VS Code de Microsoft. El artículo no dice si Cursor busca esas ubicaciones por sí mismo o pasa un git no calificado a Windows y le permite elegir el orden de búsqueda.
La prueba de concepto de Mindgard es la Calculadora de Windows, renombrada a git.exe y comprometida con la raíz. Clonalo, ábrelo y listo. La captura de pantalla muestra cómo las ventanas de la calculadora se acumulan automáticamente con el proyecto aún abierto.
Los requisitos previos parecen la parte difícil. Esto significa que los archivos binarios del atacante residen en la raíz del proyecto. que no es. Clonar el repositorio de un extraño es la forma en que los archivos binarios se guardan en el disco, y los desarrolladores y sus agentes lo hacen durante todo el día. Para empezar, los atacantes no necesitan un punto de apoyo. Esto es lo que cubre este error. Desde el repositorio, cualquiera puede publicar código que se ejecute como usted.
Hay una limitación de la evidencia. La última fecha confirmada por Mindgard es el 30 de abril de 2026 para Cursor 3.2.16, y la versión actual es 3.11, enviada el 10 de julio. El artículo dice que el error permanece en la última versión que probó, pero no menciona la versión.
Hacker News revisó los 33 avisos de seguridad publicados por Cursor y no encontró entradas que cubran este tema hasta el 15 de julio. No hay CVE asignados. Le pregunté a Cursor el nombre de la versión que lo soluciona y a Mindgard la última versión que probaron. Esta historia se actualizará si hay una respuesta.
que hacer
No existe ningún parche, por lo que todas las opciones siguientes son soluciones alternativas. Para flotas de Windows administradas, Mindgard sugiere reglas de denegación de AppLocker o Windows App Control que bloquean archivos ejecutables con nombres y rutas en la raíz del espacio de trabajo, como %USERPROFILE%\source\repos\*\filename.exe.
Reglas de ruta en lugar de hashes. El binario del atacante depende del hash. La compañía señala que la aplicación consciente de los padres generalmente significa EDR porque Windows no tiene una regla general incorporada para bloquear un proceso secundario solo si un padre en particular lo inicia. Todos los demás: abran un repositorio que no sea de confianza en una máquina virtual desechable o en un entorno limitado de Windows.
Combine esto con el consejo de Cymulate de verificar antes de abrir un repositorio clonado o un archivo extraído. git.exe, npx.exe, node.exe y where.exe no están relacionados 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 indica que la empresa permite «informes de vulnerabilidad dentro de los cinco días hábiles». La primera respuesta sustancial de Mindgard se produjo un mes después de un informe de diciembre del CISO de Cursor que explicaba que la automatización impedía que la empresa fuera invitada al programa privado HackerOne.
El informe reenviado se cerró al día siguiente por no ser informativo y estar fuera de alcance, pero se reabrió después de que Mindgard objetó y HackerOne lo reprodujo. HackerOne confirmó la entrega el 20 de enero. Luego se realizaron solicitudes de actualización en febrero, marzo y abril, pero no se devolvió nada.
El registro de asesoramiento de Cursor, leído en comparación con la línea de tiempo de Mindgard, muestra que el proceso estaba funcionando para otros investigadores mientras que el informe de Mindgard quedó desatendido. El 13 de febrero de 2026, Cursor publicó GHSA-8pcm-8jpx-hv8r. Este es un escape de entorno aislado de Git Hook (CVE-2026-26268) reportado bajo divulgación coordinada por Novee y corregido en Cursor 2.5. Tres días después, el 16 de febrero, Mindgard solicitó una actualización de sus propios informes relacionados con Git. Ninguna respuesta. Se emitieron dos avisos más de Cursor el 14 de julio, el día de la divulgación completa.
«La divulgación completa es la opción principal para la divulgación de vulnerabilidades», escribe Mindgard, y está reservada para cuando todo lo demás falla. El autor Aaron Portnoy pasó años detrás de escena. Dirigió la Iniciativa Día Cero y creó los primeros seis concursos Pwn2Own.
Mismo error con otros 3 proveedores
Mindgard no es la primera empresa en descubrir esto, ni es la primera en obtener una respuesta de Cursor. En junio, Cymulate publicó una investigación sobre clases idénticas en herramientas de inteligencia artificial. En Windows, algunas de estas herramientas resuelven ejecutables auxiliares utilizando un orden de búsqueda predeterminado que verifica el directorio de trabajo antes que las rutas confiables del sistema.
La CLI de GitHub Copilot ejecutó el espacio de trabajo git.exe al inicio antes de que se mostrara el mensaje de confianza de carpeta. Gemini CLI hizo lo mismo cuando se inició desde un espacio de trabajo. La aplicación de escritorio Codex, como Cursor, hacía eso cuando abrías una carpeta.
Hasta el artículo de Cymulate del 4 de junio, ninguno de estos proveedores había enviado una solución. GitHub priorizó y recompensó el informe, luego lo degradó a un nivel inferior. Google estuvo de acuerdo en que los hallazgos de Gemini CLI eran válidos y no lanzó ningún parche. OpenAI creyó que un atacante que podría reemplazar git.exe ya tenía acceso al sistema y cerró el informe del Codex como «No aplicable». Ese no fue el escenario reportado. Cursor cerró el informe Cursor CLI de Cymulate como informativo después de ocho días, citando una «falta de vector de ataque» en sus hallazgos que requería binarios maliciosos.
Ese estudio condujo a una modificación. AWS asignó CVE-2026-10591 como resultado del descubrimiento de Kiro, le dio crédito a Cymulate y lo parcheó en Kiro 0.11. Pero ese fue otro error. Una falla de escritura de archivos en el agente permite que un .vscode/tasks.json contaminado se ejecute automáticamente cuando se abre la carpeta. Ninguno de los informes sobre plantación binaria tuvo éxito.
Esta clase existe desde hace algún tiempo. Las rutas de búsqueda que no son de confianza son una debilidad. Implica incrustar un binario en una ubicación donde una búsqueda revela que se trata de un ataque. Windows verificar el directorio actual antes de %PATH% es lo que rompió Git Credential Manager Core en 2020 (CVE-2020-26233). Un git.exe malicioso se encuentra en el nivel superior del repositorio y se ejecuta en lugar del git.exe real durante la clonación recursiva. Corregido en GCM 2.0.289.
La PoC de Blaze Information Security en ese momento también pasó de llamarse calc.exe a git.exe. Seis años después, se realiza el mismo truco para un IDE que ejecuta una sonda en el momento en que se abre una carpeta.
Cuatro proveedores han confirmado que los archivos binarios del espacio de trabajo se ejecutan automáticamente en Windows tan pronto como un desarrollador especifica una herramienta en un repositorio clonado. Dos personas determinaron que esto no es una vulnerabilidad en absoluto. Ambos estuvieron de acuerdo en que eso era cierto, pero hasta el final del año fiscal de junio de Cymulate, no habían enviado nada de todos modos. Por lo tanto, la solicitud está del lado del defensor y es seguro para Windows tratar el repositorio clonado como contenido ejecutable. Porque eso es lo que realmente es.
Source link
