Falhas em agentes de IA para desenvolvimento mostram como confiança automática em diretórios, prompt injection indireto e interações com Git podem transformar fluxos de CI e IDEs em caminhos de execução não autorizada.
| Componente | Pacote npm @google/gemini-cli, ação google-github-actions/run-gemini-cli e IDE Cursor em cenários com agentes de IA executando operações sobre repositórios. |
| Vetor | Carregamento automático de configuração em diretórios não confiáveis no modo headless do Gemini CLI, uso de prompt injection indireto em fluxos autoaprovados e interação do Cursor com configurações e ganchos Git em repositórios controlados por terceiros. |
| Impacto | Execução arbitrária de comandos no host do CI para a falha crítica do Gemini CLI; execução de código no Cursor anterior à versão 2.5 para CVE-2026-26268; e risco de acesso local a tokens e chaves armazenados em banco SQLite do Cursor no caso CursorJacking. |
| Prioridade | Revisar workflows que executam agentes de IA sobre conteúdo não confiável, exigir confiança explícita de diretório, restringir allowlists de ferramentas, atualizar componentes afetados e auditar extensões instaladas. |
| Versões | Gemini CLI corrigido com mudança de confiança explícita em pastas e política de allowlist no modo --yolo a partir da versão 0.39.1; Cursor afetado antes da versão 2.5 para CVE-2026-26268. |
| Artefatos | Diretório local .gemini/, variável GEMINI_TRUST_WORKSPACE, arquivo ~/.gemini/settings.json, ferramenta run_shell_command, configurações .git e banco SQLite local usado pelo Cursor para dados sensíveis. |
O caso envolve uma falha de severidade máxima no Gemini CLI, incluindo o pacote npm @google/gemini-cli e o workflow google-github-actions/run-gemini-cli, capaz de permitir execução arbitrária de comandos no sistema que hospeda o agente. A condição crítica aparece quando o Gemini CLI é executado em modo headless dentro de ambientes de CI e passa a confiar automaticamente no diretório de trabalho para carregar configuração e variáveis de ambiente. Em pipelines que analisam pull requests, issues ou outros conteúdos enviados por usuários externos, essa confiança implícita cria uma fronteira fraca entre entrada não confiável e execução privilegiada no host de automação.
A raiz do problema está no carregamento de configuração de agente antes de uma revisão explícita de confiança do diretório. Se um invasor consegue introduzir conteúdo malicioso em uma pasta processada pelo workflow, o agente pode carregar arquivos de configuração locais sob .gemini/ e acionar comportamento que resulta em execução de comandos. O risco é amplificado em ambientes de integração contínua porque o host costuma ter acesso a tokens de workflow, permissões de repositório e variáveis sensíveis necessárias à automação. A correção muda esse modelo ao exigir que pastas sejam explicitamente confiáveis antes que arquivos de configuração sejam acessados.
A mesma leva de descobertas também expõe riscos no Cursor, uma IDE com recursos de IA. A vulnerabilidade CVE-2026-26268, avaliada com CVSS 8.1, afeta versões anteriores à 2.5 e permite execução arbitrária de código por uma cadeia que combina prompt injection, regras do agente e comportamento do Git em repositórios não controlados pelo usuário. Outro problema de controle de acesso, chamado CursorJacking e avaliado com CVSS 8.2, envolve a possibilidade de extensões instaladas acessarem chaves de API e credenciais salvas localmente em um banco SQLite. Esse segundo problema foi descrito como não corrigido no material analisado.
No Gemini CLI, o cenário de risco depende de execução em modo headless, típico de CI, e de conteúdo de diretório que não deveria ser tratado como confiável. Antes da correção, o agente confiava automaticamente na pasta corrente para carregar configuração e variáveis de ambiente. Em um workflow que processa contribuições externas, um atacante poderia inserir uma configuração preparada para ser interpretada pelo agente. O ponto crítico é que a configuração era avaliada antes de uma decisão explícita de confiança, reduzindo a utilidade de controles posteriores como sandbox ou confirmação manual do usuário.
O modo --yolo adiciona outra superfície relevante porque foi descrito como um modo de autoaprovação em que chamadas de ferramenta poderiam ser executadas sem confirmação. A correção na versão 0.39.1 passa a avaliar allowlists de ferramentas mesmo nesse modo. Isso importa para pipelines que pretendem permitir apenas um conjunto pequeno de ações consideradas seguras. Se a allowlist permitir ferramentas capazes de ler arquivos ou interagir com o sistema de maneira ampla, o controle continua frágil: a defesa depende tanto da existência da allowlist quanto da precisão das entradas autorizadas.
No Cursor, CVE-2026-26268 usa uma interação entre agente de IA, instruções em repositório e Git. O fluxo descrito começa quando um usuário clona um repositório público que contém um repositório bare incorporado com gancho malicioso. O agente interpreta instruções locais e realiza uma operação Git dentro desse contexto. O gancho configurado no repositório aninhado é disparado automaticamente durante a operação e leva à execução de código na máquina da vítima. A falha não depende de o usuário executar manualmente um payload; o perigo está na automação do agente realizando ações Git que parecem rotineiras, mas atravessam uma configuração controlada pelo repositório.
O problema CursorJacking é diferente: ele trata de isolamento insuficiente entre extensões instaladas e o banco local em SQLite usado para armazenar dados sensíveis, como tokens de sessão e chaves de API. O impacto exige uma extensão com acesso local ao sistema de arquivos, o que limita o cenário a máquinas onde o usuário já instalou e concedeu permissões a uma extensão. Ainda assim, em ambientes de desenvolvimento, esse limite não elimina o risco, pois extensões frequentemente operam com ampla visibilidade sobre o workspace, arquivos locais e dados de aplicação.
A superfície principal são pipelines de CI/CD que executam agentes de IA sobre conteúdo criado por usuários ou colaboradores externos. Workflows que revisam pull requests de forks, analisam issues, geram comentários automáticos ou processam diretórios extraídos de contribuições não confiáveis devem ser tratados como prioritários. O risco não está apenas no pacote em si, mas na combinação entre permissões do runner, acesso a variáveis de ambiente, token do repositório e capacidade do agente de chamar ferramentas do sistema.
No caso do Cursor, a superfície inclui estáções de desenvolvimento que abrem repositórios públicos ou de terceiros e permitem que o agente execute operações Git de forma autônoma. Também entram no escopo ambientes com extensões de origem pouco confiável, especialmente quando a IDE mantém credenciais, chaves de API ou tokens de sessão em armazenamento local acessível por essas extensões. Organizações que usam agentes de IA em engenharia devem mapear essas ferramentas como parte da superfície de identidade e supply chain, não apenas como editores de código.
- Workflows do Gemini CLI em modo headless que analisam diretórios não confiáveis ou pull requests enviados por terceiros.
- Configurações locais em
.gemini/e variáveis de ambiente carregadas automaticamente pelo agente antes da correção. - Execução do Gemini CLI em modo
--yolocom allowlists permissivas ou ferramentas capazes de ler arquivos sensíveis. - Cursor anterior à versão 2.5 em fluxos nos quais agentes executam operações Git dentro de repositórios externos.
- Instalações do Cursor com extensões não verificadas e acesso local ao banco SQLite que armazena credenciais ou chaves.
A investigação defensiva deve começar pelos logs de CI e pelas alterações recentes em workflows que invocam o Gemini CLI. Procure execuções em modo headless associadas a pull requests, issues ou diretórios originados de usuários externos. Eventos relevantes incluem carregamento de configuração a partir de .gemini/, mudanças inesperadas em variáveis de ambiente, chamadas de ferramentas não previstas e tentativas de leitura de arquivos sensíveis do workspace ou do ambiente do runner. Como o contexto descreve risco de extração de segredos em cenários de prompt injection e autoaprovação, logs de rede do runner também devem ser revisados para conexões incomuns durante a execução do agente.
Para Cursor, a telemetria deve focar em repositórios clonados recentemente, presença de repositórios bare aninhados, ganchos Git inesperados e operações Git disparadas por agente sem intervenção clara do usuário. No caso CursorJacking, a prioridade é identificar extensões instaladas com origem desconhecida, acesso frequente ao diretório de dados da aplicação e leitura do banco SQLite local. Em endpoints corporativos, EDR e auditoria de sistema de arquivos podem ajudar a correlacionar processo da IDE, processo de extensão e acesso a arquivos de credenciais.
- Execuções de CI que usam Gemini CLI em modo headless sobre pull requests, issues ou conteúdo de forks.
- Leitura ou carregamento inesperado de arquivos sob
.gemini/em diretórios submetidos por terceiros. - Uso de
--yoloacompanhado de chamadas de ferramenta fora do conjunto estritamente necessário ao workflow. - Tentativas de acesso a
~/.gemini/settings.json, arquivos de configuração Git, dados de repositório e variáveis sensíveis do runner. - Repositórios com configuração
.gitaninhada, ganchos Git inesperados ou operação de checkout disparada por agente. - Extensões do Cursor acessando banco SQLite local, tokens de sessão ou chaves de API sem justificativa operacional.
A mitigação do Gemini CLI exige separar claramente conteúdo confiável de conteúdo não confiável. Workflows que operam apenas sobre entradas de colaboradores confiáveis podem configurar confiança explícita do workspace por meio de GEMINI_TRUST_WORKSPACE. Para fluxos que processam contribuições externas, a resposta adequada é revisar a orientação de endurecimento do workflow, evitar confiança automática de diretório, restringir permissões do token do CI e reduzir o conjunto de ferramentas disponível ao agente. A variável de confiança não deve ser aplicada de forma ampla em pipelines que analisam conteúdo de terceiros.
Também é necessário revisar allowlists usadas com --yolo. A presença de uma allowlist não é suficiente se ela autoriza ferramentas que leem arquivos, acessam configurações sensíveis ou executam ações genéricas do sistema. A lista deve ser mínima, específica e alinhada à tarefa do workflow. Após atualizar para a versão corrigida, equipes devem validar se jobs críticos continuam executando apenas as chamadas esperadas, porque a mudança de política pode fazer fluxos antigos falharem ou se comportarem de forma diferente.
Para Cursor, a primeira ação é atualizar para uma versão que corrija CVE-2026-26268 quando aplicável e reduzir a autonomia do agente sobre repositórios de origem externa. Repositórios públicos devem ser tratados como entrada não confiável até que configurações Git, ganchos e instruções de agente sejam revisados. No problema CursorJacking, a medida imediata é restringir extensões a fornecedores confiáveis, remover extensões desconhecidas, revisar permissões locais e rotacionar chaves de API quando houver evidência de acesso indevido ao armazenamento local.
- Atualizar Gemini CLI e
google-github-actions/run-gemini-clipara versões que exigem confiança explícita de diretório e aplicam allowlist no modo--yolo. - Evitar
GEMINI_TRUST_WORKSPACEem workflows que processam pull requests, issues ou diretórios enviados por usuários não confiáveis. - Reduzir permissões de
GITHUB_TOKENe demais segredos disponíveis para jobs que executam agentes de IA. - Revisar allowlists para remover ferramentas amplas, especialmente as capazes de ler arquivos ou acionar comandos genéricos.
- Atualizar Cursor quando houver correção disponível para
CVE-2026-26268e bloquear execução autônoma de operações Git em repositórios não revisados. - Auditar extensões do Cursor, remover itens não confiáveis e rotacionar chaves locais caso logs indiquem acesso ao banco SQLite ou tokens.
0 Comentários