La herramienta de edición de código de Cursor todavía ejecuta un archivo git.exe malicioso colocado en una carpeta de proyecto, una vulnerabilidad crítica de día cero que ha permanecido sin parchear durante siete meses. El error permite que cualquier ejecutable que se haga pasar por Git se ejecute automáticamente con los privilegios del usuario, exponiendo a los desarrolladores a la ejecución remota de código sin necesidad de un clic o una advertencia.

El fallo fue descubierto por el investigador de seguridad Mindgard el 15 de diciembre de 2025, se reportó el mismo día y sigue presente en la versión de julio de 2026, a pesar de más de 197 actualizaciones incrementales y una valoración de la empresa de 60.000 millones de dólares.

Cómo funciona el error

Cursor escanea el directorio de un proyecto en busca de binarios de Git en varias ubicaciones, incluyendo la raíz del repositorio. Cuando encuentra un archivo llamado git.exe, lanza el programa para proporcionar funciones de control de versiones. El lanzamiento ocurre de forma silenciosa, sin ninguna indicación en la interfaz de usuario, y hereda los permisos del usuario actual.

Un atacante que pueda añadir un archivo al repositorio puede reemplazar el binario de Git esperado con cualquier ejecutable. Mindgard demostró el efecto renombrando la Calculadora de Windows a git.exe, colocándola en un repositorio y abriendo la carpeta en Cursor. Las ventanas de la calculadora aparecieron repetidamente mientras el proyecto permaneciera abierto, una ilustración de cómo un malware real podría ejecutarse de la misma manera.

Cronología de la divulgación

  • 15 de dic. de 2025 – Mindgard envía un correo electrónico a la dirección de seguridad de Cursor con un informe completo.
  • 15 de ene. de 2026 – El director de seguridad de la información (CISO) de Cursor responde, un mes después.
  • 16 de ene. de 2026 – HackerOne, la plataforma de recompensas por errores (bug bounty) utilizada por Cursor, clasifica el informe como fuera de alcance.
  • 16 de ene. de 2026 – Mindgard proporciona una prueba de concepto, lo que lleva a HackerOne a reabrir el ticket.
  • 20 de ene. de 2026 – HackerOne confirma que Cursor ha recibido formalmente el informe.

Después del 20 de enero, los mensajes de seguimiento de Mindgard no recibieron respuesta. Cursor siguió lanzando nuevas funciones y recaudando financiación adicional, pero la vulnerabilidad permaneció en el código base.

Por qué el retraso es preocupante

El problema es un riesgo clásico de la cadena de suministro: cualquier colaborador que pueda subir un archivo a un repositorio compartido puede inyectar código malicioso que se ejecute en la máquina de cada desarrollador.

Pasos de mitigación que puede tomar ahora

Entornos empresariales de Windows

  • Implementar políticas de AppLocker o Windows App Control que bloqueen el lanzamiento de cualquier ejecutable llamado git.exe dentro de los directorios de trabajo.
  • Evite las listas de permitidos basadas en hashes; los atacantes pueden simplemente cambiar el hash del archivo manteniendo el nombre.

Desarrolladores individuales

  • Abra repositorios de fuentes no confiables únicamente dentro de una máquina virtual o Windows Sandbox.
  • No confíe en las listas de bloqueo de hashes de archivos; estas dan una falsa sensación de seguridad.

Mejores prácticas generales

  • Trate cada nuevo repositorio como un vector potencial de la cadena de suministro. Verifique la procedencia de todos los binarios antes de que se ejecuten.

El episodio subraya una lección más amplia: las herramientas de desarrollo impulsadas por IA requieren un acceso profundo al sistema, y ese acceso debe protegerse con el mismo rigor que cualquier otro software privilegiado. Cuando una vulnerabilidad de alto impacto persiste durante meses en una empresa multimillonaria, los desarrolladores reciben una señal clara para reevaluar la confianza que depositan en la plataforma.