Vulnerabilidade do agente de IA Plugin4Shell contornou plugins confiáveis, deixando duas ferramentas de programação sem correção

O Plugin4Shell comprometeu uma salvaguarda central em quatro agentes de programação com IA, embora os usuários seguissem o processo esperado para instalar plugins revisados. A empresa de segurança AIR afirma que a falha afetou Claude Code, OpenAI Codex, GitHub Copilot e Gemini CLI. Seus pesquisadores demonstraram execução remota de código funcional contra os quatro produtos.

Anthropic e OpenAI lançaram correções após receberem a divulgação da AIR. A AIR relatou não haver correção correspondente para o GitHub Copilot quando publicou suas conclusões em 17 de setembro de 2026. A empresa também afirmou que o Google não corrigiria o comportamento afetado do Gemini CLI, orientando os usuários a migrarem para o Antigravity.

Essa resposta desigual é o problema central. Marketplaces de plugins prometem que a revisão e a fixação de commits protegem os desenvolvedores contra alterações de código após a aprovação. A vulnerabilidade do agente de IA Plugin4Shell teria quebrado essa promessa sem exigir uma instalação descuidada, uma aprovação suspeita ou um novo clique.

Plugin4Shell transformou uma atualização confiável em execução remota de código

O ataque mirou o processo de distribuição de plugins, não o modelo de linguagem que decide como responder a um prompt.

Agentes de programação com IA oferecem cada vez mais suporte a plugins, skills, extensões e outros complementos. Esses pacotes podem personalizar fluxos de trabalho, conectar serviços ou executar código em ambientes de desenvolvimento. Muitas vezes, eles herdam a capacidade do agente de acessar arquivos, executar comandos de shell e interagir com sistemas autenticados.

Esse acesso torna um plugin de agente mais próximo de um aplicativo local do que de um prompt de texto passivo. Se código malicioso chega ao diretório de plugins, ele pode operar com as permissões concedidas ao desenvolvedor que executa o agente.

A AIR afirma que o Plugin4Shell chegou a esse ponto ao contornar a fixação por SHA. Um SHA é um identificador criptográfico normalmente usado para nomear um commit específico do Git. Fixar um plugin a esse identificador deveria manter seu código instalado imutável, mesmo quando seu repositório muda posteriormente.

Segundo a pesquisa sobre Plugin4Shell, os agentes afetados solicitavam um commit fixado, mas não verificavam se o commit realmente havia sido obtido no checkout. Um invasor que controlasse o repositório upstream poderia explorar o comportamento de resolução de nomes do Git e substituir o código por outro.

O registro no marketplace ainda poderia exibir o identificador de commit esperado. O agente também poderia informar uma instalação bem-sucedida. No entanto, os arquivos no diretório de trabalho viriam de uma branch controlada pelo invasor, e não do commit revisado.

A AIR descreveu dois caminhos práticos de entrada. Um invasor poderia publicar um plugin legítimo, conquistar adoção e tornar o repositório malicioso em uma atualização posterior. Alternativamente, poderia assumir o controle do repositório que sustenta um plugin existente.

O segundo caminho importa porque transfere a responsabilidade para além dos autores individuais de plugins. Um plugin pode começar como um projeto legítimo e passar por todas as revisões. Seu repositório pode se tornar hostil somente depois que desenvolvedores e equipes de segurança já tenham confiado nele.

A AIR afirma que os pesquisadores encontraram o problema em maio de 2026 e o divulgaram aos quatro fornecedores em junho. A empresa publicou seu relato técnico em 17 de setembro. A Help Net Security noticiou as conclusões no dia seguinte.

Nenhuma evidência pública citada por qualquer uma das organizações mostrou que o Plugin4Shell tenha sido explorado contra vítimas reais antes da divulgação. O impacto demonstrado vem dos testes de prova de conceito da AIR, e não de uma campanha criminosa documentada.

Essa distinção limita o que pode ser afirmado sobre comprometimento imediato. Ela não reduz a importância do controle quebrado. Um ataque bem-sucedido executaria código por meio de um componente que as organizações já haviam revisado e aprovado.

