Gemini-CLI CVSS 10 RCE: qué deben parchear ahora los arquitectos de la nube en CI/CD
Pillar Security reveló la vulnerabilidad GHSA-wpqr-6v78-jr5g, que Google parcheó en la versión 0.39.1.
7 min. Tiempo de lectura
Pillar Security reportó el 16 de abril de 2026 una vulnerabilidad en la CLI de Google Gemini; Google la cerró el 24 de abril bajo el nombre GHSA-wpqr-6v78-jr5g. Puntuación CVSS: 10,0. Un colaborador externo con un pull request pudo ejecutar código en un CI-Runner antes de inicializar la sandbox. Quienes aún tienen Gemini-CLI en versión 0.38 o anterior en su stack de pipeline enfrentan un problema multi-tenant que no se detecta en la consola propia de la nube.
Lo más importante en resumen
- CVSS máximo para una CLI AI en contexto de CI. La vulnerabilidad de Gemini-CLI combinó dos brechas de diseño: el modo headless confiaba en cada carpeta del espacio de trabajo, mientras que –yolo ignoraba las listas de permisos de herramientas. Juntos, estos elementos permitieron la ejecución remota de código.
- El CI-Runner como puerta de entrada. Un pull request desde fuera fue suficiente para leer secretos, credenciales y código fuente antes de iniciar la sandbox. Esto desplaza la superficie de ataque del ordenador portátil del empleado hacia la plataforma de compilación.
- El parche está disponible, pero la propagación sigue siendo un tema abierto. Gemini-CLI 0.39.1 y google-github-actions/run-gemini-cli 0.1.22 cierran el camino. Quienes no aplican el parche de forma centralizada siguen ejecutando versiones antiguas en forks y pipelines privados sin ser notados.
Relacionado:Platform Engineering Compliance NIS2/DORA / Google Gemini en la empresa
Qué demostró específicamente Pillar Security
¿Qué es la vulnerabilidad de Gemini-CLI GHSA-wpqr-6v78-jr5g? Se trata de una brecha de ejecución remota de código en la CLI de Google Gemini y en la acción de GitHub asociada, que pudo ser explotada por un colaborador externo con un pull request para ejecutar comandos en el CI-Runner antes de inicializar la sandbox de herramientas. Google evaluó la vulnerabilidad con una puntuación CVSS de 10,0, lo que representa la severidad máxima en la escala CVSS-3.1. Las versiones actualizadas son Gemini-CLI 0.39.1 y google-github-actions/run-gemini-cli 0.1.22.
La mecánica es mucho más específica que la descripción habitual de CVE. Pillar Security primero demostró el ataque en el repositorio propio de Google, draco, y luego, el 20 de abril, directamente en la CLI de Gemini. El detonante fue un pull request con contenido de espacio de trabajo preparado. En el modo headless de la CLI, la carpeta del espacio de trabajo se trató como confiable sin ninguna confirmación adicional; se pudo cargar un archivo de configuración local .gemini y el modo –yolo ignoró las listas de permisos de herramientas muy detalladas.
El resultado fue un camino de inyección de prompts que llevó a cualquier comando shell. El runner vio la secuencia como una instrucción legítima de IA, mientras que el inicio de la sandbox llegó demasiado tarde, ya que las credenciales ya habían sido recolectadas. Quienes operan en un repositorio open-source donde los pull requests de colaboradores externos son probados rutinariamente, tuvieron un bypass abierto durante semanas, sin que nada en el registro de auditoría pareciera indicar un ataque.
Por qué esto duele especialmente en el entorno multiinquilino
Los arquitectos de nubes conocen el reflejo del CVSS-10: manos sobre la mesa, plan de parches, auditoría. Lo que hace particularmente incómodo a Gemini-CLI es su característica estructural: funciona en el contexto CI/CD con los privilegios altos de la pipeline. Una pipeline comprometida puede generar imágenes de contenedores firmadas, renovar credenciales de nube, desplegar charts de Helm y manipular estados de Terraform.
Quienes trabajan en plataformas multiinquilino lo ven aún más doloroso. Un trabajo de pipeline que produce para múltiples clientes, en caso de una RCE, podría poner en movimiento datos o artefactos de construcción pertenecientes a mandantes ajenos. Y si ese mismo trabajo solo atiende al propio mandante pero se ejecuta en una instancia compartida de Cloud Run, proporciona al atacante un posible objetivo para movimientos laterales.
No es el primer incidente de CVSS-10 en este año relacionado con hipersupervisores. El CVE-2026-32202 obligó a la CISA a incluirlo en la lista KEV en abril, con plazos estrictos y presión sobre las agencias federales. La lección es la misma: las CLI de IA son software como cualquier otra herramienta de compilación y deben someterse al mismo proceso de parcheo, auditoría y listas blancas.
Mitigaciones CI/CD para equipos de nube: lo que ayuda, lo que perjudica
Lo que perjudica
- CLI de IA con opciones –yolo o modos similares de confianza total en CI
- Configuraciones de workspace provenientes de PRs sin un paso explícito de verificación de confianza
- Fijación por rama o etiqueta en lugar de por SHA de commit
- Identidades de pipeline compartidas entre varios repositorios
- Registros de auditoría sin captura previa a la fase de sandbox
Lo que ayuda
- Gemini-CLI versión 0.39.1 / Action versión 0.1.22 como mínimo para fijar versiones
- Federación de identidad de carga de trabajo en lugar de claves duraderas
- Trabajos de validación de pull requests en aislamiento propio del tenant
- Listas blancas de herramientas, sin banderas globales de confianza total
- Renovate-Bot o Dependabot monitoreando versiones de CLI de IA
La columna de la izquierda no es pura teoría. Quienes han integrado Gemini-CLI en alguna acción durante los últimos tres meses deberían revisar hoy los registros de ejecución de CI en busca de configuraciones de workspace preparadas específicamente antes de la primera acción de la herramienta. Pillar Security ha publicado una lista de indicadores de compromiso en su informe oficial. Esta lista debe incorporarse a su propio SIEM antes del inicio de la próxima ronda de auditorías.
La federación de identidad de carga de trabajo es la segunda palanca subestimada. Si una ejecución de pipeline no obtiene sus credenciales de GCP de una clave estática de cuenta de servicio, sino que las re-federiza mediante OIDC en cada ejecución, entonces, en caso de una RCE, no dispondrá de un token duradero que pueda ser comprometido.
Hoja de ruta de parches: desde la auditoría hasta una pipeline limpia
Dos semanas es un plazo realista si el equipo de plataforma se compromete con el fijado estricto (hard-pin) de la versión de la Action y no planifica simultáneamente la siguiente migración de plataforma. Quien gestione varios inquilinos incorporará además las listas blancas de herramientas por cliente durante la tercera y cuarta semana, lo que supone un esfuerzo adicional, pero no implica una nueva arquitectura operativa.
Qué queda pendiente
Pillar Security notificó el error para optar a una recompensa, pero no reveló la cuantía. Esto es habitual en el contexto del Programa de Recompensas por Vulnerabilidades (VRP) de Google y no indica la gravedad del fallo. Lo más importante es el patrón: las CLI de IA se están convirtiendo en la primera línea de seguridad de la CI, ya que representan la conexión directa entre la entrada de prompts externos y la ejecución en shell. La próxima oleada comparable probablemente no residirá en una CLI, sino en una API de agente integrada o en una lógica de construcción operada por LLM.
Por tanto, quien aplique hoy el parche a Gemini-CLI cierra un incidente. Quien además adapte su pipeline a Workload Identity, listas blancas de herramientas y registro de auditoría previo al sandbox, cierra toda una clase de vulnerabilidades.
Preguntas frecuentes
¿Me afecta si uso Gemini-CLI solo localmente?
El riesgo en pipelines de CI sin interfaz es mucho mayor que en el uso interactivo local, ya que allí falta el paso de confianza. Localmente, la bandera –yolo es el verdadero problema. Quien no la haya activado tampoco en su entorno local y trabaje con una versión inferior a 0.39.1, debería actualizar rápidamente.
¿Basta con fijar una versión en la GitHub Action?
No por sí solo. Fijar la versión en 0.1.22 o mediante SHA es la línea base. Además, se necesitan listas de herramientas permitidas por trabajo y, idealmente, un perfil de ejecutor separado para las validaciones de solicitudes de extracción (pull request) que no conserve credenciales en la nube. La defensa en profundidad no es aquí un eslogan de manual, sino relevante operativamente.
¿Cómo sé si se ha explotado la vulnerabilidad en las últimas semanas?
Pillar Security ha publicado indicadores en el informe de divulgación. En la práctica, se buscan en los registros de acciones configuraciones .gemini manipuladas que se cargaron directamente antes de la primera operación de herramienta, así como subllamadas a shell que se encuentran fuera del conjunto permitido esperado. Una consulta retrospectiva (lookback) en SIEM durante los últimos 30 días es una visibilidad mínima adecuada.
¿Qué significa esto para los equipos de plataformas multiinquilino?
Para cada inquilino rige la misma fecha de parche. Quien pueda aplicar esto de forma centralizada mediante una actualización de plataforma está en ventaja. Quien permita pipelines específicos por inquilino debe elevar cada inquilino individualmente a la versión parcheada y documentarlo ante la auditoría.
¿Existe una relación directa con CISA KEV?
Actualmente, esta vulnerabilidad de Gemini-CLI no figura en la KEV porque Pillar Security la reportó bajo un proceso de divulgación responsable y el parche estaba disponible antes de cualquier explotación. Sin embargo, esto no excluye su inclusión futura si se documenta su explotación en entornos reales.
Consejos de lectura de la redacción
Más de la red MBF Media
MyBusinessFutureCuando la productividad con IA resulta cara: qué significa la consolidación de herramientas en Big Tech para la clase media industrial de la región DACHDigital ChiefsFinOps a escala corporativa: quién controla realmente la factura de la nube en 2026SecurityTodayTrapDoor: Ataque coordinado a la cadena de suministro contra npm, PyPI y Crates: qué deben comprobar ahora los equipos de CI/CDFuente imagen principal: Pexels / panumas nikhomkhai (px:17489150)
Fuente imagen principal: Pexels / panumas nikhomkhai
