Plugin4Shell: Quatro agentes de codificação com IA confiaram em um pin que nunca verificaram

Em 17 de setembro de 2026, a AIR Security, uma startup que cria ferramentas de segurança para agentes de IA empresariais, publicou uma pesquisa descrevendo o Plugin4Shell — uma falha de execução remota de código sem clique em quatro agentes de programação com IA: Claude Code, da Anthropic; Codex, da OpenAI; GitHub Copilot; e Gemini CLI, do Google. O bug não está em nenhum modelo. Ele está no checkout do git que cada agente realiza quando instala um plugin e no fato de que nenhum dos quatro verificou que o código recebido era o código que havia fixado. Dois dos quatro já tinham uma correção quando a pesquisa se tornou pública. Dois não tinham. Este incidente é uma entrada no Orca AI Incident Archive, que o registra como uma vulnerabilidade de alta gravidade na cadeia de suprimentos, sem exploração relatada.

O que os agentes realmente fizeram de errado

Cada agente afetado instala plugins a partir de um marketplace, e cada marketplace fixa um plugin em um commit específico do git — um SHA de 40 caracteres — depois que o plugin tiver sido revisado. Essa fixação é todo o modelo de segurança: um revisor aprova uma versão imutável, e o agente deve continuar executando essa versão mesmo que o repositório por trás dela mude depois. A AIR descreve a falha como um bypass de fixação de SHA de plugin. O agente faz checkout exatamente do commit que o marketplace fixou, mas nunca verifica se a árvore de trabalho com a qual ele termina é realmente esse commit. Nas palavras dos pesquisadores, o agente "faz checkout do commit exato que o marketplace fixou, mas nunca verifica se ele de fato chegou lá, então um atacante que controla o repositório do plugin faz o checkout resolver para código malicioso enquanto a fixação ainda parece respeitada".

O Git supre essa lacuna. Quando um nome é ao mesmo tempo um branch válido e um objeto de commit, o git prefere o branch e apenas imprime um aviso de ambiguidade. Um atacante que controla o repositório do plugin cria um branch cujo nome é exatamente o SHA fixado de 40 caracteres hexadecimais, aponta-o para código malicioso e o torna o branch padrão do repositório. Um clone simples então traz esse branch para o ambiente local sob o nome em formato de SHA, e o checkout subsequente resolve para ele. O próprio commit fixado pode permanecer intacto, de modo que nada na versão revisada parece errado. Segundo o AIR, duas condições precisam ser satisfeitas: o branch com nome de SHA deve ser o branch padrão, porque um branch não padrão é buscado apenas como uma ref de rastreamento remoto e o checkout recairia sobre o commit real; e o host git deve aceitar um nome de branch de 40 caracteres hexadecimais. O GitHub rejeita esses nomes de imediato. O Bitbucket e servidores git auto-hospedados não.

O Gemini CLI falhou por uma rota diferente. Ele buscou o commit fixado, registrou-o no arquivo FETCH_HEAD do repositório e então executou um checkout de FETCH_HEAD — um checkout que não precisa ler esse arquivo. Um repositório cujo branch padrão tem ele próprio o nome FETCH_HEAD redireciona o checkout para conteúdo controlado pelo atacante e descarta silenciosamente o commit que foi buscado. O relato do Cybersecurity News sobre o mecanismo coincide com o da AIR, incluindo a distinção entre as duas variantes.

Por que ninguém precisou clicar em nada

O mesmo checkout é executado novamente durante a atualização automática de plugins em segundo plano, que é o padrão no Claude Code e no Codex. É isso que torna o ataque zero-click em vez de apenas silencioso: quando um marketplace altera um SHA fixado para uma nova versão de rotina, todo agente que já tem o plugin instalado executa o checkout novamente sem prompt e sem ação do usuário. O ponto da AIR é que a vítima não precisa instalar nada de forma descuidada. Ela precisa ter instalado um plugin, de um marketplace em que confia, que foi revisado e fixado exatamente como o design pretende.

Existem duas maneiras de chegar a essa posição, e nenhuma delas exige controlar o marketplace. Na primeira, um atacante publica um plugin genuinamente benigno que passa pela revisão, constrói uma base de instalações, lança uma atualização normal e só então cria a branch com nome malicioso. Na segunda, o atacante assume o repositório por trás de um plugin que outra pessoa escreveu e no qual o marketplace já confia, e então distribui a versão maliciosa para todos que o têm instalado.

