**Google** ha corregido un fallo de seguridad de máxima severidad en **Gemini CLI** – el paquete npm `@google/gemini-cli` y el flujo de trabajo `google-github-actions/run-gemini-cli` de **GitHub Actions** – que podría haber permitido a los atacantes ejecutar comandos arbitrarios en los sistemas anfitriones. **Ejecución Remota de Código en Gemini CLI** "La vulnerabilidad permitía a un atacante externo no privilegiado forzar la carga de su propio contenido malicioso como configuración de **Gemini**", dijo **Novee Security** en un informe del miércoles. "Esto activaba la ejecución de comandos directamente en el sistema anfitrión, eludiendo la seguridad incluso antes de que la sandbox del agente se inicializara." 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** indicó que el impacto se limita a los flujos de trabajo que utilizan **Gemini CLI** en modo headless, añadiendo que cualquier uso de la herramienta en modo headless sin confianza en la carpeta requerirá una revisión manual para configurar este mecanismo de confianza. "En versiones anteriores, **Gemini CLI** ejecutándose en entornos de CI (modo headless) confiaba automáticamente en las carpetas del espacio de trabajo para cargar la configuración y las variables de entorno", señaló. Esta confianza automática en la carpeta del espacio de trabajo actual significaba que la herramienta podía cargar cualquier configuración de agente que encontrara sin revisión, sandboxing o consentimiento explícito del usuario. Un atacante podría explotar este comportamiento al insertar una configuración especialmente diseñada que podría allanar el camino para la ejecución de código en el anfitrión que ejecuta el agente, convirtiendo efectivamente los pipelines de CI/CD en rutas de ataque de cadena de suministro. La actualización aborda el problema exigiendo que las carpetas sean explícitamente confiables antes de que se pueda acceder a los archivos de configuración. Para ello, se insta a los usuarios a revisar sus flujos de trabajo y adoptar uno de los dos enfoques: * Si el flujo de trabajo se ejecuta con entradas confiables (por ejemplo, revisión de pull requests de colaboradores confiables), establezca `GEMINI_TRUST_WORKSPACE: 'true'` en el flujo de trabajo. * Si el flujo de trabajo se ejecuta con entradas no confiables, revise la guía de **Google** en `google-github-actions/run-gemini-cli` para endurecer el flujo de trabajo contra contenido malicioso, y establezca la variable de entorno. El gigante tecnológico también señaló que está tomando medidas para endurecer la lista de permitidos de herramientas cuando **Gemini CLI** se configura para ejecutarse en modo `--yolo` para prevenir escenarios en los que entradas no confiables (por ejemplo, **GitHub** issues enviadas por usuarios) podrían llevar a ejecución remota de código a través de inyección de prompts, 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 (incluyendo "run_shell_command") sin requerir confirmación del usuario. "En la versión 0.39.1, el motor de políticas de **Gemini CLI** ahora evalúa la lista de permitidos de herramientas en modo `--yolo`, lo cual es útil para flujos de trabajo de CI que permiten ejecutar unos pocos comandos seguros al procesar entradas no confiables", dijo **Google**. "Como resultado, algunos flujos de trabajo que anteriormente dependían de este comportamiento pueden fallar silenciosamente a menos que las listas de permitidos de herramientas se modifiquen para ajustarse a la tarea." ### **Bug en Cursor** Lleva a Ejecución de Código  La divulgación se produce mientras **Novee Security** también destacó una vulnerabilidad de alta severidad en la herramienta de desarrollo impulsada por IA **Cursor** anterior a la versión 2.5 (**CVE-2026-26268**, puntuación **CVSS**: 8.1) que también podría llevar a ejecución arbitraria de código mediante inyección de prompts. **Cursor**, en una alerta publicada en febrero de 2026, lo describió como un caso de escape de sandbox a través de configuraciones de `.git`, permitiendo a un agente malicioso configurar un repositorio bare (`.git`) con un [hook de **Git**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) malicioso que se activa automáticamente cada vez que se ejecuta una operación de commit dentro del contexto del repositorio incrustado sin requerir ninguna interacción del usuario. El resultado final es la ejecución de código arbitrario con aprobación automática en la máquina de la víctima a través de la siguiente secuencia de acciones: * El usuario clona un repositorio público de **GitHub** con el repositorio bare incrustado que contiene un hook post-checkout malicioso. * El usuario abre el repositorio en **CursorIDE**. * Los usuarios hacen una pregunta inocua como "explicar la base de código". * El agente de **Cursor** analiza AGENTS.md que le instruye a navegar al repositorio bare y realiza un "git checkout" de la rama master. * Se activa el hook post-checkout dentro del repositorio bare, lo que lleva a la ejecución de código. "La causa raíz no es un fallo en la lógica central del producto de **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 autónomamente operaciones de **Git** dentro de un repositorio que no controla", dijo el investigador de seguridad Assaf Levkovich. "Cuando el agente ejecuta git checkout como parte de cumplir una solicitud rutinaria, 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 de **Cursor** del repositorio han puesto en marcha. Un hook pre-commit malicioso incrustado en un repositorio bare anidado se ejecuta silenciosamente, fuera de la cadena de razonamiento del agente y fuera del campo de visión del usuario." ### **CursorJacking**: Robo de Claves API Los hallazgos también coinciden con el descubrimiento de otra vulnerabilidad de control de acceso de alta severidad en el IDE (puntuación **CVSS**: 8.2) que podría permitir a cualquier extensión instalada acceder a claves API y credenciales sensibles almacenadas localmente en una base de datos **SQLite**, permitiendo la toma de control de cuentas, exposición de datos y pérdidas financieras derivadas del uso no autorizado de API. El problema, con nombre en clave **CursorJacking** por **LayerX**, sigue sin parchear. "**Cursor** no aplica 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 llevar a la exposición de tokens de sesión y claves API, acceso no autorizado a servicios backend de **Cursor**, y robo de datos a través de suplantación de identidad de usuario." **Cursor** ha sostenido que el acceso se limita a la máquina local donde el usuario ya ha instalado y otorgado 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.