O problema também se segue a pesquisas anteriores da AIR sobre distribuição de plugins. A empresa afirma que uma skill de teste chegou a mais de 26.000 agentes antes de ser removida. Uma pesquisa separada teria identificado 925 skills sequestradas que afetavam 134.000 agentes.

Esses números vêm da AIR e não foram reproduzidos de forma independente na divulgação do Plugin4Shell. Eles ilustram o argumento mais amplo dos pesquisadores: conquistar distribuição e comprometer repositórios upstream são etapas realistas, não apenas pré-requisitos teóricos.

Como a vulnerabilidade do agente de IA Plugin4Shell contornou a fixação por SHA

O Plugin4Shell funcionou porque cada agente afetado confiou na referência Git solicitada em vez de verificar o commit final obtido no checkout.

Claude Code, Codex e GitHub Copilot teriam compartilhado uma variante. Seus instaladores de plugins clonaram um repositório e passaram o identificador de commit fixado de 40 caracteres para git checkout.

O Git permite nomes de branches que se assemelham a identificadores de commit em muitas configurações de hospedagem. Quando um nome pode identificar tanto uma branch quanto um objeto, o Git pode resolvê-lo como uma referência enquanto exibe um aviso de ambiguidade.

Um invasor que controlasse o repositório do plugin poderia criar uma branch com exatamente o mesmo nome do commit fixado. Em seguida, tornaria essa branch o padrão do repositório e a apontaria para código malicioso.

O clone inicial baixaria a branch padrão do invasor. O checkout seguinte poderia resolver o aparente identificador de commit para essa branch local. O agente então carregaria ou executaria arquivos diferentes daqueles revisados pelo marketplace.

Essa técnica não funciona de forma idêntica em todos os serviços de hospedagem. O GitHub bloqueia nomes de branches e tags que se parecem com identificadores completos de objetos Git, segundo suas restrições de nomes de branches.

No entanto, a AIR afirma que Bitbucket e serviços Git auto-hospedados podem aceitar esses nomes. Alguns marketplaces de agentes oferecem suporte oficial a repositórios hospedados fora do GitHub, deixando a configuração mais ampla exposta.

O Gemini CLI teria usado uma rota separada para o mesmo resultado. Seu instalador buscava o commit fixado e depois executava um checkout contra FETCH_HEAD, uma referência Git que normalmente aponta para conteúdo obtido por fetch.

A AIR descobriu que um repositório poderia usar FETCH_HEAD como nome de sua branch padrão. O checkout poderia então ser resolvido para essa branch, em vez do arquivo especial que contém o commit obtido.

Ambas as variantes dependiam da ausência de uma comparação final. Após concluir o checkout, o agente precisava resolver HEAD e verificar se ele era igual ao SHA fixado pelo marketplace.

Essa verificação é pequena, mas sua localização importa. Um marketplace não pode confirmar o que um cliente acabou colocando em sua árvore de trabalho local. A verificação precisa ocorrer dentro do agente que executa o clone e o checkout.

O rótulo de zero clique vem das atualizações em segundo plano. A AIR afirma que Claude Code e Codex atualizam automaticamente os plugins instalados por padrão. Uma substituição maliciosa poderia, portanto, chegar depois que um marketplace alterasse sua fixação, sem outra decisão de instalação.

A vítima não precisaria encontrar um novo plugin malicioso. O invasor miraria um plugin já presente na máquina e aguardaria o processo de atualização do agente.

Execução remota de código, ou RCE, significa que instruções controladas pelo invasor são executadas no sistema-alvo. O alcance resultante depende da conta, do ambiente, do sandbox, das credenciais e do acesso à rede disponíveis para o agente afetado.

A AIR descreve o impacto potencial como equivalente ao acesso detido pelo funcionário que executa a ferramenta. Essa é uma descrição de pior caso, não uma medição universal de todas as instalações.

Um agente rigidamente isolado pode expor apenas um espaço de trabalho temporário. Um agente instalado localmente com credenciais de nuvem, repositórios de código-fonte, chaves de assinatura ou acesso à produção cria um raio potencial de impacto muito maior.

Essa variabilidade explica por que apenas o inventário de versões é insuficiente. As equipes de segurança também precisam saber onde cada agente é executado, quais plugins ele carrega e quais credenciais estão disponíveis dentro desse limite de execução.

