CVE-2026-26268: el agente de Cursor convierte un git checkout en ejecución de código
Un repositorio malicioso oculta un repositorio Git «bare» con un hook automático. Cuando el agente de IA de Cursor ejecuta git checkout para «explicar el código», el hook se dispara — ejecución de código arbitrario en la máquina del desarrollador, sin confirmación. Corregido en Cursor 2.5.
¿Qué es esto?
CVE-2026-26268 es una vulnerabilidad de ejecución de código arbitrario de severidad alta en el IDE asistido por IA Cursor, que afecta a todas las versiones anteriores a la 2.5. Cursor publicó el aviso (GHSA-8pcm-8jpx-hv8r) en febrero de 2026, y el investigador Assaf Levkovich (Novee Security) detalló públicamente el mecanismo el 28 de abril de 2026 (recogido por The Hacker News el 30 de abril). La vulnerabilidad tiene una puntuación CVSS de 8,1; el proveedor la clasifica como escape de sandbox a través de la configuración .git. La divulgación se coordinó con Cursor y el parche se entregó antes de la publicación.
El fallo no está en la lógica del modelo de Cursor. Es una interacción de funcionalidades de Git que se vuelve explotable en cuanto un agente de IA ejecuta comandos Git de forma autónoma dentro de un repositorio que no controla. Resultado: el código del atacante se ejecuta directamente en el equipo del desarrollador, sin diálogo de confirmación.
Cómo funciona
Dos funcionalidades legítimas de Git se combinan para crear la condición:
- Los hooks de Git son scripts que se ejecutan automáticamente ante eventos como
post-checkoutopre-commit. Residen en el directorio.gitde un repositorio, que no forma parte del árbol de archivos versionado y revisable. - Los repositorios «bare» contienen solo los datos de
.git, sin directorio de trabajo. Uno puede incrustarse dentro de un repositorio normal.
Un atacante publica un repositorio público de apariencia normal que oculta un repositorio bare con un hook malicioso. El detonante es la autonomía del agente. Según la secuencia divulgada:
- Un desarrollador clona el repositorio público y lo abre en Cursor.
- Hace una pregunta inocua — «explícame el código».
- El agente de Cursor lee el archivo
AGENTS.md/ las Cursor Rules del repositorio, que le ordenan desplazarse al repositorio bare incrustado y ejecutar ungit checkout. - El checkout dispara el hook plantado → ejecución de código.
Aquí no se reproduce ningún payload, y ninguno es necesario para entender la lección. El usuario autorizó «explícame el código», no «ejecuta el script de shell de un atacante». Pero el agente lanzó git checkout para satisfacer la petición, y el hook se ejecutó fuera de la cadena de razonamiento del agente y fuera del campo de visión del usuario. El agente nunca informó de haber lanzado un script: hasta donde sabía, ejecutó un comando Git rutinario.
Es el mismo patrón estructural que otras divulgaciones sobre agentes de programación: un archivo de instrucciones presente en contenido no confiable (inyección de cadena de suministro vía AGENTS.md) orienta al agente, y una acción autoaprobada o invisible convierte esa orientación en ejecución — véase el falso diálogo de aprobación de SymJack y la elusión de la allowlist de Cursor.
Por qué importa
La máquina de un desarrollador es un objetivo equivalente a producción. Contiene código fuente, claves SSH, credenciales de nube y tokens de firma, y se encuentra dentro de la red corporativa. La ejecución de código arbitrario allí suele ser el primer paso hacia un compromiso más amplio o un pivote de cadena de suministro.
Lo que hace que esta categoría sea nuevamente peligrosa es el colapso de la restricción de acción requerida. Los ataques «del lado del cliente» clásicos contra desarrolladores exigían un error deliberado: abrir un archivo malicioso, ejecutar un script, hacer clic en un enlace. Esa necesidad de acción humana era en sí misma un freno a la explotabilidad. Un agente autónomo elimina el freno. Clonar un repositorio público y hacer una pregunta ya basta para alcanzar la ejecución de código — y los flujos de trabajo asistidos por IA automatizan precisamente ese bucle a gran escala.
También amplía la superficie de auditoría. Cuando un equipo de seguridad revisa una herramienta de programación con IA, el código de la propia herramienta es solo una parte del cuadro. El contenido sobre el que opera el agente — repositorios, AGENTS.md, Cursor Rules, hooks en un árbol clonado — forma ahora parte de la superficie de ataque, y el entorno de ejecución que el agente conduce (aquí, Git) es directamente relevante para la seguridad de la herramienta.
Defensas
Cursor posee el parche específico; los defensores poseen el radio de impacto circundante y la próxima variante del patrón.
- Actualice Cursor a 2.5 o posterior. Es la remediación del proveedor para CVE-2026-26268. Siga los avisos sobre agentes de programación a su cadencia de parcheo habitual.
- Desactive o aísle los hooks de Git en repositorios no confiables. Apunte
core.hooksPatha un directorio vacío y controlado al clonar código fuera de su frontera de confianza, e inspeccione cualquier directorio.gitincrustado antes de dejar operar a un agente.git clone --no-checkoutseguido de una revisión manual evita disparar los hooks en el checkout. - Trate los archivos de instrucciones del agente como entradas no confiables.
AGENTS.md, Cursor Rules, directivas de README y similares en un repositorio clonado son controlables por el atacante. No deje que autoricen silenciosamente la navegación por el sistema de archivos u operaciones Git sobre rutas que usted no eligió. - Ejecute los agentes de programación en un sandbox. Contenedores, máquinas virtuales o usuarios restringidos limitan lo que un hook disparado puede alcanzar — credenciales, red y el resto del sistema de archivos. Mantenga los secretos fuera del entorno donde se ejecuta el agente.
- Haga visibles y revisables las acciones autónomas. Prefiera configuraciones que expongan los comandos concretos que ejecuta el agente (en particular las operaciones Git y de shell) frente a la autoaprobación. La supervisión «human-on-the-loop» de lo que se ejecutó es el control cuya ausencia explotó esta CVE.
- Abra primero los repositorios no confiables en un entorno desechable. Clone, revise y solo después lleve el código al entorno donde su agente dispone de privilegios reales.
Estado
| Elemento | Detalle |
|---|---|
| CVE | CVE-2026-26268 |
| Componente | Cursor IDE (interacción agente de IA + Git) |
| Clase | Escape de sandbox vía config .git → ejecución de código arbitrario |
| CVSS | 8,1 (alta) |
| Afectado | Cursor < 2.5 |
| Corregido en | Cursor 2.5 |
| Aviso del proveedor | Feb. 2026 (GHSA-8pcm-8jpx-hv8r) |
| Divulgación pública | 28 abr. 2026 (Novee Security) |
| Divulgación | Coordinada; corregida antes de la publicación |
El encuadre correcto no es «un fallo de Cursor». Es que la autonomía convierte funcionalidades de entorno anodinas y conocidas desde hace tiempo en rutas de ataque de un solo clic. Los hooks de Git y los repositorios bare se comportan así desde hace años; lo que cambió es un agente dispuesto a ejecutar git checkout sobre un repositorio no confiable sin supervisión humana. Toda herramienta de programación con IA que conduzca de forma autónoma un entorno local potente hereda la misma forma, y la defensa duradera consiste en considerar hostil el contenido que el agente manipula y en mantener a un humano capaz de ver lo que el agente realmente ejecutó.
Sources
- → https://novee.security/blog/cursor-ide-cve-2026-26268-git-hook-arbitrary-code-execution/
- → https://thehackernews.com/2026/04/google-fixes-cvss-10-gemini-cli-ci-rce.html
- → https://github.com/cursor/cursor/security/advisories/GHSA-8pcm-8jpx-hv8r
- → https://www.csoonline.com/article/4164250/critical-cursor-bug-could-turn-routine-git-into-rce.html