Os números por trás dessas duas rotas vêm do trabalho anterior da AIR, não do Plugin4Shell. Em uma campanha que a empresa chama de The Story of Skills, ela afirma que um plugin que desenvolveu se espalhou para mais de 26.000 agentes antes de ser retirado. Em SkillJacking, ela relatou que 925 skills já em uso ativo haviam sido tomadas de seus mantenedores originais, alcançando 134.000 agentes. A manchete da AIR para o post do Plugin4Shell afirma que "milhões de agentes afetados"; a pesquisa não fornece um número de instalações expostas, e nenhum terceiro publicou um.

A linha do tempo, e onde as correções foram aplicadas

AIR afirma ter encontrado a falha em maio de 2026 com exploits de prova de conceito funcionais contra todos os quatro agentes, e a divulgou a cada fornecedor no mês seguinte sob divulgação coordenada. A Anthropic confirmou sua correção no Claude Code {{1}}2.1.179{{/1}} em {{2}}17 June{{/2}}. O Google informou a AIR em {{3}}4 August{{/3}} que nenhuma correção seria lançada, porque o Gemini CLI está sendo descontinuado. O Codex {{4}}0.146.0{{/4}} foi verificado como corrigido em {{5}}12 August{{/5}}. A Microsoft não lançou uma correção para o GitHub Copilot.

As versões de patch são a única confirmação pública de que a falha era real nos dois produtos que a corrigiram. A entrada do changelog publicado pela Anthropic para a 2.1.179 lista tratamento de queda de conexão, rolagem no WSL2, correções de glob e interface do sandbox, e não menciona fixação de versões, verificação de plugins nem qualquer tipo de correção de segurança. O The Hacker News fez a mesma observação, segundo o relato do The Next Web. Na data de publicação da pesquisa, nenhum identificador CVE havia sido atribuído, e a nota de pesquisa da Cloud Security Alliance sobre a falha repete que nenhum identificador existia três meses após os fornecedores terem sido notificados.

Quatro fornecedores, três respostas diferentes

O Google foi além de se recusar a corrigir. Ele descontinuou o Gemini CLI, o que significa que as instalações existentes permanecem expostas enquanto as pessoas continuarem a executá-las. Sua recomendação é migrar para o Antigravity, o ambiente de desenvolvimento agêntico mais recente, que, segundo a AIR, o ataque não atinge porque não tem pinning de SHA de plugins do marketplace a ser contornado.

A posição do GitHub é novamente diferente. Um porta-voz do GitHub disse ao The Register que a plataforma não permite que usuários criem nomes de branch ou tag que se assemelhem a SHAs de commit, e que "essa mitigação garante que a vulnerabilidade relatada não possa ser explorada no GitHub". A AIR contesta o escopo dessa mitigação, e não sua existência: os pesquisadores disseram ao The Register que marketplaces podem ser hospedados em outras plataformas, como o Bitbucket, e que o GitHub Copilot ainda oferece suporte a marketplaces dessas plataformas, portanto a variante baseada em nome de branch continua acessível para usuários do Copilot. A AIR também afirma que a documentação da própria Anthropic lista o Bitbucket e o git auto-hospedado como backends válidos de marketplace; a documentação atual de marketplace da Anthropic descreve adicionar um marketplace a partir de uma URL de repositório git, não apenas do GitHub. A Microsoft não respondeu ao pedido de comentário do The Register, e a AIR disse que não recebeu resposta da Microsoft desde que relatou o problema em junho, citando o volume de divulgações que a empresa está processando.

Esta é uma discordância sobre a amplitude da exposição, não sobre se o bug existe. A mitigação do GitHub é uma restrição no nível do host; a constatação da AIR é que a verificação precisa acontecer dentro do agente, porque o pin é resolvido no cliente.

O que está estabelecido, e o que não está

• Estabelecido: o mecanismo. O texto da AIR traz os comandos git exatos, a regra de resolução ref-over-object, as duas condições de que o truque de branch precisa e a variante separada de FETCH_HEAD para o Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld e The Next Web noticiam isso da mesma forma.

• Estabelecido: duas versões corrigidas. A Anthropic confirmou o Claude Code 2.1.179 em 17 de junho de 2026, e o Codex 0.146.0 da OpenAI foi verificado como corrigido em 12 de agosto de 2026, conforme o cronograma de divulgação da AIR.

• Estabelecido: dois produtos não tinham correção no momento da divulgação. O Google não corrigirá o Gemini CLI e está descontinuando-o; a Microsoft ainda não lançou uma correção para o Copilot.

• Não estabelecido: reprodução independente. Todo relato publicado remonta à própria postagem no blog da AIR, e a nota de pesquisa da Cloud Security Alliance não descreve explicitamente uma validação técnica por terceiros nem uma reprodução independente do exploit. O arquivo classifica a confiança deste registro como B por esse motivo.