A revisão de plugins funcionou como projetado, mas o código instalado ainda mudou

O conflito central está entre a promessa de revisão imutável e a realidade da resolução Git no lado do cliente.

Os controles da cadeia de suprimentos de software costumam separar aprovação de execução. Um revisor avalia uma versão conhecida, registra seu digest e permite que os sistemas instalem somente essa versão.

Esse modelo pressupõe que o digest identifica os arquivos que serão executados. O Plugin4Shell teria preservado a fixação visível, ao mesmo tempo em que quebrou a ligação entre essa fixação e a árvore de trabalho final.

Isso é mais grave do que alertar os usuários contra extensões desconhecidas. Os pesquisadores afirmam que o ataque ainda funciona quando um plugin vem de um marketplace confiável, passa por revisão e permanece fixado.

Portanto, orientações de segurança baseadas apenas na reputação do marketplace deixariam de fora a etapa vulnerável. O invasor não precisa comprometer o banco de dados do marketplace se o agente local puder ser enganado durante o checkout.

A mesma limitação se aplica a catálogos internos de plugins. Uma empresa pode revisar todos os pacotes e espelhar metadados aprovados. Esses controles continuam incompletos se os clientes dos funcionários não validarem o commit resolvido.

A AIR chama o Plugin4Shell de primeira vulnerabilidade da cadeia de suprimentos do ecossistema de agentes de IA. Essa formulação é a caracterização da empresa e merece alguma cautela.

Ferramentas de desenvolvimento com IA já enfrentaram envenenamento de repositórios, injeção de prompt, arquivos de configuração maliciosos e vulnerabilidades relacionadas a extensões. O Plugin4Shell é mais restrito em um sentido porque se concentra em complementos de agentes fixados e em seu caminho de atualização.

Ainda assim, o mecanismo expõe uma falha distinta de confiança. Ele ataca a forma como funcionalidades de agentes revisadas chegam de um repositório à máquina de um desenvolvedor.

Pesquisas recentes mostram que este não é um ponto de pressão isolado. A Wiz divulgou o GhostApproval em julho de 2026 após testar seis assistentes de programação com IA. Esse problema usava links simbólicos para alcançar arquivos fora dos limites esperados do espaço de trabalho.

As conclusões sobre GhostApproval afetaram produtos da Amazon, Anthropic, Augment, Cursor, Google e Windsurf. As respostas dos fornecedores variaram, com várias correções e pelo menos uma decisão contestada sobre o modelo de ameaças.

GhostApproval e Plugin4Shell usam primitivas técnicas diferentes. Um explora a resolução de caminhos por meio de links simbólicos. O outro teria explorado a resolução de referências Git durante a instalação e as atualizações de plugins.

O padrão que os conecta é uma lacuna entre a decisão visível do usuário e a ação real do sistema. Um caminho parece local, mas é resolvido em outro lugar. Uma fixação parece imutável, mas é resolvida para código diferente.

Somente prompts de permissão não podem corrigir essa incompatibilidade. Os usuários não podem tomar decisões informadas quando a interface exibe o nome confiável, enquanto a operação subjacente mira outra coisa.

A Anthropic descreveu publicamente o isolamento de sistema de arquivos e rede como salvaguardas complementares para o Claude Code. Seu modelo de sandboxing busca impedir que um processo injetado alcance arquivos sensíveis ou destinos de rede não autorizados.

O sandboxing pode reduzir o impacto de código malicioso em plugins. Ele não substitui a verificação precisa de pacotes, especialmente quando os plugins são executados fora das mesmas restrições ou recebem permissões mais amplas.

Portanto, as empresas precisam de dois limites independentes. O processo de instalação deve verificar se o código revisado foi realmente instalado. O ambiente de execução deve limitar o que esse código pode alcançar após a execução.

Uma falha em qualquer uma das camadas não deveria automaticamente se transformar em um comprometimento da estação de trabalho ou da conta de nuvem. Plugin4Shell importa porque muitas implantações de agentes ainda combinam extensões mutáveis com credenciais locais valiosas.

Quatro Agentes de Programação Produziram Quatro Resultados de Segurança Diferentes

