Um catálogo pode indicar que uma extensão foi revista e associada a uma versão exata do código sem que o programa acabe por instalar essa versão. É esta a falha que a Air Security descreveu a 17 de setembro de 2026, sob o nome Plugin4Shell. Segundo os investigadores, o problema afetou mecanismos de instalação de extensões no Claude Code, no Codex, no GitHub Copilot e no Gemini CLI. Quando determinadas condições se verificam no repositório Git da extensão, o programa pode aceitar código diferente daquele que tinha sido aprovado.
Não se trata de um ataque que funcione indiscriminadamente em todas as instalações. É necessário que alguém controle ou comprometa o repositório de origem, que a plataforma de alojamento permita determinadas referências Git e que o cliente utilize uma versão vulnerável. Também não foi possível confirmar, nas fontes consultadas, um conjunto identificado de vítimas de uma campanha real com esta falha. A Aipolix não realizou um ensaio próprio. A informação disponível permite, contudo, esclarecer o mecanismo, distinguir os estados das correções e indicar verificações concretas para as equipas de desenvolvimento.
O código aprovado pode não ser o código instalado
Para impedir que o conteúdo de uma extensão mude depois da revisão, os catálogos registam habitualmente a identificação de uma alteração específica do repositório, o chamado hash de um commit. Quando instala a extensão, o agente descarrega o repositório e pede ao Git que selecione essa versão. A Air verificou que os instaladores em causa aceitavam o êxito da operação sem confirmar se o commit efetivamente selecionado correspondia à identificação registada.
No Claude Code, no Codex e no Copilot, a exploração descrita depende de uma ambiguidade entre o nome de um ramo e uma identificação hexadecimal de 40 caracteres. Um operador malicioso que controle o repositório pode criar um ramo com o mesmo nome do commit aprovado e torná-lo o ramo predefinido, desde que o serviço de alojamento aceite essa designação. O Git pode interpretar o identificador como o ramo e selecionar código diferente. Sem controlo sobre esse repositório e sem as condições de alojamento necessárias, não se pode presumir que este método funcione.
A distinção entre plataformas de alojamento muda a avaliação do risco. O GitHub informou que impede a criação de ramos ou etiquetas com nomes semelhantes a hashes de commits; por isso, essa variante não afeta repositórios alojados no próprio GitHub. O problema mantém relevância para origens externas, nomeadamente Bitbucket e servidores Git privados que admitam esses nomes. Ver uma extensão num catálogo alojado no GitHub não demonstra, por si só, que o seu código também esteja num repositório protegido por essa regra.
No Gemini CLI, os investigadores identificaram outro percurso: a versão pretendida é descarregada, mas a seleção final usa a referência FETCH_HEAD, cujo nome pode entrar em conflito com um ramo controlado pelo operador do repositório. Proibir ramos que parecem hashes não resolve necessariamente este segundo caso. A verificação decisiva consiste em comparar a identificação do commit que ficou efetivamente selecionado com a identificação previamente aprovada.
A atualização automática retira o último aviso ao utilizador
O cenário apresentado pela Air começa com uma extensão legítima, aprovada e instalada. Uma atualização aparentemente normal pode receber uma nova identificação no catálogo; posteriormente, o repositório é manipulado de forma a que o instalador obtenha outros ficheiros. Se o programa atualizar extensões em segundo plano, o utilizador não precisa de voltar a autorizar manualmente a instalação. Segundo os investigadores, as atualizações automáticas são a configuração predefinida do Claude Code e do Codex. Isso não autoriza a generalização a todas as configurações e a todos os clientes.
Quando executada, uma extensão maliciosa pode dispor dos mesmos acessos a ficheiros, credenciais ou serviços que o processo do agente recebeu. A descrição de execução remota de código refere-se a este resultado possível de uma exploração bem-sucedida; não é prova de que todas as organizações que utilizam os quatro produtos tenham sido comprometidas. A revisão do catálogo e a presença de um hash são úteis, mas não substituem a confirmação da integridade da instalação.
Daqui resulta uma separação importante para as auditorias: o catálogo responde pela versão que aprovou; o servidor Git pode impor regras de nomes para algumas referências; e o cliente tem de confirmar qual o código efetivamente colocado no computador. As permissões concedidas ao agente são uma quarta dimensão, pois determinam a extensão dos danos caso a instalação seja adulterada. Uma proteção numa destas etapas não demonstra que as restantes estejam garantidas.
Duas correções comunicadas; a situação dos outros clientes exige reservas
A Air atribui à Anthropic uma correção no Claude Code 2.1.179, comunicada aos investigadores em junho. As notas públicas dessa versão não identificam autonomamente Plugin4Shell, pelo que esta associação deve ser apresentada como informação dos autores da descoberta. No caso do Codex, existe confirmação técnica no próprio projeto: uma alteração aceite compara o commit real de HEAD com o hash solicitado e recusa a instalação se forem diferentes. Essa alteração está incluída nas notas da versão 0.146.0.
A 17 de setembro, os investigadores afirmaram que ainda não existia correção disponibilizada para o Copilot. O histórico público de versões do Copilot CLI consultado para esta notícia não permitiu confirmar uma correção posterior específica. Tal não equivale a conhecer todas as medidas internas da Microsoft. Numa declaração ao The Register, o GitHub destacou a proteção da sua plataforma contra nomes de ramos semelhantes a hashes, enquanto a Air salientou que as extensões podem vir de outros serviços.
Quanto ao Gemini CLI, a Air relata que a Google comunicou que não lançaria uma correção para esta falha e aconselhou a passagem para o Antigravity, que não usa o mesmo mecanismo vulnerável. Há, porém, uma ressalva documental: a Google publicou notas para a versão estável 0.60.0 do Gemini CLI, datada de 15 de setembro, incluindo outras melhorias de segurança. Isso impede concluir que todo o desenvolvimento tenha cessado ou que essas melhorias resolvam Plugin4Shell. Quem ainda utiliza o produto necessita de esclarecimento específico do fabricante sobre o comportamento de instalação de extensões.
Como verificar as extensões que já estão em produção
O primeiro passo é levantar as versões dos agentes, as extensões instaladas, os respetivos repositórios e os serviços que os alojam. Depois, comparar, através de procedimentos de inspeção fiáveis, o hash aprovado no catálogo com a identificação real do commit presente na instalação. Uma mensagem de instalação bem-sucedida não basta. Perante uma divergência, importa preservar os elementos necessários à investigação antes de executar novamente a extensão. Também devem ser revistos os mecanismos de atualização automática e o acesso dos agentes ao código, às credenciais e à rede.
Onde existe correção documentada, a atualização do cliente é necessária. Nas restantes situações, restringir repositórios de origem e suspender atualizações automáticas de extensões não confiáveis pode reduzir o risco, mas não equivale a corrigir o instalador. Tampouco se deve presumir que a atualização do agente elimina uma extensão já adulterada ou neutraliza credenciais eventualmente expostas: as fontes consultadas não demonstram esse efeito. Um indício de execução de código suspeito deve ser tratado de acordo com os acessos que esse código poderia ter utilizado.
O contributo técnico deste caso está na diferença entre quatro garantias frequentemente confundidas: revisão da extensão, identificação da versão, confirmação do conteúdo efetivamente instalado e contenção dos privilégios de execução. O nome Plugin4Shell descreve uma falha num ponto muito preciso dessa cadeia. Para uma equipa, demonstrar que cada etapa funciona vale mais do que declarar que o catálogo é fidedigno apenas porque apresenta uma versão imutável.