• Não estabelecido: quantas instalações foram realmente expostas. "Milhões" é a caracterização da AIR em sua manchete, não um número medido.

• Não estabelecido: se atualizar um agente afetado remove um plugin que já foi substituído, ou apenas impede a próxima substituição. Nenhuma fonte publicada resolve isso.

• Não comprovado: qualquer uso no mundo real. Nenhuma fonte no registro relata exploração, sondagem ou infraestrutura de atacante, e o arquivo registra dano real como falso. Isso é ausência de relatos, não evidência de que nada aconteceu.

Uma verificação de terceiros de fato estreita o quadro prático. O The Next Web, resumindo verificações do The Hacker News, relata que plugins no catálogo comunitário da Anthropic e nos catálogos padrão do Claude Code e do Copilot apontam para repositórios do GitHub, e que a atualização automática vem ativada por padrão principalmente nesses marketplaces integrados. Como o GitHub recusa nomes de branch em formato de SHA, a variante de nome de branch é mais difícil de alcançar para usuários que permanecem nos catálogos padrão. Esse raciocínio não abrange a variante FETCH_HEAD do Gemini CLI, que não depende de como o host nomeia as branches.

Como deve ser uma correção

A correção recomendada pela AIR é uma única asserção: após o checkout, resolver o commit realmente presente na árvore de trabalho e abortar a menos que ele seja igual ao SHA fixado. Os pesquisadores enfatizam que ela precisa verificar o HEAD resolvido, e não a ref solicitada, porque é exatamente essa distinção que a variante do Gemini CLI deixa passar, e que ela precisa ser executada dentro do agente, porque o pin é resolvido no cliente e nenhum marketplace consegue impor a garantia que anuncia.

Conselhos práticos para equipes que executam esses agentes, extraídos da AIR, Cybersecurity News e dos comentários de analistas na InfoWorld:

• Atualize o Claude Code para 2.1.179 ou posterior e o Codex para 0.146.0 ou posterior. A atualização é a única mitigação completa onde existe uma correção.

• Desative as atualizações automáticas de plugins em qualquer agente que não tenha patch. Isso reduz a falha de zero-click para uma reinstalação manual, o que representa uma redução da exposição, e não uma correção.

• Migre do Gemini CLI em vez de esperar por uma correção que o Google afirmou que não virá.

• Audite o inventário de plugins e restrinja as fontes de marketplace sempre que possível. O AIR observa que um marketplace pode atenuar a variante de nome de branch ao permitir apenas hosts que rejeitam nomes em formato SHA — na prática, somente GitHub —, mas que isso baniria hosts com suporte oficial dos agentes e não faria nada pela variante Gemini.

• Trate a estação de trabalho como o limite de exposição. Os plugins herdam as permissões do agente, portanto, uma exploração bem-sucedida alcança código-fonte, chaves SSH, credenciais de nuvem, tokens de CI/CD e repositórios internos com a própria autoridade do desenvolvedor. Pareekh Jain, analista principal da Pareekh Consulting, disse ao InfoWorld que as equipes de segurança devem examinar logs de EDR, git, CI/CD, IAM de nuvem e autenticação em busca de processos incomuns, arquivos de plugin inesperados, repositórios alterados e atividade suspeita no git — e acrescentou que essas medidas reduzem o risco sem corrigir a falha subjacente, que ele atribui ao código do fornecedor. "As empresas podem impor controles ao uso de plugins", disse ele ao InfoWorld, "mas não conseguem corrigir uma falha na forma como o agente de codificação valida o código que faz checkout."

Por que um bug de fixação foi o que realmente importou

O SHA pinning foi a resposta da indústria exatamente ao tipo de tomada de controle que o AIR já havia demonstrado: se um repositório público for comprometido, o agente continua executando o hash auditado em vez de baixar o que quer que o atacante tenha enviado. O Plugin4Shell não quebra o hash. Ele mostra que os agentes resolveram a fixação para um nome de branch que apenas se parecia com o hash, e nunca compararam o resultado. Tudo o que está a jusante dessa suposição — processos de revisão, listas de permissões internas, a confiança que os desenvolvedores depositam em uma versão fixada — herda a falha.

O que o registro não sustenta é a alegação de que algo tenha sido levado. Esta é uma vulnerabilidade que foi encontrada e, em dois de quatro casos, corrigida; nenhuma fonte nele relata uma intrusão, e os produtos que não lançaram um patch ainda aguardam. A questão em aberto é a menos satisfatória: para qualquer pessoa que executou um plugin em um agente não corrigido, não há uma forma publicada de saber se o código executado era o código que ela aprovou.