**Google** corrigiu uma falha de segurança de severidade máxima no **Gemini CLI** – o pacote npm `@google/gemini-cli` e o fluxo de trabalho `google-github-actions/run-gemini-cli` do **GitHub Actions** – que poderia ter permitido a atacantes executar comandos arbitrários em sistemas host. **Execução Remota de Código no Gemini CLI** "A vulnerabilidade permitiu que um atacante externo não privilegiado forçasse o carregamento de seu próprio conteúdo malicioso como configuração do **Gemini**", disse a **Novee Security** em um relatório de quarta-feira. "Isso acionou a execução de comandos diretamente no sistema host, contornando a segurança antes mesmo que o sandbox do agente fosse inicializado." A falha, que não possui um identificador **CVE**, carrega uma pontuação **CVSS** de 10.0. Ela afeta as seguintes versões: * `@google/gemini-cli < 0.39.1` * `@google/gemini-cli < 0.40.0-preview.3` * `google-github-actions/run-gemini-cli < 0.1.22` Em seu aviso publicado na semana passada, o **Google** disse que o impacto é limitado a fluxos de trabalho que usam o **Gemini CLI** em modo headless, acrescentando que qualquer uso da ferramenta em modo headless sem confiança na pasta exigirá revisão manual para configurar esse mecanismo de confiança. "Em versões anteriores, o **Gemini CLI** executado em ambientes de CI (modo headless) confiava automaticamente nas pastas de trabalho para fins de carregamento de configuração e variáveis de ambiente", disse. Essa confiança automática na pasta de trabalho atual significava que a ferramenta poderia carregar qualquer configuração de agente encontrada sem revisão, sandboxing ou consentimento explícito do usuário. Um atacante poderia explorar esse comportamento ao inserir uma configuração especialmente elaborada que poderia abrir caminho para a execução de código no host que executa o agente, transformando efetivamente os pipelines de CI/CD em caminhos de ataque à cadeia de suprimentos. A atualização aborda o problema exigindo que as pastas sejam explicitamente confiáveis antes que os arquivos de configuração possam ser acessados. Para isso, os usuários são instados a revisar seus fluxos de trabalho e adotar uma das duas abordagens: * Se o fluxo de trabalho for executado em entradas confiáveis (por exemplo, revisão de pull requests de colaboradores confiáveis), defina `GEMINI_TRUST_WORKSPACE: 'true'` no fluxo de trabalho. * Se o fluxo de trabalho for executado em entradas não confiáveis, revise as orientações do **Google** em `google-github-actions/run-gemini-cli` para fortalecer o fluxo de trabalho contra conteúdo malicioso e defina a variável de ambiente. A gigante da tecnologia também observou que está tomando medidas para fortalecer a lista de permissões de ferramentas quando o **Gemini CLI** é configurado para ser executado no modo `--yolo` para evitar cenários em que entradas não confiáveis (por exemplo, issues do **GitHub** enviadas por usuários) poderiam levar à execução remota de código via injeção de prompt, aproveitando o fato de que o modo de aprovação automática ignoraria qualquer lista de permissões em `~/.gemini/settings.json` e executaria todas as chamadas de ferramenta automaticamente (incluindo "run_shell_command") sem exigir confirmação do usuário. "Na versão 0.39.1, o mecanismo de políticas do **Gemini CLI** agora avalia a lista de permissões de ferramentas no modo `--yolo`, o que é útil para fluxos de trabalho de CI que permitem a execução de alguns comandos seguros ao processar entradas não confiáveis", disse o **Google**. "Como resultado, alguns fluxos de trabalho que anteriormente dependiam desse comportamento podem falhar silenciosamente, a menos que as listas de permissões de ferramentas sejam modificadas para se adequar à tarefa." ### Bug no **Cursor** Leva à Execução de Código  A divulgação ocorre enquanto a **Novee Security** também destacou uma vulnerabilidade de alta severidade na ferramenta de desenvolvimento impulsionada por IA **Cursor** antes da versão 2.5 (**CVE-2026-26268**, pontuação **CVSS**: 8.1) que também poderia levar à execução de código arbitrário por meio de injeção de prompt. O **Cursor**, em um alerta divulgado em fevereiro de 2026, descreveu-o como um caso de fuga de sandbox através de configurações `.git`, permitindo que um agente malicioso configure um repositório bare (`.git`) com um [**Git** hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) malicioso que é acionado automaticamente toda vez que uma operação de commit é executada no contexto do repositório embutido, sem exigir qualquer interação do usuário. O resultado final é a execução de código arbitrário com aprovação automática na máquina da vítima através da seguinte sequência de ações: * O usuário clona um repositório **GitHub** público com o repositório bare embutido contendo um hook post-checkout malicioso * O usuário abre o repositório no **CursorIDE** * O usuário faz um prompt inócuo como "explicar o codebase" * O agente **Cursor** analisa o AGENTS.md que o instrui a navegar até o repositório bare e executa um "git checkout" do branch master * O hook post-checkout dentro do repositório bare é acionado, levando à execução de código. "A causa raiz não é uma falha na lógica principal do produto **Cursor**, mas sim uma consequência de uma interação de recursos no **Git**, uma que se torna explorável no momento em que um agente de IA começa a executar autonomamente operações **Git** dentro de um repositório que não controla", disse o pesquisador de segurança Assaf Levkovich. "Quando o agente executa git checkout como parte do cumprimento de uma solicitação rotineira, ele não está fazendo nada que o usuário não tenha implicitamente autorizado. Mas nem o usuário nem o agente têm visibilidade sobre o que as Regras do **Cursor** do repositório colocaram em movimento. Um hook pre-commit malicioso embutido em um repositório bare aninhado executa silenciosamente, fora da cadeia de raciocínio do agente e fora do campo de visão do usuário." ### **CursorJacking**: Roubo de Chave de API As descobertas também coincidem com a descoberta de outra vulnerabilidade de controle de acesso de alta severidade na IDE (pontuação **CVSS**: 8.2) que poderia permitir que qualquer extensão instalada acessasse chaves de API e credenciais confidenciais armazenadas localmente em um banco de dados **SQLite**, permitindo takeover de conta, exposição de dados e perdas financeiras decorrentes do uso não autorizado da API. A questão, codinome **CursorJacking** pela **LayerX**, permanece sem correção. "O **Cursor** não impõe limites de controle de acesso entre as extensões e este banco de dados", disse o pesquisador da **LayerX**, Roy Paz. "A exploração desta vulnerabilidade pode levar à exposição de tokens de sessão e chaves de API, acesso não autorizado aos serviços de backend do **Cursor** e roubo de dados via personificação do usuário." O **Cursor** sustentou que o acesso é limitado à máquina local onde o usuário já instalou e concedeu permissões à extensão, o que significa que qualquer extensão maliciosa com acesso ao sistema de arquivos local poderia potencialmente extrair informações valiosas de vários armazenamentos de dados de aplicativos. Para combater a ameaça, é essencial que os usuários se atenham a baixar extensões confiáveis.