🔥 Fique por dentro das novidades mais quentes do momento! 🔥
A notícia que você procurava está aqui!
Apoie esse projeto de divulgacao de noticias! Clique aqui
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 do Gemini”, disse a 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 -
@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 comunicado publicado na semana passada, o Google disse que o impacto é limitado aos 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 são incentivados a revisar seus fluxos de trabalho e adotar uma de duas abordagens:
Se o fluxo de trabalho for executado em entradas confiáveis (por exemplo, revisão de solicitações pull 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 proteger 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 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) possam 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 executaria todas as chamadas de ferramenta automaticamente (incluindo "run_shell_command") sem exigir que o usuário confirmação.
“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.”
Bug do cursor leva à execução de código
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 desonesto configurasse um repositório vazio (".git") com um gancho Git malicioso que é disparado 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 -
O usuário clona um repositório GitHub público com o repositório vazio incorporado contendo um gancho pós-checkout malicioso
O usuário abre o repositório no CursorIDE
Os usuários pedem um prompt inócuo para “explicar a base de código”
O agente Cursor analisa o AGENTS.md que o instrui a navegar até o repositório vazio e executa um "git checkout" do branch master
O gancho pós-checkout dentro do repositório vazio é acionado, levando à execução do código.
“A causa raiz não é uma falha na lógica central 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 o Git de forma autônoma.
“A vulnerabilidade permitiu que um invasor externo sem privilégios 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 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 -
@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 comunicado publicado na semana passada, o Google disse que o impacto é limitado aos 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 são incentivados a revisar seus fluxos de trabalho e adotar uma de duas abordagens:
Se o fluxo de trabalho for executado em entradas confiáveis (por exemplo, revisão de solicitações pull 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 proteger 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 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) possam 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 executaria todas as chamadas de ferramenta automaticamente (incluindo "run_shell_command") sem exigir que o usuário confirmação.
“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.”
Bug do cursor leva à execução de código
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 desonesto configurasse um repositório vazio (".git") com um gancho Git malicioso que é disparado 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 -
O usuário clona um repositório GitHub público com o repositório vazio incorporado contendo um gancho pós-checkout malicioso
O usuário abre o repositório no CursorIDE
Os usuários pedem um prompt inócuo para “explicar a base de código”
O agente Cursor analisa o AGENTS.md que o instrui a navegar até o repositório vazio e executa um "git checkout" do branch master
O gancho pós-checkout dentro do repositório vazio é acionado, levando à execução do código.
“A causa raiz não é uma falha na lógica central 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 o Git de forma autônoma.
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #google #corrige #falhas #do #cvss #10 #gemini #cli #ci #rce #e #do #cursor #que #permitem #a #execução #de #código
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário