Las herramientas de inteligencia artificial para desarrollo y CI/CD se han convertido en un objetivo prioritario para atacantes. Dos incidentes recientes, que afectan a Google Gemini CLI y a la AI‑IDE Cursor, demuestran cómo un modelo de confianza mal definido en agentes de IA puede derivar rápidamente en remote code execution (RCE) y comprometer tanto infraestructuras de CI como estaciones de trabajo de desarrolladores.
Vulnerabilidad crítica en Gemini CLI: RCE en entornos CI/CD automatizados
Investigadores de Novee Security identificaron una vulnerabilidad crítica de máxima severidad en el paquete npm @google/gemini-cli y en el flujo de trabajo de GitHub Actions google-github-actions/run-gemini-cli. El fallo permitía a un atacante remoto ejecutar comandos arbitrarios en la máquina donde se ejecutaba el agente, incluso antes de inicializar la sandbox. La vulnerabilidad ha recibido una puntuación base de CVSS 10.0, aunque todavía no cuenta con identificador CVE público.
El origen del problema estaba en el uso de Gemini CLI en modo headless, es decir, sin interacción del usuario, como ocurre típicamente en pipelines de CI/CD. En este modo, la herramienta confiaba implícitamente en el directorio de trabajo y cargaba automáticamente configuración y variables de entorno desde la carpeta local .gemini/, sin exigir confirmación ni mecanismos robustos de sandboxing. Un atacante podía introducir en un repositorio una configuración maliciosa de agente y hacerla llegar al pipeline mediante un pull request o contribuciones externas. Cuando el flujo de CI ejecutaba Gemini CLI, la configuración se aplicaba de forma automática, abriendo la puerta a RCE en el servidor de integración.
Este tipo de escenario es especialmente peligroso cuando la plataforma de CI procesa contenido no confiable (forks públicos, PR de terceros, contribuciones externas). La toma de control de un servidor de build puede derivar en ataques a la cadena de suministro de software: creación de artefactos comprometidos, inyección de puertas traseras en librerías y ataques posteriores a clientes, una amenaza que múltiples informes de la industria (incluidos los de ENISA y proveedores de seguridad de supply chain) consideran ya uno de los vectores más críticos.
Cambios de seguridad en Gemini CLI y endurecimiento del modo –yolo
Google ha modificado el modelo de confianza de Gemini CLI para mitigar el riesgo, con especial foco en usos sin interfaz. A partir de las versiones corregidas, las carpetas deben marcarse explícitamente como confiables antes de cargar configuraciones. Los equipos de desarrollo y DevOps deben revisar sus GitHub Actions y otros workflows de CI, garantizando que solo se ejecuta Gemini CLI en directorios verificados o configurando de forma explícita qué ubicaciones se consideran de confianza.
Otra mejora relevante afecta al parámetro –yolo, que habilita la aprobación automática de acciones propuestas por el agente. Anteriormente, en este modo se ignoraban las restricciones de la allowlist definidas en ~/.gemini/settings.json, permitiendo que cualquier herramienta —incluida run_shell_command, de alto riesgo— se ejecutara sin confirmación. Esto abría un vector de RCE adicional ante entradas no confiables, como issues de GitHub o solicitudes de usuarios susceptibles de prompt injection (ataques que manipulan las instrucciones que recibe el modelo).
Desde la versión Gemini CLI 0.39.1, el motor de políticas evalúa la allowlist incluso en modo –yolo. De este modo, es posible mantener la automatización en CI limitando estrictamente las acciones permitidas. Sin embargo, algunos pipelines pueden empezar a fallar silenciosamente si la lista de comandos autorizados no contempla todas las herramientas usadas en la práctica, por lo que será necesario ajustar la configuración siguiendo principios de least privilege.
Vulnerabilidades en la AI‑IDE Cursor: sandbox escape y exposición de credenciales
CVE-2026-26268: escape de sandbox mediante ganchos de Git
En paralelo, Novee Security reportó una vulnerabilidad de alta gravedad en la AI‑IDE Cursor hasta la versión 2.5, identificada como CVE-2026-26268 con una puntuación CVSS 8.1. El problema permite obtener ejecución arbitraria de código en la máquina del desarrollador mediante una combinación de prompt injection y el uso de repositorios Git especialmente preparados.
La técnica consiste en crear un repositorio «bare .git» anidado con un hook malicioso (por ejemplo, pre-commit), que se disparará automáticamente en cada operación de commit. Cuando el agente de IA de Cursor, actuando «en nombre del usuario», ejecuta comandos como git checkout o flujos habituales de Git en ese repositorio, el hook se ejecuta fuera de la visibilidad del usuario y del propio agente, pero con los permisos del usuario local. La raíz del problema no es un fallo específico de Git, sino la interacción insegura entre capacidades de Git y agentes autónomos de IA en entornos donde no se controla plenamente el origen del código.
CursorJacking: extensiones con acceso a API keys y tokens de sesión
Un segundo hallazgo, descrito por investigadores de LayerX y bautizado como CursorJacking, expone otra superficie de alto riesgo en Cursor (CVSS 8.2). La vulnerabilidad reside en la ausencia de límites de acceso estrictos entre las extensiones instaladas y la base de datos local SQLite donde la aplicación almacena claves de API, tokens de sesión y otras credenciales sensibles. Cualquier extensión con acceso al sistema de archivos local puede leer esta base de datos y, con ello, potencialmente:
- secuestrar cuentas mediante el uso de tokens de sesión;
- invocar servicios backend de Cursor haciéndose pasar por el usuario;
- abusar de APIs de pago, generando costes inesperados;
- extraer datos de proyectos y el historial de interacción con la IA.
Según los datos publicados, la vulnerabilidad sigue sin corregirse. Los desarrolladores de Cursor señalan que el ataque requiere acceso local y una extensión instalada con permisos concedidos por el propio usuario. En la práctica, esto implica que cualquier extensión maliciosa o comprometida puede utilizar este vector no solo contra Cursor, sino también como puerta de entrada para acceder a otros almacenes locales de credenciales en el sistema.
Lecciones clave y recomendaciones para la seguridad de herramientas de IA
Estos incidentes confirman una tendencia clara: las herramientas de IA para desarrollo, IDEs inteligentes y pipelines de CI/CD se están consolidando como un vector de ataque prioritario. Cuando un agente puede ejecutar comandos de sistema, interactuar con Git y gestionar secretos, cualquier error en el modelo de confianza o en la configuración se traduce en un canal directo hacia RCE y ataques a la cadena de suministro.
Para reducir el riesgo, las organizaciones deberían:
- tratar a los agentes de IA como componentes de alto riesgo, limitando estrictamente los comandos y herramientas que pueden usar (allowlists duras);
- ejecutar CI/CD con aislamiento fuerte (contenedores, sandboxes) y en entornos diferenciados para código de terceros;
- evitar almacenar secretos en estaciones de trabajo y repos locales, centralizando la gestión de credenciales en bóvedas seguras;
- revisar y auditar extensiones, integraciones y workflows de IA antes de su adopción en entornos de producción;
- formar a equipos de desarrollo y DevOps en amenazas específicas como prompt injection, abuso de Git hooks y ataques de cadena de suministro.
La adopción acelerada de agentes de IA en desarrollo exige elevar el listón de la ciberseguridad. Revisar hoy las configuraciones de Gemini CLI, Cursor y herramientas similares, endurecer políticas de acceso y mantener una vigilancia continua sobre nuevas vulnerabilidades es clave para evitar que la automatización impulsada por IA se convierta en el eslabón más débil de la cadena de suministro de software.
