Cero-day en Cursor: por qué la divulgación total terminó siendo la única medida de protección

 (mindgard.ai)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Cursor para Windows ejecuta automáticamente git.exe desde la raíz del espacio de trabajo al abrir un proyecto, por lo que se puede ejecutar código arbitrario sin interacción del usuario con solo abrir un repositorio que incluya un binario malicioso
  • El alcance de búsqueda de la ruta de Git incluye el interior del repositorio, y no solo ejecuta archivos sin advertencia ni aprobación, sino que además los vuelve a ejecutar periódicamente mientras el proyecto permanezca abierto
  • Mindgard lo reportó el 15 de diciembre de 2025 y completó la reproducción y entrega a través de HackerOne, pero después de más de 6 meses y más de 197 versiones nuevas, el problema seguía presente en la versión de prueba más reciente
  • Los entornos Windows administrados deben aplicar reglas de denegación basadas en rutas con AppLocker o Windows App Control, y los usuarios comunes deben abrir repositorios no confiables en una VM o en Windows Sandbox hasta que haya un parche
  • Mindgard concluyó que el proceso de divulgación coordinada no podía reducir el riesgo para los usuarios, por lo que publicó todos los detalles, y sostiene que al elegir herramientas de desarrollo con IA también debe evaluarse la capacidad de respuesta y comunicación en seguridad del proveedor

git.exe se ejecuta con solo abrir un repositorio

  • Cursor busca binarios de Git en varias ubicaciones al cargar un proyecto, y entre esos lugares está el espacio de trabajo actual
  • Si un atacante coloca un git.exe malicioso en la raíz del repositorio, Cursor lo ejecuta automáticamente sin advertencia, cuadro de aprobación ni clic adicional
  • El ataque comienza con solo que el desarrollador abra ese proyecto; no se necesitan prompt injection, manipulación del modelo, jailbreak, corrupción de memoria ni cadenas de explotación complejas
  • El código ejecutado corre con el mismo nivel de privilegios del usuario actual de Cursor

Proceso de reproducción y registros de ejecución repetida

  • Para una prueba de concepto segura, Mindgard colocó Windows Calculator en la raíz del repositorio con el nombre git.exe
  • Al abrir el repositorio en Cursor, Calculator se ejecutó, y al dejar el proyecto abierto siguieron apareciendo más ventanas
    • El investigador no abrió manualmente varias ventanas
    • No fue un evento único al inicio, sino el resultado de que el ejecutable del espacio de trabajo se volvía a ejecutar periódicamente durante el uso normal
  • En un ataque real, en lugar de Calculator podría colocarse código controlado por el atacante
  • Los registros de Sysinternals Process Monitor muestran que Cursor.exe ejecutó git.exe dentro del repositorio y le pasó el siguiente comando
git rev-parse --show-toplevel
  • La última verificación se realizó el 30 de abril de 2026 en Cursor 3.2.16 para Windows

Una vulnerabilidad presente en una base masiva de usuarios

  • Cursor es un entorno de desarrollo asistido por IA usado a esta escala
    • más de 7 millones de usuarios activos
    • más de 1 millón de usuarios diarios
    • más de 1 millón de usuarios de pago
    • más de 50 mil empresas usuarias
  • Su valor de mercado reportado es de 60 mil millones de dólares
  • Mindgard descubrió la vulnerabilidad el 15 de diciembre de 2025 y la reportó ese mismo día
  • Al momento de escribir, después de más de 6 meses y más de 197 versiones nuevas, la vulnerabilidad seguía presente en la versión de prueba más reciente
  • El texto sobre la respuesta también indica que, mientras seguían lanzándose funciones y anuncios, se publicaron más de 70 versiones sin que el problema se resolviera
  • Una vulnerabilidad de ejecución remota de código simple y fácil de reproducir permaneció sin solución durante meses, afectando tanto a personas como a organizaciones que desplegaron Cursor

Mitigaciones temporales antes del parche

  • En sistemas Windows administrados, se puede bloquear ese nombre de ejecutable dentro de directorios de espacios de trabajo de desarrollo con políticas de AppLocker o Windows App Control
  • Como el hash puede cambiar entre binarios, para este caso son más adecuadas las reglas de denegación basadas en rutas, limitadas a la raíz del repositorio o del espacio de trabajo, que una lista de bloqueo basada en hash
