2026-04-30 00:00
← VoltarO Google corrigiu uma falha de segurança de gravidade máxima no Gemini CLI – o pacote npm “@google/gemini-cli” e o fluxo de trabalho do GitHub Actions “google-github-actions/run-gemini-cli” – que poderia ter permitido que invasores executassem comandos arbitrários em sistemas host. “A vulnerabilidade permitiu que um invasor externo sem privilégios forçasse o carregamento de seu próprio conteúdo malicioso como configuração Gemini”, disse Novee Security em um relatório de quarta-feira. “Isso desencadeou a execução de comandos diretamente no sistema host, ignorando a segurança antes mesmo de a sandbox do agente ser inicializada.” A deficiência, que não possui identificador CVE, possui pontuação CVSS de 10,0. Afeta as seguintes versões - Em seu comunicado publicado na semana passada, o Google disse que o impacto é limitado a fluxos de trabalho que usam Gemini CLI no modo headless, acrescentando que qualquer uso da ferramenta no modo headless sem confiança de pasta exigirá revisão manual para configurar esse mecanismo de confiança. “Nas versões anteriores, o Gemini CLI executado em ambientes CI (modo headless) confiava automaticamente nas pastas do espaço de trabalho com a finalidade de carregar variáveis de configuração e de ambiente”, disse. "Isso é potencialmente arriscado em situações em que o Gemini CLI é executado em pastas não confiáveis no modo headless (por exemplo, fluxos de trabalho de CI que analisam solicitações pull enviadas pelo usuário). Se usado com conteúdo...
O Google corrigiu uma falha de segurança de gravidade máxima no Gemini CLI – o pacote npm “@google/gemini-cli” e o fluxo de trabalho do GitHub Actions “google-github-actions/run-gemini-cli” – que poderia ter permitido que invasores executassem comandos arbitrários em sistemas host. “A vulnerabilidade permitiu que um invasor externo sem privilégios forçasse o carregamento de seu próprio conteúdo malicioso como configuração Gemini”, disse Novee Security em um relatório de quarta-feira. “Isso desencadeou a execução de comandos diretamente no sistema host, ignorando a segurança antes mesmo de a sandbox do agente ser inicializada.” A deficiência, que não possui identificador CVE, possui pontuação CVSS de 10,0. Afeta as seguintes versões - Em seu comunicado publicado na semana passada, o Google disse que o impacto é limitado a fluxos de trabalho que usam Gemini CLI no modo headless, acrescentando que qualquer uso da ferramenta no modo headless sem confiança de pasta exigirá revisão manual para configurar esse mecanismo de confiança. “Nas versões anteriores, o Gemini CLI executado em ambientes CI (modo headless) confiava automaticamente nas pastas do espaço de trabalho com a finalidade de carregar variáveis de configuração e de ambiente”, disse. "Isso é potencialmente arriscado em situações em que o Gemini CLI é executado em pastas não confiáveis no modo headless (por exemplo, fluxos de trabalho de CI que analisam solicitações pull enviadas pelo usuário). 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 .gemini/ local." Essa confiança automática da pasta do espaço de trabalho atual significava que a ferramenta poderia carregar qualquer configuração de agente encontrada sem revisão, sandbox ou consentimento explícito do usuário. Um invasor pode transformar esse comportamento em uma arma, implantando uma configuração especialmente criada que poderia abrir caminho para a execução de código no host que executa o agente, transformando efetivamente pipelines de CI/CD em caminhos de ataque à cadeia de suprimentos.
A atualização resolve o problema exigindo que as pastas sejam explicitamente confiáveis antes que os arquivos de configuração possam ser acessados. Para esse fim, os usuários estão sendo incentivados a revisar seus fluxos de trabalho e adotar uma de duas abordagens - A gigante da tecnologia também observou que está tomando medidas para fortalecer a lista de permissões de ferramentas quando o Gemini CLI está configurado para ser executado no modo --yolo para evitar cenários em que entradas não confiáveis (por exemplo, problemas do GitHub enviados pelo usuário) podem levar à execução remota de código por meio de injeção imediata, aproveitando o fato de que o modo de aprovação automática ignoraria qualquer lista de permissões em "~/.gemini/settings.json" e execute 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ítica Gemini CLI agora avalia a lista de permissões de ferramentas no modo --yolo, o que é útil para fluxos de trabalho de CI que listam alguns comandos seguros para execução 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 adequarem à tarefa.” A divulgação ocorre no momento em que a Novee Security também destacou uma vulnerabilidade de alta gravidade na ferramenta de desenvolvimento Cursor, alimentada por IA, anterior à versão 2.5 (CVE-2026-26268, pontuação CVSS: 8.1) que também poderia levar à execução arbitrária de código por meio de uma injeção imediata. Cursor, em um alerta lançado em fevereiro de 2026, descreveu-o como um caso de escape de sandbox por meio de configurações .git, permitindo que um agente não autorizado configure um repositório vazio (".git") com um gancho Git malicioso que é acionado automaticamente sempre que uma operação de commit é executada dentro do contexto do repositório incorporado sem exigir qualquer interação do usuário. O resultado final é a execução de código arbitrário aprovado automaticamente na máquina da vítima por meio da seguinte sequência de ações - "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, 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 ele não controla", disse o pesquisador de segurança Assaf Levkovich. "Quando o agente executa git checkout como parte do cumprimento Ao executar uma solicitação de rotina, ele não está fazendo nada que o usuário não tenha autorizado implicitamente. Mas nem o usuário nem o agente têm visibilidade sobre o que as Regras do Cursor do repositório acionaram.
Um gancho de pré-confirmação malicioso incorporado em um repositório vazio aninhado é executado silenciosamente, fora da cadeia de raciocínio do agente e fora do campo de visão do usuário." As descobertas também coincidem com a descoberta de outra vulnerabilidade de controle de acesso de alta gravidade no IDE (pontuação CVSS: 8.2) que pode permitir que qualquer extensão instalada acesse chaves e credenciais de API confidenciais armazenadas localmente em um banco de dados SQLite, permitindo o controle de contas, exposição de dados e perdas financeiras decorrentes do uso não autorizado da API. O problema, codinomeCursorJackingby LayerX, permanece sem patch. "O Cursor não impõe limites de controle de acesso entre as extensões e este banco de dados", disse o pesquisador do 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 back-end do Cursor e roubo de dados por meio da representação do usuário." o acesso ao sistema de arquivos pode potencialmente extrair informações valiosas de vários armazenamentos de dados de aplicativos. Para combater a ameaça, é essencial que os usuários se limitem ao download de extensões confiáveis. Aprenda como impedir ataques do tipo paciente zero antes que eles ignorem a detecção e comprometam seus sistemas em pontos de entrada – tudo gratuitamente.