Vulnerabilidade crítica em Gemini CLI e GitHub Actions expõe a cadeia de fornecimento de CI a execução remota de código

O Google corrigiu uma vulnerabilidade crítica em Gemini CLI (o pacote npm @google/gemini-cli) e no fluxo de trabalho do GitHub Actions google-github-actions/run-gemini-cli que permitia executar comandos arbitrários no sistema anfitrião quando a ferramenta era usada em modo headless dentro da CI. A raiz do problema foi uma confiança implícita na pasta de trabalho: em versões afetadas a CLI carregava configurações e variáveis de ambiente desde .gemini/ sem validação quando corria em ambientes automatizados, o que abria a porta a que conteúdo malicioso plantado por um atacante fosse tratado como configuração legítima e detonaria execução remota de código.

O defeito, qualificado com uma severidade máxima (CVSS 10.0) por pesquisadores externos, exemplifica como um atalho de usabilidade em pipelines automatizados torna-se um vetor de ataque da cadeia de fornecimento: análise de pull requests, forks ou conteúdos de terceiros podem se tornar armadilhas se uma ferramenta assume que o workspace é confiável. O Google mitigou o risco obrigando agora a marcar explicitamente as pastas como confiáveis antes de ler arquivos de configuração e propondo variáveis de ambiente e configurações concretas para workflows, além de endurecer as verificações de allowlist quando a CLI é executada com --yolo.

Se você usa Gemini CLI no GitHub Actions, a ação imediata é atualizar para versões corrigidas: instala @google/gemini-cli em versões iguais ou superiores às que corrigem a falha (as versões vulneráveis são as indicadas pelo fornecedor) e atualizam google-github-actions/run-gemini-cli à versão 0.1.22 ou posterior. Verifique a página do repositório para obter as releases e o guia de configuração: google-github-actions/run-gemini-cli e o pacote npm @google/gemini-cli em npm.

Não basta actualizar: audita seus workflows. Se o seu fluxo processar apenas entradas de colaboradores de confiança, você pode optar por estabelecer GEMINI_TRUST_WORKSPACE: 'true' no ambiente do job, mas não o faça se você aceita contribuições de terceiros ou forks. Para inputs não confiáveis, segue o guia oficial de endurecimento e trata o workspace como hostile: monta runners efêmeros, limita permissões de Actions com o mínimo necessário, deshabilita acesso desnecessário a secrets e emprega regras rigorosas de allowlist para qualquer funcionalidade que execute comandos ou processos.

Além disso, o Google mudou o comportamento de --yolo (modo de auto-aprovação) para que a política de allowlist de ferramentas também se avalie nesse modo; isso evita que chamadas a funções perigosas como run_shell_command sejam executadas sem restrições. No entanto, a mudança pode provocar falhas silenciosas em workflows anteriores, pelo que convém rever e ajustar as allowlists para manter a funcionalidade requerida sem sacrificar segurança.

O caso de Gemini deve ser lido em conjunto com outras vulnerabilidades recentes em ferramentas impulsionadas por IA. Pesquisadores também descreveram um vetor em Cursor IDE que permitiu execução arbitrária através de técnicas de prompt injection e hooks Git maliciosos dentro de repositórios “embebidos” (.git), além de uma falha de controle de acesso que permitia a extensões locais ler credenciais armazenadas em bases SQLite. Esses incidentes reforçam um padrão: os agentes autônomos que realizam operações Git ou sistemas que concedem privilégios a extensões podem converter características legítimas em vetores de ataque quando combinados com repositórios ou pacotes maliciosos.

O que fazer frente a estas ameaças: em primeiro lugar, Aplicação de adesivos imediatamente Inscreva-se a avisos de segurança dos projetos que você usa. Em segundo lugar, reduz a superfície de ataque em CI: executores efêmeros, separação de permissões por job, revisão manual de PRs de forks antes de executar workflows que processam o conteúdo e digitalização automatizado de artefatos entrantes. O GitHub mantém recomendações úteis sobre o endurecimento de Actions que convém seguir: Security hardening for GitHub Actions.

Para ferramentas de desenvolvimento locais como Cursor, a prática mínima é não abrir repositórios desconhecidos em ambientes com agentes que actuem automaticamente, evitar instalar extensões de origem não fiáveis e limitar o acesso das extensões ao sistema de ficheiros. Se você já trabalha com segredos locais ou chaves API, rota credenciais expostas e usa gestores de segredos e contas de serviço com privilégios limitados para CI em vez de tokens pessoais.

Finalmente, adota defesas em profundidade: integra análise estática e digitalização de dependências em sua pipeline, habilita políticas de segurança que inspeccionem arquivos de configuração (incluindo dotfiles como .git e .gemini), e estabelece procedimentos de aprovação humana quando um agente vai executar mudanças no sistema. A conveniência dos agentes da IA e das ferramentas automatizadas não deve substituir controlos básicos de isolamento e revisão; a segurança defensiva continua a ser a melhor proteção contra exploits encobertos na cadeia de abastecimento.