%USERPROFILE%\\source\\repos\\*\\filename.exe
  • Windows no incluye una regla general integrada para bloquear un ejecutable hijo arbitrario solo cuando lo lanza un proceso padre específico
    • Para controles que reconozcan el proceso padre se necesita un EDR o un producto de seguridad de endpoint personalizado
  • Los usuarios comunes deben abrir repositorios no confiables solo en una VM aislada, Windows Sandbox o un entorno desechable hasta que el IDE sea parchado
  • Como el hash puede cambiar cada vez que se modifica el binario, no se debe confiar en listas de bloqueo por hash de archivo para esta vulnerabilidad

El proceso coordinado se detuvo tras el reporte

  • El reporte inicial se envió al correo de seguridad indicado en el security.txt de Cursor, pero no hubo acuse de recibo
  • Mindgard intentó encontrar al responsable adecuado de seguridad mediante correos de seguimiento y una solicitud pública de contacto
  • El CISO de Cursor respondió que el proceso previsto en HackerOne no había comenzado por una falla en la automatización interna, e invitó manualmente a Mindgard al programa privado de bug bounty
  • El reporte reenviado a HackerOne fue cerrado inicialmente como Informative y fuera de alcance
    • Mindgard objetó esa clasificación
    • Después de que HackerOne reprodujo el problema, el reporte fue reabierto y se confirmó que los detalles habían sido entregados a Cursor
  • Después de eso, no hubo respuestas significativas pese a solicitudes de actualización, escalaciones por HackerOne y contacto directo con el CISO y ejecutivos de Cursor
  • Mindgard no recibió evidencia de que la corrección hubiera comenzado, de que el equipo de ingeniería estuviera investigando ni de que el riesgo se hubiera comunicado a los usuarios afectados

Cronología desde el reporte hasta la divulgación total

  • 15 de diciembre de 2025

    • Mindgard descubre la vulnerabilidad
    • La reporta a security-reports@cursor.com

  • 18 de diciembre de 2025

    • Envía un seguimiento para solicitar confirmación de recepción

  • 13 de enero de 2026

    • Publica en LinkedIn para encontrar un contacto en Cursor
    • En los comentarios, un usuario identifica al CISO de Cursor

  • 15 de enero de 2026

    • El CISO de Cursor informa una falla en la automatización de la invitación privada de bounty en HackerOne e invita manualmente a Mindgard
    • Mindgard envía la vulnerabilidad a través de HackerOne

  • 16 de enero de 2026

    • El reporte se cierra como Informative y fuera de alcance
    • Mindgard objeta la decisión
    • Tras reproducirse con éxito, el reporte se reabre

  • 20 de enero de 2026

    • HackerOne confirma que entregó el reporte a Cursor

  • 16 de febrero y 3 de marzo de 2026

    • Mindgard pide actualizaciones, pero no recibe respuesta

  • 17 de marzo de 2026

    • Solicita una actualización directamente al CISO de Cursor

  • 18 de marzo de 2026

    • HackerOne informa que contactó a Cursor

  • 1 de abril de 2026

    • Mindgard vuelve a pedir una actualización, pero no recibe respuesta
    • HackerOne también confirma que no recibió ninguna actualización de Cursor

  • 1 de junio de 2026

    • Mindgard informa a HackerOne su intención de publicar

  • 3 de junio de 2026

    • HackerOne proporciona lineamientos de divulgación

  • 14 de julio de 2026

    • Publica el post con los detalles de la vulnerabilidad

Por qué la divulgación coordinada no terminó protegiendo a los usuarios

  • La divulgación coordinada normalmente sigue esta secuencia: reporte, diálogo, discusión de severidad, investigación de ingeniería, desarrollo de la corrección, protección a usuarios y publicación
  • Este proceso funciona cuando todas las partes comparten el objetivo de reducir el riesgo
  • En este caso, durante 7 meses no hubo participación significativa del proveedor, por lo que nunca se llegó a la etapa de reducción del riesgo
  • Las plataformas grandes y de cambio rápido pueden tardar en corregir, pero cuando pasan meses sin comunicación, actualizaciones ni progreso visible, seguir esperando se vuelve difícil
  • Para el investigador solo quedaban dos opciones
    • guardar silencio y dejar que los usuarios siguieran trabajando bajo la falsa premisa de que estaban seguros
    • divulgar la información para que las organizaciones pudieran entender el riesgo y decidir cómo responder
  • Mindgard optó por la divulgación total como último recurso cuando todas las demás vías fallaron

Preguntas que deja el bug bounty y la respuesta de seguridad en IA

  • Sobre las causas del retraso, el texto plantea estas posibilidades
    • si los programas modernos de bug bounty están sobrecargados
    • si modelos con capacidades elevadas, como Mythos, han hecho imposible absorber el volumen de reportes
    • si Cursor redujo la prioridad de la seguridad del usuario mientras se enfocaba en la adquisición por parte de SpaceX
    • si, con miles de millones de dólares en juego, la seguridad real del usuario sigue siendo una prioridad
  • Con la expansión de los productos de IA, la cantidad de hallazgos de seguridad está aumentando con fuerza, y muchos de ellos no encajan limpiamente en las clasificaciones de vulnerabilidades existentes
  • Los procesos de clasificación y recepción en los que se ha confiado durante casi 20 años están fallando rápidamente a medida que en el entorno de IA se rompen sus supuestos de base
  • Si el pipeline de divulgación está sobrecargado, la industria debería decirlo con transparencia para que investigadores, clientes y usuarios puedan evaluar la situación
  • Las empresas de rápido crecimiento deben corregir sus fallas de seguridad y, al mismo tiempo, tratar a los usuarios como clientes valiosos, no como sujetos de experimento de compra

Condiciones para confiar en herramientas de desarrollo con IA

  • Las empresas de IA piden un nivel de acceso sin precedentes a código, repositorios, terminales, secretos y flujos de trabajo, y además el límite entre sugerencia y ejecución se está volviendo cada vez más difuso
  • Los usuarios están confiando a software de producción su código fuente, credenciales, propiedad intelectual exclusiva y funciones cada vez más autónomas
  • No se debe confiar en un sistema solo porque mejore la productividad; la confianza debe ganarse mediante la respuesta a reportes de seguridad, la comunicación con usuarios afectados y la priorización de correcciones
  • La confianza requiere responsabilidad, y la responsabilidad requiere comunicación, pero cuando usuarios, investigadores y plataformas públicas no reciben ni siquiera actualizaciones básicas de estado durante meses, resulta difícil verificar esa responsabilidad
  • Mindgard publicó todos los detalles para dar a las organizaciones la oportunidad de evaluar su exposición, aplicar controles compensatorios y juzgar la postura de seguridad
  • Cuando seguir ocultando la información ya no protege a los usuarios sino solo al silencio, incluso si es incómodo debe priorizarse la seguridad del usuario

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones de Hacker News

  • Desde la perspectiva de quienes reciben reportes de seguridad, están llegando en volúmenes inmanejables reportes de baja calidad generados por LLM, que por lo general no entienden el diseño del producto ni el alcance de seguridad. De vez en cuando también hay reportes muy buenos, así que hay que revisarlos todos manualmente, pero enviar más “justificación” extensa generada por un LLM no es la solución, y este texto también parece estar escrito en su mayor parte por un LLM.
    En este caso, si se trata de poner un binario malicioso en un entorno donde el software puede ejecutar código o binarios arbitrarios, parece más cercano a la responsabilidad de aislar y proteger el espacio de trabajo, salvo que Cursor diga que también se hará responsable de la seguridad del entorno del usuario.
    Al crear reportes CVE con un LLM, ojalá se use para el proceso de reproducción determinista, y que el texto principal se escriba directamente y de forma concisa, quitando los adjetivos innecesarios y las exageraciones típicas de los LLM.

    • Un binario no debería ejecutarse automáticamente dentro de un repositorio recién clonado solo porque se abrió con Cursor.
    • La variable PATH existe precisamente para controlar este tipo de problema. Si entendí bien, Cursor agrega de inmediato el repositorio al PATH sin aprobación del usuario.
    • No hay una solución fácil y, si la seguridad importa, hay que asignar más personal de revisión acorde al entorno cambiado. Agregar otra capa de revisión con LLM no lo va a resolver.

  • La raíz del problema está en que Cursor no trata la clonación de repositorios y la ejecución de código como fronteras de seguridad distintas. Cursor desactiva Workspace Trust de forma predeterminada[0], y basta con abrir un repositorio que tenga "runOn": "folderOpen" en .vscode/tasks.json para que ya se ejecute código arbitrario[1].
    [0] https://cursor.com/docs/agent/security#workspace-trust
    [1] https://www.oasis.security/blog/cursor-security-flaw

  • Mindgard dice que descubrió la vulnerabilidad por primera vez el 15 de diciembre de 2025 y la reportó ese mismo día y varias veces después, pero que sigue presente en la versión más reciente de Cursor incluso después de 6 meses y más de 197 versiones nuevas.
    Al principio se cerró como un reporte informativo o fuera de alcance; tras una apelación, HackerOne lo reabrió, lo reprodujo y se lo pasó a Cursor, pero luego no hubo respuesta a solicitudes de actualización, preguntas adicionales, escalamiento vía HackerOne ni contactos enviados a la dirección de Cursor. Es difícil entender por qué Cursor responde así.

    • El proceso de gestión de CVE en sí está roto. Con el avance de la IA agéntica, en HackerOne y en los programas corporativos de divulgación de vulnerabilidades aumentaron al mismo tiempo los reportes de baja calidad y los reportes realmente excelentes; como la misma IA puede escribir ambos, es casi imposible distinguirlos solo por la superficie.
      Como resultado, las empresas ya no responden como antes, y en una conferencia de ciberseguridad de junio también predominaba la idea de que la divulgación responsable está muerta o muriendo, por lo que conviene más hacerlo público. Se citaban con frecuencia los casos de Microsoft y Nightmare Eclipse.
    • También surge la posibilidad de que sea una puerta trasera intencional. Si la NSA o el FBI ponen git.exe en un repositorio dirigido a un objetivo y logran que el objetivo lo clone, el payload podría ejecutarse.
      Dado que Cursor está basado en VS Code, me pregunto si lo mismo ocurre también en VS Code.

  • Es difícil estar completamente de acuerdo en que esto sea una vulnerabilidad crítica. Para explotarla realmente, el atacante primero tendría que poner un ejecutable malicioso llamado git.exe en la carpeta de código del usuario, lo cual se parece a llamar vulnerabilidad a modificar .bashrc para crear un alias que haga que ls ejecute /tmp/mega-big-virus.sh.
    Sí es una ruta de ataque, pero si ese archivo ya entró al sistema de archivos, puede considerarse que ya hubo una intrusión previa.

    • Uno podría infectarse solo por clonar un repositorio de GitHub y abrirlo en Cursor, el editor predeterminado. Es como cuando al insertar un CD se ejecutaba autorun.exe e infectaba Windows.
      Se podría decir que el usuario debe inspeccionar manualmente en un entorno aislado todos los archivos del repositorio y binarios sospechosos como git.exe, pero en la realidad esto no lo controla el usuario sino una política de seguridad que impide la ejecución automática, y Cursor debería desactivarla del mismo modo.
    • A diferencia de .bashrc, las carpetas de código suelen venir de fuentes no confiables. No debería permitirse la ejecución de código arbitrario solo porque alguien abrió un proyecto de GitHub para revisarlo.
      Dicho eso, en los IDE principales esa frontera ya se rompió hace mucho, y las funciones remotas de SSH y devcontainer de VS Code también permiten ejecución remota de código por diseño.
    • Desde el primer párrafo de la página se dice claramente, en dos frases, que después de abrir un proyecto Cursor busca el binario de Git en varias ubicaciones, incluido el espacio de trabajo actual, y que si se coloca un git.exe malicioso en la raíz del repositorio, lo ejecuta sin entrada ni confirmación del usuario. No es un texto que oculte el comportamiento central.
    • Con solo clonar un repositorio y abrirlo en el IDE, en la práctica se le concede al dueño del repositorio permiso de ejecución remota de código, y es difícil verlo como un contrato implícito incluido en la acción de abrir una carpeta.
    • Hace 30 años ya existían los ataques de orden de búsqueda de DLL, donde se ponía una DLL alternativa infectada en una carpeta de MP3 o fotos para que Winamp o el visor de fotos de Windows la cargaran; este caso es muy parecido.

  • Es extraño que Cursor ejecute archivos arbitrarios sin confirmación, y también preocupa que los investigadores no hayan recibido una respuesta adecuada durante meses.
    Aun así, el ejemplo de ejecutar la calculadora puede resultar algo engañoso. Entiendo que el ejecutable malicioso ya tendría que estar descargado en el sistema y, si Cursor intenta ejecutarlo, las ACL entrarían en acción y pedirían permiso para ejecutar por primera vez una app nueva sin firmar. Para una explotación real, quizá las ACL tendrían que estar completamente desactivadas.

    • Si el cuadro de confirmación dice “¿Desea ejecutar git.exe?”, es muy probable que el usuario piense que Cursor necesita Git y que la configuración de permisos está mal, y lo apruebe tal cual.
    • Lo mismo podría pasar si se usa un PS1 que muestra la rama actual de Git y se incluye el directorio actual en PATH. En ese caso, me pregunto si también habría que enviarle a Bash un CVE de alto riesgo.

  • Más que un bug exclusivo de Cursor, parece estar relacionado con el orden de búsqueda propio de Windows, que busca ejecutables en el directorio de trabajo actual antes de revisar el PATH. Es muy probable que muchos programas en Windows estén expuestos a ataques similares.

    • El software que se preocupa por la seguridad ya corrigió este problema.
      Como se explica en https://go.dev/blog/path-security, Command y LookPath buscan programas en los directorios listados en el PATH actual según las convenciones del sistema operativo, pero hoy en día el comportamiento de incluir el directorio actual suele ser inesperado y deriva en problemas de seguridad.
      https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
    • Se puede mitigar fácilmente buscando el ejecutable real de Git en rutas conocidas del sistema o permitiendo que el usuario configure la ruta; hasta donde sé, VS Code también lo maneja de esa forma.
    • Es una trampa de seguridad antigua y bien conocida contra la que hay que protegerse obligatoriamente al desarrollar software para Windows.
    • Entonces, al final suena a que la versión de Cursor para Windows sí tiene un bug y una vulnerabilidad.

  • Es demasiado común que las empresas no prioricen la seguridad, y aunque es lamentable, en parte se puede entender. También se entiende que una startup de seguridad, cansada de esperar, termine divulgándolo para recuperar aunque sea parte del costo invertido mediante efecto publicitario, y hay momentos en los que la divulgación pública de vulnerabilidades es necesaria.
    Dicho eso, si realmente querían ayudar a resolverlo, parece que podían haber hecho más que insistir en HackerOne y enviarle un mensaje de LinkedIn al CISO una vez. Ahora queda un sabor amargo, como si a nadie le importara de verdad.

    • No queda claro qué sería ayudar de verdad a resolverlo, ni cuáles son exactamente los costos hundidos a los que se refiere aquí. En general suena demasiado ambiguo.

  • Me pregunto por qué Cursor ejecuta automáticamente ejecutables y qué flujo de toma de decisiones llevó a este comportamiento. Vim también tuvo problemas al ejecutar código inesperado al cargar archivos por funciones explícitas como %{expr}, pero cuesta entender por qué Cursor busca específicamente git.exe y a quién beneficia esa función.
    Incluso sin haber usado Cursor, me da curiosidad por qué existe un CVE duplicado que parece poder corregirse de forma sencilla.

    • Un flujo común es pedirle a Cursor que resuma un repositorio existente y escriba un README; Cursor lee el repositorio y el código, y luego ejecuta comandos de Git para ofrecer también metadatos como la rama de desarrollo o tags anteriores.
      El problema es que, cuando se le pide evaluar un repositorio remoto, después de clonarlo, si ejecuta git ... desde el directorio de trabajo, Windows puede decidir que el archivo git que está en ese directorio es el ejecutable. También se puede ejecutar código de inmediato al cambiar a un repositorio no confiable o a una rama comprometida.
      La solución habitual es usar la ruta completa del Git instalado en el sistema; aunque sea molesto para una persona escribirla, para Cursor es una tarea trivial.
    • Parece que la intención es que el agente integrado encuentre el Git real del usuario para leer contexto en varias ramas y worktrees. Hay formas más seguras, pero este tipo de pequeño atajo es fácil que salga mal en flujos de trabajo asistidos por IA, y también es un punto donde es fácil que las alertas se pasen por alto en la clasificación de bugs con IA.

  • Como es común darles a los agentes de desarrollo permisos para traer y subir repositorios Git, esto se convierte en una enorme ruta de ataque a la cadena de suministro. Si un agente de Cursor en ejecución trae los archivos más recientes y un atacante dejó un ejecutable dentro del proyecto, de pronto cientos de miles de personas podrían ejecutar un EXE arbitrario con permisos de usuario normales.

  • El reporte se lee un poco como un texto escrito por IA. Para explotarlo, el payload malicioso ya tendría que estar en la PC mediante clonación, descarga, etc., así que entiendo la gravedad, pero uno esperaría no quedar en esa situación desde el principio.

    • Los agentes de coding modernos, cuando se les pregunta por una API con documentación poco clara, a veces clonan el repositorio y leen el código, por lo que esta vulnerabilidad sí es explotable en la práctica.
    • El payload malicioso puede estar en un repositorio remoto. Basta con hacer git clone del repositorio y abrirlo con Cursor para que la compromisión quede completa.
    • Si eres desarrollador open source, también podrías recibir un pull request que incluya git.exe.
    • Normalmente no se piensa que descargar un repositorio para ver el código fuente sea lo mismo que activar un payload malicioso, y justamente eso es lo preocupante. Aunque moleste el estilo de IA, habría que criticar el contenido de la vulnerabilidad más que la forma en que está escrito.
    • Es difícil afirmar que el payload tenga que estar previamente en la PC. Si mediante prompt injection se puede inducir un comando como download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;), existe la posibilidad de que el agente descargue y ejecute git.exe.