Plugin4Shell: quatro agentes de código com IA confiavam em um pin que nunca verificavam

Fixar um plugin em um commit específico por meio de seu hash SHA é uma das principais garantias de integridade em uma cadeia de suprimentos de software. Depois que esse código é revisado e aprovado, o pin deveria garantir que aquele código, e nenhum outro, seja executado.

O problema é que "fixado" e "validado" não são a mesma coisa. E uma pesquisa recente demonstrou exatamente isso em quatro dos agentes de código com IA mais utilizados do mercado.

O que a AIR Security descobriu

Pesquisadores da AIR Security identificaram uma falha no mecanismo de fixação de plugins por SHA: o agente verificava se o commit indicado pelo marketplace estava fixado, mas nunca confirmava se o checkout realmente havia chegado àquele commit.

Um atacante que controla o repositório de um plugin legítimo poderia explorar essa brecha para fazer com que o checkout resolvesse para um código malicioso enquanto o pin continuava parecendo válido. O resultado: execução remota de código zero-click no Claude Code, Codex, GitHub Copilot e Gemini CLI.

A mecânica varia de acordo com o agente. No Claude Code, Codex e GitHub Copilot, a exposição envolve uma branch com o mesmo nome do hash de 40 caracteres do commit fixado. Como o Git pode resolver o nome da branch antes do objeto de commit, um atacante pode criar uma branch com esse nome exato, defini-la como branch padrão e fazer com que o agente reporte uma instalação correta no hash esperado enquanto, na prática, executa outro código.

Essa variante também depende do host Git utilizado. O GitHub, por exemplo, restringe a criação de branches com nomes hexadecimais de 40 caracteres, enquanto outros hosts ou servidores Git podem permiti-las.

O Gemini CLI apresenta uma variante diferente, relacionada a uma ambiguidade na resolução de FETCH_HEAD.

Além disso, nos agentes em que plugins fixados podiam ser atualizados automaticamente, o ataque podia ser executado sem uma nova interação do usuário depois que as condições necessárias estivessem estabelecidas. Daí a classificação como zero-click.

Como cada fabricante respondeu

A AIR Security divulgou publicamente o Plugin4Shell em 17 de setembro de 2026, depois de descobrir a falha em maio daquele ano, desenvolver provas de conceito contra os quatro agentes e, posteriormente, notificar cada fabricante.

No momento da divulgação:

• Anthropic já havia corrigido o Claude Code na versão 2.1.179.
• OpenAI havia corrigido o problema no Codex 0.146.0.
• Microsoft ainda não havia lançado uma correção para o GitHub Copilot. No entanto, a exploração por meio de branches com nomes de 40 caracteres é restringida em repositórios hospedados diretamente no GitHub, embora o Copilot possa utilizar plugins provenientes de outros hosts.
• Google não planejava corrigir a versão afetada do Gemini CLI e direcionava os usuários para o Antigravity.

Ou seja, no momento em que a pesquisa se tornou pública, apenas dois dos quatro agentes contavam com uma correção disponível.

Por que isso importa além da correção

O que torna esse caso interessante não é apenas a lista de empresas envolvidas.

É o fato de que até mesmo uma organização que seguisse o modelo de segurança esperado poderia ficar exposta sob determinadas condições. Um usuário poderia estar utilizando um plugin revisado e fixado exatamente como o mecanismo de segurança previa, mas, se o repositório acabasse sob o controle de um atacante, esse pin não necessariamente garantiria que o código aprovado fosse o código realmente executado.

Fazer tudo certo nem sempre era suficiente.

O Plugin4Shell expõe uma diferença simples, mas importante: verificar se um controle de segurança existe não é o mesmo que verificar se ele funciona.

O marketplace podia revisar o código. Podia registrar um SHA. Podia exigir que o plugin fosse fixado. Todos esses controles podiam estar corretamente configurados e, ainda assim, o código executado no final podia ser outro.

O problema não estava na ausência de um controle de segurança. Estava em assumir que esse controle produzia o resultado esperado sem validá-lo.

E essa diferença importa muito além do Plugin4Shell.

Uma configuração pode estar correta. Uma política pode estar ativa. Um controle pode parecer devidamente implementado. Mas nada disso, por si só, demonstra o que acontece quando alguém realmente tenta quebrá-lo.

Encontrar um controle de segurança não é o mesmo que validar que ele funciona em condições reais de ataque.

Quantos dos seus controles de segurança estão configurados corretamente, mas nunca foram validados em condições reais de ataque?

Na Strike, acreditamos que a segurança não termina quando um controle está corretamente configurado. Ela começa quando você consegue comprovar que ele funciona como esperado diante de um ataque real.

Porque "configurado", "fixado" e "aprovado" descrevem uma intenção. Validado descreve um resultado.

‍