O Google corrigiu uma falha de segurança de gravidade máxima no Gemini CLI, no pacote npm "@google/gemini-cli" e no fluxo de trabalho "google-github-actions/run-gemini-cli" para GitHub Actions, que poderia permitir a invasores executar comandos arbitrários nos sistemas host.
“A vulnerabilidade permitia que um atacante externo sem privilégios forçasse o carregamento do próprio conteúdo malicioso como configuração do Gemini”, afirmou a Novee Security em relatório publicado na quarta-feira.
“Isso disparava a execução de comandos diretamente no sistema host, contornando as proteções antes mesmo de o sandbox do agente ser inicializado.”
A falha, que não possui identificador CVE, tem 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 um alerta publicado na semana passada, o Google informou que o impacto fica limitado a fluxos de trabalho que usam o Gemini CLI em modo sem interface, acrescentando que qualquer uso da ferramenta nesse modo, sem confiança prévia na pasta, exigirá revisão manual para configurar esse mecanismo de confiança.
“Nas versões anteriores, o Gemini CLI executado em ambientes de integração contínua, no modo sem interface, confiava automaticamente nas pastas do espaço de trabalho para carregar configurações e variáveis de ambiente”, disse a empresa.
“Isso é potencialmente arriscado em situações em que o Gemini CLI roda em pastas não confiáveis no modo sem interface, como em fluxos de trabalho de CI que analisam pull requests enviados por usuários.
Se usado com conteúdo de diretório não confiável, isso pode levar à execução remota de código por meio de variáveis de ambiente maliciosas no diretório local .gemini/.”
Essa confiança automática na pasta do espaço de trabalho atual permitia que a ferramenta carregasse qualquer configuração de agente encontrada, sem revisão, sem sandbox e sem consentimento explícito do usuário.
Um atacante poderia explorar esse comportamento ao inserir uma configuração especialmente criada, abrindo caminho para execução de código no host que executa o agente e transformando, na prática, os pipelines de CI/CD em vetores de ataque à supply chain.
A atualização corrige o problema ao exigir que as pastas sejam explicitamente confiáveis antes que arquivos de configuração possam ser acessados.
Para isso, os usuários são orientados a revisar seus fluxos de trabalho e adotar uma das duas abordagens:
Se o fluxo de trabalho operar com entradas confiáveis, como a análise de pull requests de colaboradores de confiança, defina GEMINI_TRUST_WORKSPACE: 'true' no fluxo de trabalho.
Se o fluxo de trabalho operar com entradas não confiáveis, consulte a orientação do Google em google-github-actions/run-gemini-cli para endurecer a proteção contra conteúdo malicioso e defina a variável de ambiente.
A gigante também informou que está tomando medidas para fortalecer a lista de permissão de ferramentas quando o Gemini CLI é configurado para rodar em modo --yolo, a fim de evitar cenários em que entradas não confiáveis, como issues enviadas por usuários no GitHub, levem à execução remota de código por injeção de prompt.
Isso seria possível porque o modo de aprovação automática ignoraria qualquer lista de permissão em "~/.gemini/settings.json" e executaria automaticamente todas as chamadas de ferramentas, 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ão 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 dependiam desse comportamento anteriormente podem falhar silenciosamente, a menos que as listas de permissão de ferramentas sejam ajustadas à tarefa.”
A divulgação ocorre ao mesmo tempo em que a Novee Security também destacou uma vulnerabilidade de alta severidade na ferramenta de desenvolvimento com IA Cursor, em versões anteriores à 2.5 (
CVE-2026-26268
, CVSS 8,1), que também poderia levar à execução arbitrária de código por meio de injeção de prompt.
Em um alerta divulgado em fevereiro de 2026, o Cursor descreveu o caso como uma fuga de sandbox por meio de configurações .git, permitindo que um agente malicioso montasse um repositório vazio (".git") com um Git hook malicioso, acionado automaticamente sempre que uma operação de commit era executada no contexto do repositório incorporado, sem qualquer interação do usuário.
O resultado final era a execução automática e arbitrária de código na máquina da vítima por meio da seguinte sequência de ações:
O usuário clona um repositório público no GitHub com o repositório vazio incorporado contendo um post-checkout hook malicioso
O usuário abre o repositório no CursorIDE
O usuário faz um pedido inofensivo, como “explique a base de código”
O agente do Cursor analisa o AGENTS.md, que o instrui a navegar até o repositório vazio e executar um “git checkout” da branch master
O post-checkout hook dentro do repositório vazio é acionado, levando à execução de código
“A causa raiz não é uma falha na lógica central do Cursor, mas sim uma consequência da interação entre recursos do Git, que se torna explorável no momento em que um agente de IA começa a executar operações de Git de forma autônoma dentro de um repositório que não controla”, disse o pesquisador de segurança Assaf Levkovich.
“Quando o agente executa git checkout para atender a uma solicitação rotineira, ele não está fazendo nada que o usuário não tenha autorizado implicitamente.
Mas nem o usuário nem o agente conseguem enxergar o que as Cursor Rules do repositório colocaram em movimento.
Um pre-commit hook malicioso embutido em um repositório vazio aninhado é executado em silêncio, fora da cadeia de raciocínio do agente e fora do campo de visão do usuário.”
As descobertas coincidem ainda com a identificação de outra vulnerabilidade de alto impacto de controle de acesso no IDE, com pontuação CVSS de 8,2, que poderia permitir que qualquer extensão instalada acessasse chaves de API e credenciais sensíveis armazenadas localmente em um banco de dados SQLite, possibilitando tomada de conta, exposição de dados e perdas financeiras decorrentes do uso não autorizado de API.
O problema, batizado de CursorJacking pela LayerX, continua sem correção.
“O Cursor não impõe limites de controle de acesso entre as extensões e esse banco de dados”, disse o pesquisador da LayerX, Roy Paz.
“A exploração dessa vulnerabilidade pode levar à exposição de tokens de sessão e chaves de API, ao acesso não autorizado aos serviços de backend do Cursor e ao roubo de dados por meio da falsificação de identidade do usuário.”
O Cursor afirmou que o acesso fica restrito à máquina local em que o usuário já instalou a extensão e concedeu permissões, o que significa que qualquer extensão maliciosa com acesso ao sistema de arquivos local poderia, potencialmente, extrair informações valiosas de diferentes armazenamentos de dados do aplicativo.
Para reduzir o risco, é essencial que os usuários baixem apenas extensões confiáveis.
Publicidade
Tenha acesso aos melhores hackers éticos do mercado através de um serviço personalizado, especializado e adaptado para o seu negócio. Qualidade, confiança e especialidade em segurança ofensiva de quem já protegeu centenas de empresas. Saiba mais...