Esta semana Mindgard publicó el detalle de una vulnerabilidad en Cursor que, siendo honesto, me dejó helado. No por lo sofisticada que es, al contrario, por lo ridículamente simple que resulta. Hablamos de que un repositorio que contenga un git.exe malicioso en la raíz hace que el IDE lo ejecute automáticamente al abrir el proyecto, sin click, sin prompt, sin absolutamente nada que avise al usuario. Arbitrary code execution en su forma más plana.
Cursor no es un juguete. Son más de 7 millones de usuarios activos, 50 mil empresas pagándolo y una valuación reportada de 60 mil millones de dólares. Cuando una herramienta así tiene un bug básico de path traversal en Windows, no es un descuido menor: es un síntoma.
El bug en cuestión
El detalle técnico que publicó Mindgard es casi aburrido de leer, y eso es lo peor. Al cargar un workspace, Cursor busca binarios de Git en varias rutas, y una de esas rutas incluye el propio directorio del proyecto. Si pones un git.exe controlado por el atacante ahí, Cursor lo invoca. Punto.
La PoC que usaron fue tan inocua como reveladora: renombraron calc.exe a git.exe, lo dejaron en la raíz del repo y abrieron el proyecto. La calculadora se ejecutó sola, y se siguió ejecutando periódicamente mientras el proyecto quedó abierto. O sea: no es un one-shot accidental, es ejecución continua y silenciosa de binarios que viven dentro del código que estás revisando.
Para cualquiera que trabaje con repos externos, clones de PRs de terceros, gists que descarga, o tareas de vibe coding con la IA, esto es el escenario perfecto. Un git.exe metido en un commit aparentemente inocente basta para tomar el control de la máquina del desarrollador. Y con eso, te llevas sus credenciales, sus tokens de GitHub, sus sesiones activas y todo el código al que esa máquina tenga acceso.
Lo que realmente preocupa: el silencio
Lo que a mí me preocupa no es el bug en sí. Es la respuesta del vendor. Mindgard reportó la vulnerabilidad el 15 de diciembre de 2025, siguió todos los canales: security.txt, HackerOne, contacto directo con el CISO, LinkedIn, outreach público, y se comieron 197 versiones del producto sin tocarlo. Siete meses. Más de 70 releases con features nuevas, anuncios, celebrando la valuación, mientras la vulnerabilidad seguía ahí.
Lo más grave es el patrón: el reporte fue cerrado como Informative y fuera de scope, después reabierto cuando Mindgard lo disputó, finalmente reproducido por HackerOne, confirmado como entregado al vendor, y de ahí, silencio absoluto. Sin ETA, sin plan, sin aviso a los usuarios. El CISO reconoció internamente que un fallo de automatización rompió el flujo esperado del bug bounty. O sea, ni siquiera un sistema automatizado funcionó para una vulnerabilidad básica de RCE en una herramienta usada por millones.
Mi opinión, con la mano en el pecho
Trabajo hace años con sistemas y he visto disclosures bien hechos y desastres. Esto es un desastre. La disclosure completa fue la decisión correcta de Mindgard, pero es una decisión que no debería haber sido necesaria. Si un vendor recibe un RCE de un investigador serio, lo reproduce, lo confirma, y después lo deja pudrirse siete meses, está eligiendo priorizar el roadmap sobre la seguridad de sus usuarios. Y eso, en 2026, es inaceptable.
Lo concreto que voy a hacer yo, y que recomiendo:
- Si usas Cursor en Windows en una máquina administrada, crea reglas de AppLocker o Windows App Control que bloqueen ejecutables lanzados desde rutas de workspace tipo
%USERPROFILE%\source\repos\*\. No uses listas por hash, los binarios van a variar. - Si no tienes EDR, abre repos no confiables en una VM aislada, Windows Sandbox o un entorno desechable. Punto. Cero excepciones.
- Si tu empresa paga Cursor, presionalos por escrito pidiendo un plan de remediación y un timeline. El silencio corporativo se combate con tickets firmados, no con tweets.
- Revisa tu
~/.gitconfigy tus hooks. Sí, esto no es lo mismo, pero el hábito de desconfiar del árbol de trabajo es sano en general.
Lo que viene
Este caso se va a convertir en texto obligatorio en futuras clases de disclosure y en documentos de procurement. ¿Cuántas empresas compraron licencias de Cursor pensando que tenía un mínimo de higiene de seguridad? Todas, probablemente. La lección operativa es simple: la popularidad de una herramienta de IA no es evidencia de su seguridad. La cantidad de usuarios no reemplaza al bug bounty funcionando, ni al vendor respondiendo. Y para los que estamos al otro lado, la única defensa real es asumir que cualquier clon, cualquier PR, cualquier repo externo es hostil hasta que se demuestre lo contrario.
Siete meses, 197 versiones, y un binario en la raíz del repo. Eso es todo lo que se necesitó para exponer a millones. Y eso es todo lo que necesitabas saber hoy.
Fuente de inspiración: Cursor 0day: When Full Disclosure Becomes the Only Protection Left
