Google ha abordado una falla de seguridad de máxima gravedad en Gemini CLI: el paquete npm «@google/gemini-cli» y el flujo de trabajo de acciones GitHub «google-github-actions/run-gemini-cli», que podría haber permitido a los atacantes ejecutar comandos arbitrarios en sistemas host.
«La vulnerabilidad permitió a un atacante externo sin privilegios forzar la carga de su propio contenido malicioso como configuración Gemini», Novee Security dicho en un informe del miércoles. «Esto desencadenó la ejecución del comando directamente en el sistema host, evitando la seguridad incluso antes de que se inicializara el entorno limitado del agente».
La deficiencia, que no tiene un identificador CVE, tiene una puntuación CVSS de 10,0. Afecta a las siguientes versiones:
- @google/gemini-cli <0.39.1
- @google/gemini-cli < 0.40.0-preview.3
- google-github-actions/run-gemini-cli <0.1.22
en su aviso publicado La semana pasada, Google dijo que el impacto se limita a los flujos de trabajo que utilizan Gemini CLI en modo sin cabeza, y agregó que cualquier uso de la herramienta en modo sin cabeza sin confianza en la carpeta requerirá una revisión manual para configurar este mecanismo de confianza.
«En versiones anteriores, Gemini CLI que se ejecuta en entornos CI (modo sin cabeza) confiaba automáticamente en las carpetas del espacio de trabajo con el fin de cargar la configuración y las variables de entorno», decía.
«Esto es potencialmente riesgoso en situaciones en las que Gemini CLI se ejecuta en carpetas que no son de confianza en modo sin cabeza (por ejemplo, flujos de trabajo de CI que revisan las solicitudes de extracción enviadas por los usuarios). Si se usa con contenidos de directorios que no son de confianza, esto podría llevar a la ejecución remota de código a través de variables de entorno maliciosas en el directorio .gemini/ local».
Esta confianza automática de la carpeta del espacio de trabajo actual significaba que la herramienta podía cargar cualquier configuración de agente que encontrara sin revisión, espacio aislado o consentimiento explícito del usuario. Un atacante podría convertir este comportamiento en un arma al implementar una configuración especialmente diseñada que podría allanar el camino para la ejecución de código en el host que ejecuta el agente, convirtiendo efectivamente los canales de CI/CD en rutas de ataque a la cadena de suministro.
La actualización soluciona el problema al requerir que se confíe explícitamente en las carpetas antes de poder acceder a los archivos de configuración. Con ese fin, se insta a los usuarios a revisar sus flujos de trabajo y adoptar uno de dos enfoques:
- Si el flujo de trabajo se ejecuta con entradas confiables (por ejemplo, revisar solicitudes de extracción de colaboradores confiables), configure GEMINI_TRUST_WORKSPACE: ‘true’ en el flujo de trabajo.
- Si el flujo de trabajo se ejecuta en entradas que no son de confianza, revise la guía de Google en google-github-acciones/run-gemini-cli para reforzar el flujo de trabajo contra contenido malicioso y establecer la variable de entorno.
El gigante tecnológico también señaló que está tomando medidas para reforzar la lista de herramientas permitidas cuando Gemini CLI está configurado para ejecutarse en modo –yolo para evitar escenarios en los que entradas no confiables (por ejemplo, problemas de GitHub enviados por el usuario) podrían conducir a la ejecución remota de código mediante inyección rápida, aprovechando el hecho de que el modo de aprobación automática ignoraría cualquier lista de permitidos en «~/.gemini/settings.json» y ejecutaría todas las llamadas a herramientas automáticamente (incluido «run_shell_command») sin necesidad de usuario. confirmación.
«En la versión 0.39.1, el motor de políticas Gemini CLI ahora evalúa la lista de herramientas permitidas en el modo –yolo, lo cual es útil para los flujos de trabajo de CI que permiten incluir algunos comandos seguros para ejecutar cuando se procesan entradas que no son de confianza», dijo Google. «Como resultado, algunos flujos de trabajo que anteriormente dependían de este comportamiento pueden fallar silenciosamente a menos que se modifiquen las listas de herramientas permitidas para adaptarse a la tarea».
El error del cursor conduce a la ejecución del código
La divulgación se produce cuando Novee Security también destacó una vulnerabilidad de alta gravedad en la herramienta de desarrollo basada en IA Cursor anterior a la versión 2.5 (CVE-2026-26268, puntuación CVSS: 8.1) que también podría conducir a la ejecución de código arbitrario mediante una inyección rápida.
Cursor, en una alerta liberado en febrero de 2026, lo describió como un caso de escape de la zona de pruebas a través de configuraciones .git, lo que permite a un agente deshonesto configurar un repositorio simple («».git») con un archivo malicioso. gancho git eso se activa automáticamente cada vez que se ejecuta una operación de confirmación dentro del contexto del repositorio integrado sin requerir ninguna interacción del usuario.
El resultado final es la ejecución de código arbitrario aprobado automáticamente en la máquina de la víctima mediante la siguiente secuencia de acciones:
- El usuario clona un repositorio público de GitHub con el repositorio básico integrado que contiene un enlace malicioso posterior al pago
- El usuario abre el repositorio en CursorIDE
- Los usuarios solicitan un mensaje inocuo para «explicar el código base»
- El agente de cursor analiza el AGENTES.md que le indica que navegue hasta el repositorio básico y realiza un «git checkout» de la rama maestra
- Se activa el gancho posterior al pago dentro del repositorio básico, lo que lleva a la ejecución del código.
«La causa raíz no es una falla en la lógica central del producto Cursor, sino más bien una consecuencia de una interacción de características en Git, una que se vuelve explotable en el momento en que un agente de IA comienza a ejecutar de forma autónoma operaciones de Git dentro de un repositorio que no controla», dijo el investigador de seguridad Assaf Levkovich. dicho.
«Cuando el agente ejecuta git checkout como parte del cumplimiento de una solicitud de rutina, no está haciendo nada que el usuario no haya autorizado implícitamente. Pero ni el usuario ni el agente tienen visibilidad de lo que las reglas del cursor del repositorio han puesto en marcha. Un gancho malicioso de confirmación previa incrustado en un repositorio anidado se ejecuta silenciosamente, fuera de la cadena de razonamiento del agente y fuera del campo de visión del usuario».
Los hallazgos también coinciden con el descubrimiento de otra vulnerabilidad de control de acceso de alta gravedad en el IDE (puntuación CVSS: 8,2) que podría permitir que cualquier extensión instalada acceda a claves y credenciales API confidenciales almacenadas localmente en una base de datos SQLite, lo que permitiría la apropiación de cuentas, la exposición de datos y pérdidas financieras derivadas del uso no autorizado de API. El problema, con nombre en clave CursorJacking por LayerX, permanece sin parchear.
«Cursor no impone límites de control de acceso entre las extensiones y esta base de datos», dijo el investigador de LayerX Roy Paz. «La explotación de esta vulnerabilidad puede provocar la exposición de tokens de sesión y claves API, acceso no autorizado a los servicios backend de Cursor y robo de datos mediante la suplantación de usuarios».
Cursor ha sostenido que el acceso está limitado a la máquina local donde el usuario ya instaló y otorgó permisos a la extensión, lo que significa que cualquier extensión maliciosa con acceso al sistema de archivos local podría potencialmente extraer información valiosa de varios almacenes de datos de aplicaciones. Para contrarrestar la amenaza, es esencial que los usuarios se limiten a descargar extensiones confiables.
