Google ha abordado una falla de seguridad de máxima gravedad en la CLI de Gemini (el paquete npm «@google/gemini-cli» y el flujo de trabajo de acciones de GitHub «google-github-actions/run-gemini-cli»). Esta falla podría permitir que un atacante ejecute comandos arbitrarios en el sistema host.
«Esta vulnerabilidad podría permitir que un atacante externo no autorizado fuerce la carga de su propio contenido malicioso como una configuración Gemini», dijo Novee Security en un informe el miércoles. «Esto permitió que los comandos se ejecutaran directamente en el sistema host, evitando la seguridad antes de que se inicializara la zona de pruebas del agente».
Este inconveniente no tiene identificador CVE y 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
Google dijo en un aviso publicado la semana pasada que el impacto se limita a los flujos de trabajo que utilizan Gemini CLI en modo sin cabeza, y agregó que usar 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, la CLI de Gemini que se ejecutaba en un entorno CI (modo sin cabeza) confiaba automáticamente en la carpeta del espacio de trabajo para leer las variables de configuración y entorno», dijo.
«Esto es potencialmente peligroso en situaciones en las que la CLI de Gemini se ejecuta en modo sin cabeza en una carpeta que no es de confianza (como un flujo de trabajo de CI que revisa las solicitudes de extracción enviadas por los usuarios). Si se usa con el contenido de un directorio que no es de confianza, puede provocar 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 significa que la herramienta puede cargar cualquier configuración de agente que encuentre sin revisión, espacio aislado o consentimiento explícito del usuario. Los atacantes pueden convertir este comportamiento en un arma mediante la implantación de configuraciones especialmente diseñadas que allanan el camino para la ejecución de código en el host que ejecuta el agente, convirtiendo efectivamente la canalización de CI/CD en una ruta de ataque a la cadena de suministro.
Esta actualización resuelve este problema al requerir que se confíe explícitamente en las carpetas antes de acceder a los archivos de configuración. Esto requiere que los usuarios reconsideren sus flujos de trabajo y adopten uno de dos enfoques:
Si su flujo de trabajo se ejecuta con información confiable (como revisar solicitudes de extracción de colaboradores confiables), configure GEMINI_TRUST_WORKSPACE: ‘true’ en su flujo de trabajo. Si su flujo de trabajo se ejecuta con entradas que no son de confianza, revise la guía de Google en google-github-actions/run-gemini-cli para reforzar su flujo de trabajo contra contenido malicioso y establecer variables de entorno.
El gigante tecnológico también aprovechó el hecho de que el modo de aprobación automática ignora la lista de permitidos en «~/.gemini/settings.json» y todas las llamadas a herramientas (incluyendo «run_shell_command») se ejecutan automáticamente para evitar escenarios en los que entradas no confiables (como un problema de GitHub enviado por un usuario) podrían conducir a la ejecución remota de código mediante inyección rápida. También notamos que estamos tomando medidas para ajustar la lista permitida de herramientas cuando se configuran para ejecutarse en este modo. Se requiere confirmación del usuario.
«En la versión 0.39.1, el motor de políticas CLI de Gemini ahora evalúa las listas blancas de herramientas en modo –yolo. Esto es útil para los flujos de trabajo de CI que desean incluir en la lista blanca algunos comandos seguros para ejecutar al procesar 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 modifique la lista blanca de herramientas para que coincida con la tarea».
El error del cursor hace que el código se ejecute
La divulgación se produce cuando Novee Security destaca una vulnerabilidad de alta gravedad (CVE-2026-26268, puntuación CVSS: 8.1) en la herramienta de desarrollo basada en IA Cursor anterior a la versión 2.5 que también podría permitir la ejecución de código arbitrario mediante inyección rápida.
En una alerta publicada en febrero de 2026, Cursor describió esto como un caso de escape de la zona de pruebas a través de la configuración .git. Esto permite a un agente malicioso configurar un repositorio simple (‘.git’) utilizando un gancho Git malicioso que se invoca automáticamente cada vez que se realiza una operación de confirmación dentro del contexto del repositorio integrado, sin requerir la interacción del usuario.
El resultado final es la ejecución autoautorizada de código arbitrario en la máquina de la víctima mediante la siguiente secuencia de acciones:
Un usuario clona un repositorio público de GitHub que tiene un repositorio básico integrado con un enlace malicioso posterior al pago. Un usuario abre un repositorio en CursorIDE. El usuario solicita una «descripción del código base» en un mensaje inofensivo. El agente de cursor analiza AGENTS.md, lo que le indica que vaya al repositorio básico y realice una «compra git» de la rama maestra. Se activa un enlace posterior al pago en el repositorio básico y ejecuta el código.
«La causa raíz no es una falla en la lógica del producto central de Cursor, sino más bien el resultado de las interacciones funcionales de Git que se vuelven explotables en el momento en que un agente de IA comienza a realizar operaciones de Git de forma autónoma dentro de un repositorio que no controla», dijo el investigador de seguridad Assaf Levkovich.
«Cuando un agente ejecuta git checkout como parte de la ejecución de una solicitud de rutina, el agente no está haciendo nada que el usuario no haya autorizado implícitamente. Sin embargo, ni el usuario ni el agente pueden saber qué están impulsando las reglas del cursor del repositorio. Los ganchos de confirmación previa maliciosos incrustados en repositorios desnudos anidados se ejecutan silenciosamente fuera de la cadena de inferencia del agente y fuera del campo de visión del usuario».
Este descubrimiento coincide con el descubrimiento de otra vulnerabilidad de control de acceso de alta gravedad (puntuación CVSS: 8,2) en el IDE. Esta vulnerabilidad permite que las extensiones instaladas accedan a claves y credenciales API confidenciales almacenadas localmente en una base de datos SQLite, lo que podría resultar en apropiación de cuentas, divulgación de datos y pérdidas financieras debido al uso indebido de API. Este problema, cuyo nombre en código es CursorJacking de LayerX, sigue sin parchearse.
«Cursor no impone ningún límite de control de acceso entre la extensión y esta base de datos», dijo Roy Paz, investigador de LayerX. «La explotación de esta vulnerabilidad podría conducir a la divulgación de tokens de sesión y claves API, acceso no autorizado al servicio backend de Cursor y robo de datos mediante la suplantación de usuario».
Cursor afirma que el acceso está limitado a máquinas locales donde los usuarios ya instalaron la extensión y dieron permiso. Esto significa que una extensión maliciosa que accede al sistema de archivos local puede extraer información valiosa de varios almacenes de datos de aplicaciones. Para combatir esta amenaza, es importante que los usuarios sigan descargando extensiones confiables.
Source link