A divulgação expôs um processo fragmentado de correção entre ferramentas que implementam fluxos de trabalho de plugins semelhantes.

A AIR afirma que a Anthropic corrigiu a vulnerabilidade do Claude Code na versão 2.1.179. A empresa registrou 17 de junho de 2026 como a data em que a Anthropic confirmou a correção.

A OpenAI corrigiu o comportamento afetado do Codex na versão 0.146.0, segundo a AIR. A cronologia da pesquisa diz que a empresa verificou essa versão como corrigida em 12 de agosto.

Usuários desses produtos não devem presumir que as atualizações automáticas foram concluídas com sucesso. Estações de trabalho gerenciadas, ambientes offline, bloqueios de pacotes e sistemas internos de distribuição podem deixar versões mais antigas instaladas.

As organizações devem consultar os endpoints reais e comparar suas versões com as versões corrigidas. Também devem reiniciar sessões de longa duração caso seu processo de implantação não substitua processos ativos do agente.

O GitHub Copilot apresenta um problema diferente. A AIR afirmou que a Microsoft recebeu o mesmo relatório de vulnerabilidade, mas ainda não havia lançado uma correção quando a pesquisa se tornou pública.

O GitHub havia expandido recentemente os controles centralizados para operações de agentes. Seu anúncio de 9 de setembro dizia que administradores poderiam bloquear, permitir ou exigir aprovação para comandos de shell, operações de arquivo e domínios de rede por meio de permissões gerenciadas de agentes.

Esses controles podem limitar as consequências, mas não são evidência de uma correção para o Plugin4Shell. Um instalador sem correção e uma política de execução restritiva abordam etapas diferentes do ataque.

Administradores do Copilot devem, portanto, buscar um aviso específico do produto, uma versão corrigida ou confirmação do fornecedor. Até lá, as organizações podem suspender atualizações de plugins do marketplace ou limitar os agentes a repositórios aprovados sob seu controle.

O Gemini CLI tem o status mais complicado. A AIR afirma que o Google confirmou em 4 de agosto que não corrigiria o fluxo de trabalho afetado e aconselhou a migração para o Antigravity.

O Google já havia começado a migrar usuários individuais do Gemini CLI para o Antigravity CLI. Um anúncio de junho disse que o Gemini CLI deixou de atender solicitações para contas individuais, enquanto o uso empresarial e por chave de API permaneceu disponível.

No entanto, o aviso de transição anterior do Google também dizia que o projeto open source Gemini CLI continuaria recebendo atualizações de modelos, correções de bugs e correções de segurança para clientes empresariais.

Essa linguagem pública não se alinha perfeitamente à alegação de que todas as instalações do Gemini CLI permanecerão vulneráveis indefinidamente. Ela deixa uma lacuna importante de verificação para os administradores.

O changelog de setembro do Google mostra que as versões do Gemini CLI continuaram após a transição dos consumidores. Ele também lista reforços de segurança não relacionados à falha específica de checkout. Essa atividade não estabelece uma correção para o Plugin4Shell.

A conclusão cautelosa é mais restrita. A AIR informou que não havia correção para o Plugin4Shell no Gemini CLI no momento da divulgação e recomendou o Antigravity. O Google continuou mantendo partes do Gemini CLI para uso empresarial, mas nenhuma nota de versão citada identifica essa correção específica.

Usuários empresariais não devem inferir segurança a partir de linguagem geral de manutenção. Eles precisam de confirmação direta de que sua versão verifica o commit final obtido após instalar ou atualizar uma extensão.

Também devem evitar tratar a migração como uma simples mudança de nome. Mover skills, hooks, servidores MCP e credenciais para um novo agente pode reproduzir outros riscos caso as configurações sejam transferidas sem revisão.

A AIR afirma que o Antigravity não usa o mecanismo de fixação de SHA de plugins explorado pelo Plugin4Shell. Isso significa que esse caminho específico não se aplica, com base na análise dos pesquisadores.

Isso não significa que o Antigravity seja imune a plugins maliciosos, injeção de prompt, ferramentas inseguras ou futuras falhas na cadeia de suprimentos. As equipes de segurança devem manter os mesmos requisitos de isolamento e privilégio mínimo após a migração.

