Cursor tiene un agujero de seguridad crítico desde 2025 — y la empresa se negó a parchearlo

Imagina esto: descargas un repositorio de GitHub, lo abres en tu editor de código favorito, y sin hacer clic en nada, sin aceptar ningún permiso, ese repositorio ejecuta código malicioso en tu computadora.

No es un escenario hipotético. Es exactamente lo que pasa con Cursor IDE, el editor de código con IA más popular del momento, valorado en $60 mil millones, con 7 millones de usuarios activos y más de un millón de suscriptores de pago.

El equipo de seguridad de Mindgard descubrió la vulnerabilidad en diciembre de 2025. La reportaron inmediatamente a Cursor a través de su canal oficial de seguridad. Siete meses después — y 197 versiones nuevas después — el bug sigue ahí, sin parche, sin respuesta.

Así de simple es el exploit

No estás leyendo sobre una vulnerabilidad compleja que requiere ingeniería social, jailbreak de modelos de IA o una cadena de exploits sofisticada. Esto es más básico y por eso más aterrador.

Cursor busca binarios de git en varias ubicaciones cuando abres un proyecto. Una de esas ubicaciones es la raíz del proyecto mismo. Si alguien crea un repositorio con un git.exe malicioso en la raíz, Cursor lo ejecuta automáticamente. Sin preguntar. Sin dialogo de advertencia. Sin necesidad de que el usuario haga clic en nada.

Como dice Aaron Portnoy, el investigador de Mindgard que encontró el bug: "A veces la investigación de seguridad descubre vulnerabilidades profundamente técnicas que requieren páginas de explicación. Este no es uno de esos casos."

El impacto es devastador: un atacante puede publicar un repositorio de código abierto con apariencia legítima, y cualquier desarrollador que lo abra en Cursor en Windows quedará totalmente comprometido sin saberlo.

El silencio ensordecedor de Cursor

Mindgard reportó el bug el 15 de diciembre de 2025. Esto es lo que pasó después:

• Día 0: Reportan por correo electrónico, siguiendo el security.txt oficial de Cursor.
• Sin respuesta. Envían seguimientos. Silencio.
• Buscan contacto público. Intentan identificar a la persona de seguridad correcta.
• El CISO responde. Finalmente, el CISO de Cursor dice que un error interno de automatización impidió que el reporte entrara al flujo de HackerOne.
• Los invitan al bug bounty privado. Mindgard reenvía el reporte. HackerOne lo reproduce y confirma el bug.
• HackerOne lo cierra como "Informativo — fuera de alcance". Mindgard apela. Reabren.
• Y entonces... nada. Cursor deja de responder por completo.

Mindgard siguió insistiendo durante meses. Cero respuestas. Mientras tanto, Cursor seguía lanzando versiones — más de 70 releases con nuevas funcionalidades, anuncios, campañas de marketing — mientras el agujero de seguridad seguía abierto.

Como era de esperarse, Mindgard optó por full disclosure: publicó todos los detalles del 0day para que los usuarios puedan protegerse. Es la única herramienta que le queda a un investigador cuando una empresa decide ignorar un bug crítico durante siete meses.

No es un problema teórico

Algunos comentaristas en Hacker News señalaron que el exploit requiere que el atacante ya tenga un ejecutable malicioso en tu sistema. Es cierto — pero también es cierto que clonar un repositorio de GitHub es la actividad más común del mundo para un desarrollador.

Cada día, millones de desarrolladores clonan repositorios de código abierto sin pensarlo dos veces. Dependencias de npm, paquetes de PyPI, forks de proyectos populares, PRs de contribuyentes desconocidos. Cualquiera de esos vectores puede entregar un git.exe malicioso.

Y Cursor lo ejecuta sin preguntar. Automáticamente. En bucle.

El investigador dclowd9901 lo resumió perfectamente en HN: "Esto me hace recordar el diálogo que se abre cuando abres un nuevo proyecto en Cursor (y también en VSCode), donde el IDE pregunta si confías en el proyecto. ¿Cursor cree que esa es protección suficiente?"

Qué deberías hacer ahora mismo

Hasta que Cursor decida parchear esto (y no hay señales de que vaya a hacerlo), estas son tus únicas protecciones:

• No abras repositorios no confiables en Cursor en Windows. Si necesitas revisar el código de un proyecto desconocido, usa una máquina virtual aislada o Windows Sandbox.
• Administradores de sistemas: Usa AppLocker o Windows App Control para bloquear la ejecución de git.exe desde directorios de workspace. Reglas basadas en ruta (%USERPROFILE%\source\repos\*\git.exe) en vez de hash, porque el atacante cambia el binario.
• Considera usar VS Code directamente hasta que Cursor resuelva esto. No tiene la misma funcionalidad de IA, pero al menos no ejecuta código malicioso sin preguntar.

Y si eres usuario de Cursor en macOS o Linux, respiras aliviado: el bug afecta solo a Windows. Pero la próxima vulnerabilidad podría no ser tan selectiva.

La lección más grande

Cursor es un producto valorado en $60 mil millones. Usado por más de 50,000 empresas. Con un equipo de seguridad que tiene CISO, programa de bug bounty en HackerOne, y página de security.txt. Todo el papeleo de una empresa que "toma la seguridad en serio".

Pero cuando llegó el momento de la verdad, todo eso fue teatro. El CISO respondió una vez y desapareció. HackerOne confirmó el bug y nadie lo miró. Siete meses después, el agujero sigue ahí.

Mindgard no quería hacer full disclosure. Los forzaron a hacerlo. Como ellos mismos dicen: "La divulgación completa es la única protección que le queda a los usuarios cuando el vendor se niega a actuar."

Cursor está recaudando otra ronda, posiblemente saliendo a bolsa. Pero su software ejecuta código arbitrario sin preguntar. Eso no es un feature — es una bomba de tiempo.

Comparte esto con todos los desarrolladores que conoces que usan Cursor. Que sepan que su "editor del futuro" tiene un agujero del tamaño de un camión desde 2025.

¿Y tú? ¿Sigues usando Cursor después de esto, o te cambias a algo más seguro?