Vulnerabilidad crítica en Gemini CLI y GitHub Actions expone la cadena de suministro de CI a ejecución remota de código

Google corrigió una vulnerabilidad crítica en Gemini CLI (el paquete npm @google/gemini-cli) y en el flujo de trabajo de GitHub Actions google-github-actions/run-gemini-cli que permitía ejecutar comandos arbitrarios en el sistema anfitrión cuando la herramienta se usaba en modo headless dentro de CI. La raíz del problema fue una confianza implícita en la carpeta de trabajo: en versiones afectadas la CLI cargaba configuraciones y variables de entorno desde .gemini/ sin validación cuando corría en entornos automatizados, lo que abría la puerta a que contenido malicioso plantado por un atacante fuera tratado como configuración legítima y detonara ejecución remota de código.

El defecto, calificado con una severidad máxima (CVSS 10.0) por investigadores externos, ejemplifica cómo un atajo de usabilidad en pipelines automatizados se convierte en un vector de ataque de la cadena de suministro: análisis de pull requests, forks o contenidos de terceros pueden convertirse en trampas si una herramienta asume que el workspace es confiable. Google mitigó el riesgo obligando ahora a marcar explícitamente las carpetas como confiables antes de leer archivos de configuración y proponiendo variables de entorno y configuraciones concretas para workflows, además de endurecer las comprobaciones de allowlist cuando la CLI se ejecuta con --yolo.

Si usas Gemini CLI en GitHub Actions, la acción inmediata es actualizar a versiones corregidas: instala @google/gemini-cli en versiones iguales o superiores a las que corrigen el fallo (las versiones vulnerables son las indicadas por el proveedor) y actualiza google-github-actions/run-gemini-cli a la versión 0.1.22 o posterior. Revisa la página del repositorio para obtener las releases y la guía de configuración: google-github-actions/run-gemini-cli y el paquete npm @google/gemini-cli en npm.

No basta con actualizar: audita tus workflows. Si tu flujo procesa solo entradas de colaboradores de confianza puedes optar por establecer GEMINI_TRUST_WORKSPACE: 'true' en el entorno del job, pero no lo hagas si aceptas contribuciones de terceros o forks. Para inputs no confiables, sigue la guía oficial de endurecimiento y trata el workspace como hostile: monta runners efímeros, limita permisos de Actions con el mínimo necesario, deshabilita acceso innecesario a secrets y emplea reglas estrictas de allowlist para cualquier funcionalidad que ejecute comandos o procesos.

Además, Google cambió el comportamiento de --yolo (modo de auto-aprobación) para que la política de allowlist de herramientas también se evalúe en ese modo; eso evita que llamadas a funciones peligrosas como run_shell_command se ejecuten sin restricciones. Sin embargo, el cambio puede provocar fallos silenciosos en workflows previos, por lo que conviene revisar y ajustar las allowlists para mantener la funcionalidad requerida sin sacrificar seguridad.

El caso de Gemini debe leerse en conjunto con otras vulnerabilidades recientes en herramientas impulsadas por IA. Investigadores también describieron un vector en Cursor IDE que permitió ejecución arbitraria mediante técnicas de prompt injection y hooks Git maliciosos dentro de repositorios “embebidos” (.git), además de una falla de control de acceso que permitía a extensiones locales leer credenciales almacenadas en bases SQLite. Estos incidentes refuerzan un patrón: los agentes autónomos que realizan operaciones Git o sistemas que otorgan privilegios a extensiones pueden convertir características legítimas en vectores de ataque cuando se combinan con repositorios o paquetes maliciosos.

Qué hacer frente a estas amenazas: en primer lugar, aplica parches inmediatamente y suscríbete a avisos de seguridad de los proyectos que uses. En segundo lugar, reduce la superficie de ataque en CI: ejecutores efímeros, separación de permisos por job, revisión manual de PRs de forks antes de ejecutar workflows que procesen el contenido y escaneo automatizado de artefactos entrantes. GitHub mantiene recomendaciones útiles sobre endurecimiento de Actions que conviene seguir: Security hardening for GitHub Actions.

Para herramientas de desarrollo locales como Cursor, la práctica mínima es no abrir repositorios desconocidos en entornos con agentes que actúen automáticamente, evitar instalar extensiones de origen no fiable y limitar el acceso de las extensiones al sistema de archivos. Si ya trabajas con secretos locales o claves API, rota credenciales expuestas y usa gestores de secretos y cuentas de servicio con privilegios limitados para CI en lugar de tokens personales.

Finalmente, adopta defensas en profundidad: integra análisis estático y escaneo de dependencias en tu pipeline, habilita políticas de seguridad que inspeccionen archivos de configuración (incluidos dotfiles como .git y .gemini), y establece procedimientos de aprobación humana cuando un agente va a ejecutar cambios en el sistema. La conveniencia de los agentes de IA y las herramientas automatizadas no debe sustituir a controles básicos de aislamiento y revisión; la seguridad defensiva sigue siendo la mejor protección contra exploits encubiertos en la cadena de suministro.