As quatro respostas revelam um problema de governança que vai além deste bug. Recursos semelhantes podem ser lançados em vários agentes sem convenções compartilhadas de divulgação, pontuação comum de severidade ou remediação sincronizada.

Os desenvolvedores precisam acompanhar changelogs e declarações de fornecedores separados. Em seguida, os administradores empresariais precisam traduzir esses registros desiguais em uma única postura de segurança aplicável.

O Que as Equipes de Desenvolvimento Devem Mudar Imediatamente

A primeira prioridade é interromper atualizações vulneráveis de plugins, verificar as versões dos agentes e reduzir as credenciais disponíveis para cada agente de programação.

Para o Claude Code, as organizações devem mover todas as instalações para a versão 2.1.179 ou posterior. Para o Codex, a AIR identifica a versão 0.146.0 como a versão corrigida.

As equipes devem verificar versões por meio de um inventário de endpoints, e não de pesquisas. Os desenvolvedores podem usar vários agentes de programação em terminais locais, extensões de IDE, espaços de trabalho remotos e sistemas de CI.

Para o GitHub Copilot, os administradores devem solicitar orientações explícitas de remediação ao GitHub ou à Microsoft. Eles não devem tratar melhorias de permissões não relacionadas como confirmação de que a vulnerabilidade de checkout foi corrigida.

Onde a funcionalidade de plugins não for essencial, desabilitar pacotes de marketplace de terceiros oferece a redução temporária mais clara. Organizações que não puderem desabilitá-los devem pausar atualizações automáticas e restringir as fontes de repositórios.

Usuários do Gemini CLI devem avaliar a migração para o Antigravity, especialmente ao usar extensões de marketplace. Clientes empresariais também devem solicitar confirmação por escrito sobre o status de sua versão exata do Gemini CLI.

Remover um plugin afetado após a divulgação é útil, mas incompleto. Um pacote comprometido pode ter criado persistência, modificado arquivos de inicialização, copiado credenciais ou alterado repositórios antes da remoção.

Equipes de resposta a incidentes devem revisar o histórico de atualizações de plugins, a atividade do Git, a execução de processos, conexões de rede e alterações em arquivos sensíveis. A janela de tempo relevante começa antes da divulgação pública caso atualizações automáticas vulneráveis estivessem ativas.

As equipes devem rotacionar credenciais quando a telemetria indicar que código inesperado de plugin foi executado. Os alvos prioritários incluem tokens de controle de código-fonte, credenciais de nuvem, chaves de publicação de pacotes, material de assinatura e segredos armazenados em ambientes de shell.

O escopo das credenciais importa tanto quanto a rotação. Um agente de programação com IA não deve herdar acesso irrestrito à produção apenas porque o desenvolvedor que o inicia detém essas permissões.

Identidades separadas para agentes facilitam conter e auditar ações anormais. Tokens de curta duração também limitam o valor das credenciais coletadas de uma estação de trabalho.

O isolamento em tempo de execução fornece outra camada. O acesso a arquivos deve, por padrão, limitar-se ao projeto ativo, enquanto o acesso à rede deve usar uma lista de permissões restrita e adequada à tarefa.

A execução de shell exige limites semelhantes. Um plugin que pode invocar qualquer comando sob a conta de um desenvolvedor pode contornar muitos controles aplicados apenas ao código-fonte gerado.

As organizações devem testar se as regras de sandbox abrangem subprocessos criados por plugins, hooks, gerenciadores de pacotes e servidores MCP. Uma restrição sobre as ferramentas diretas do modelo pode não abranger todos os processos de extensão.

A governança de plugins também precisa de evidências mais robustas. Um catálogo interno deve armazenar o commit revisado, a origem do repositório, o identificador da árvore resolvida, o revisor, a data de aprovação e a versão implantada.

O instalador deve validar o HEAD resolvido após o checkout. Se ele não corresponder ao commit aprovado, a instalação deverá parar em vez de emitir um aviso e continuar.

As equipes de segurança podem testar esse comportamento sem reproduzir execução maliciosa. Um repositório controlado pode apresentar referências ambíguas enquanto o sistema de validação verifica se a instalação falha de forma segura.

O resultado deve tornar-se parte das compras e dos testes internos de aceitação. Os fornecedores devem ser capazes de explicar como seus agentes verificam o conteúdo de plugins após clonar, buscar e atualizar.

As equipes também precisam de um registro confiável do motivo da existência de cada plugin. Uma base de conhecimento de engenharia pesquisável pode conectar aprovações, responsáveis, incidentes e decisões de substituição.

Essa documentação não impede a exploração. Ela reduz o tempo necessário para identificar equipes afetadas e remover integrações arriscadas quando surgir outra divulgação.

Por fim, os desenvolvedores não devem ser culpados por confiar em uma fixação anunciada. O Plugin4Shell supostamente contornou um controle projetado para tornar essa confiança razoável.

A ação corretiva se distribui entre o código do fornecedor, a política empresarial e a arquitetura de execução. Treinar usuários para inspecionar cada atualização não pode compensar um instalador que executa código diferente daquele associado ao digest aprovado.

Três Sinais Mostrarão se a Segurança de Plugins de Agentes Está Melhorando

O próximo teste é saber se os fornecedores transformarão esta divulgação em controles verificáveis de instalação, em vez de promessas mais amplas de segurança.

O primeiro sinal é uma remediação específica para o GitHub Copilot. Os administradores devem procurar um aviso de segurança, identificador de versão ou declaração técnica que confirme a verificação do commit após o checkout.

Uma atualização geral do Copilot não responderá à questão. A evidência relevante é se o cliente resolve o HEAD da árvore de trabalho e o compara com a fixação do marketplace.

Se o GitHub documentar esse comportamento e o lançar em todas as superfícies compatíveis do Copilot, a atual lacuna de correção diminuirá. O silêncio contínuo reforçaria preocupações sobre o tratamento inconsistente de vulnerabilidades.

O segundo sinal é o esclarecimento do Google para usuários empresariais do Gemini CLI. A linguagem pública de transição diz que o acesso empresarial e a manutenção de segurança continuam, enquanto a AIR relata não haver correção para o Plugin4Shell.

O Google pode resolver essa tensão ao nomear as versões afetadas, explicar se existe uma correção e definir datas de suporte. Um aviso específico ajudaria as equipes a decidir entre correção e migração.

Se o Gemini CLI receber verificação de commit comprovada, o status relatado pela AIR no momento da divulgação ficará desatualizado. Se o Google confirmar que não receberá, as organizações devem tratar a migração como um requisito de segurança, e não como uma preferência de produto.

O terceiro sinal é a adoção, no nível dos marketplaces, de comportamento verificável do cliente. Marketplaces não podem impor sozinhos o checkout final, mas podem exigir agentes compatíveis e rejeitar configurações inseguras de repositórios.

Mudanças úteis incluiriam manifests assinados, artefatos de pacote imutáveis, atestados de procedência e recibos de instalação contendo o commit resolvido. Cada controle deve continuar testável de forma independente.

Os fornecedores de agentes também devem divulgar se os plugins são executados dentro do mesmo sandbox que os comandos gerados. Um pacote verificado ainda pode ser comprometido a montante antes da revisão ou conter uma vulnerabilidade negligenciada.

A lição maior não é que plugins são inerentemente inseguros. É que agentes autônomos transformam erros de empacotamento em ações realizadas com privilégios de desenvolvedor.

O Plugin4Shell supostamente afetou quatro produtos concorrentes porque suas implementações dependiam da mesma suposição não verificada. O identificador Git solicitado foi tratado como equivalente ao código realmente instalado.

Desenvolvedores e líderes de segurança devem agora fazer uma pergunta direta a cada fornecedor de agentes de programação: o que comprova que o código revisado é o código em execução na máquina?

Até que Copilot e Gemini CLI tenham respostas específicas para seus produtos, as organizações afetadas devem limitar o uso de plugins, verificar todas as versões dos agentes e isolar credenciais. As equipes que usam Claude Code ou Codex corrigidos ainda devem auditar as extensões instaladas e confirmar que as atualizações chegaram a todos os endpoints.

A vulnerabilidade do agente de IA Plugin4Shell é, em última análise, um teste de visibilidade operacional. Sua organização consegue identificar cada agente, seus plugins, sua versão e seus privilégios antes que a próxima atualização em segundo plano seja executada?