O teu agente de código fixou o commit. Nunca verificou onde tinha aterrado

Uma fixação que pedia mas não verificavaHover to explore

Há um tipo de descoberta de segurança que vale mais do que a sua pontuação de severidade, porque o mecanismo ensina algo aplicável noutros sítios. Esta é uma dessas.

Os detalhes vêm da cobertura da divulgação da AIR pelo The Register, pelo Help Net Security e pelo Cyber Security News. O estado das correções e as posições dos fabricantes são os reportados na altura da divulgação e podem ter mudado; a secção 7 diz o que não estou a afirmar. A leitura do mecanismo, e tudo o que vem a partir da secção 4, é minha.

1. O que foi divulgado

A 17 de setembro de 2026, os investigadores da AIR publicaram o Plugin4Shell: uma falha de execução remota de código sem um único clique nos sistemas de plugins de quatro grandes agentes de código de IA. Encontraram-na em maio de 2026, construíram exploits de demonstração funcionais contra os quatro, e comunicaram-na aos fabricantes em junho.

Estado tal como reportado à data da publicação:

É essa última parte que fala. Quando quatro concorrentes lançam o mesmo defeito, não são quatro distrações. É um pressuposto partilhado que ninguém chegou a escrever.

2. O mecanismo: uma fixação que pede mas não verifica

Os marketplaces de plugins fixam um plugin a um hash de commit específico depois de o reverem. É este o controlo em que toda a gente confia: fixas um SHA e recebes exatamente os bytes que alguém olhou. É o mesmo instinto que está por trás de um lockfile.

Eis o que os agentes afetados faziam na verdade:

1. O marketplace fixa o plugin a um hash de commit revisto de 40 caracteres.

   Até aqui tudo bem. Esta parte funciona.

2. O agente pede ao Git para fazer checkout desse hash.

   Também correto, tomado isoladamente.

3. Um atacante que controla o repositório do plugin publica um ramo cujo nome é essa mesma cadeia de 40 caracteres.

   Nada te impede de chamar a um ramo a94a8fe5ccb19ba61c4c0873d391e987982fbbd3. É só uma cadeia de caracteres.

4. O Git resolve o nome da referência antes de tratar a cadeia como identificador de objeto, por isso o checkout aterra no ramo do atacante — e o agente dá o SHA fixado por satisfeito.

   Porque nunca olhou. Como o formulam os investigadores: o agente faz checkout do commit exato que o marketplace fixou, mas nunca verifica se aterrou lá.

A variante do Gemini CLI é outro caminho para o mesmo sítio — um ramo chamado FETCH_HEAD que desvia o checkout do commit descarregado — e é esse detalhe que faz disto uma classe de defeitos e não o deslize de um fabricante.

3. A atualização automática é o que a tornou sem clique

Uma falha de cadeia de fornecimento normalmente exige algo do utilizador: instalar, atualizar, aprovar um aviso. O Plugin4Shell não exigia nada disso, e a razão é uma funcionalidade de que toda a gente gosta.

O Claude Code e o Codex correm atualizações automáticas em segundo plano por omissão. Quando um marketplace muda um SHA fixado, o agente volta a correr o checkout no seu próprio horário. Se o atacante já deixou o ramo malicioso preparado, a troca acontece em silêncio, sem aviso, sem instalação e sem ninguém presente.

O que inverte o conselho habitual:

Para dependências correntes, «liga as atualizações automáticas» é boa orientação de segurança, porque quase tudo o que a atualização automática entrega são correções. Para uma superfície de execução em que o próprio caminho de atualização é o componente vulnerável, atualizar automaticamente é o mecanismo de entrega. Os dois casos parecem idênticos numa página de políticas e comportam-se em sentidos opostos.

4. O raio de impacto é o teu programador, não um ambiente isolado

É tentador ler «vulnerabilidade de plugin» como um problema contido. Não é, e esta é a parte que deve decidir com que seriedade uma equipa pequena a leva.

O código executado através do sistema de plugins de um agente de código obtém, na formulação dos investigadores, o mesmo alcance sobre os sistemas e os dados da empresa que o colaborador que corre o agente. Num posto de trabalho normal, isso significa:

Um posto de trabalho de programação é a máquina menos segmentada da maioria das empresas e a que tem mais alcance. Isso é aceitável enquanto o código que lá corre for código que uma pessoa escolheu. É outra coisa quando um caminho de atualização pode mudar o que executa sem que ninguém tenha decidido mudá-lo.

5. A árvore de dependências que ninguém inventaria

Aqui está o ponto estrutural, e a razão pela qual acho que isto importa para além de um ciclo de correções.

As dependências da tua aplicação estão governadas. Há um lockfile, um scanner, um passo de revisão quando alguém acrescenta um pacote, e um SBOM se vendes a alguém que o peça. Essa maquinaria levou vinte anos ao setor e em geral funciona.

Os plugins, skills, extensões e instalações de marketplace do teu agente não têm nada disso.

As dependências de aplicação costumam correr dentro de um serviço com uma identidade limitada. Os plugins de agente correm num posto de trabalho com toda a autoridade de uma pessoa. A camada com menos revisão é a que tem mais alcance, o que está exatamente ao contrário, e aconteceu por acidente: os plugins chegaram como funcionalidade de produtividade, não como cadeia de fornecimento de software, por isso ninguém lhes ligou a maquinaria correspondente.

A maioria das equipas com quem falo não consegue responder a «que plugins de agente estão instalados na equipa, em que versões, de que autores» sem andar de secretária em secretária. Isso não é negligência. Ninguém lhes disse que era uma pergunta.

6. O que fazer esta semana

Quatro coisas, cerca de uma tarde, e nenhuma exige uma equipa de segurança.

1. Atualiza os agentes e depois confirma que as versões entraram mesmo.

   Claude Code 2.1.179 e Codex 0.146.0 ou posteriores. Para tudo o que esteja reportado sem correção ou descontinuado, a decisão é se mantém sequer superfície de plugins: um caminho de atualização por corrigir não se monitoriza, desliga-se.

2. Faz o inventário.

   Cada plugin, skill e extensão de agente instalados na equipa, com autor e versão. Costuma ser uma lista curta e o exercício acaba numa hora. Se sair uma lista longa, é essa a descoberta.

3. Decide a política de atualização automática de forma deliberada, superfície a superfície.

   Atualiza automaticamente o binário do agente: é assim que recebes correções como estas. Pondera pôr uma pessoa a aprovar as atualizações de plugins, pelo menos os que conseguem executar código. São duas decisões distintas e hoje quase todas as equipas tomam só uma, por omissão, para ambas.

4. Reduz o que está autenticado no posto de trabalho.

   Credenciais de nuvem de vida curta, nenhum token de produção duradouro em perfis de shell, e nenhum túnel para base de dados aberto o dia inteiro. É o controlo que se aguenta seja qual for o agente que lance o próximo defeito, e é isso que o torna o primeiro a valer a pena.

E uma coisa a acrescentar ao teu próprio código, seja o que for que construas:

Procura cada sítio onde vais buscar por identificador — um commit, um digest, uma versão de modelo, um identificador de documento — e vê se alguma coisa volta a derivar esse identificador a partir do que chegou de facto. Se a resposta for «pedimos, logo há de ser aquilo», tens a forma do Plugin4Shell no teu próprio sistema. Fechar isso custa umas linhas e é invisível até ao dia em que deixa de ser.

7. O que não vou afirmar

Não foi reportada exploração confirmada no mundo real. Isto é uma divulgação com exploits de demonstração funcionais, não um relatório de incidente. Os valores que circulam sobre quantos agentes um plugin malicioso poderia alcançar são modelação de cenários, não contagens de instalações comprometidas, e deixei-os deliberadamente de fora.

O estado das correções mexia-se durante a divulgação e as fontes divergem. O Claude Code e o Codex são reportados de forma consistente como corrigidos nas versões acima. A cobertura sobre a exposição do Copilot não é consistente: uns relatos descrevem-no sem correção, outros como mitigado por controlos de plataforma. Consulta o aviso do teu próprio fabricante em vez desta tabela.

Isto não é uma vulnerabilidade do Git. O Git resolver uma referência ambígua por uma ordem documentada é o Git a funcionar conforme especificado. O defeito está nos agentes terem assumido que o resultado correspondia ao pedido. Culpar a ferramenta seria a lição errada e levar-te-ia a não corrigir nada.

Não reproduzi nada disto. Tudo o que está na secção 2 é a minha leitura de descrições publicadas do mecanismo, não uma verificação independente.

O resumo honesto

O interessante aqui não é quatro agentes de código terem tido um defeito. É qual o pressuposto que todos partilhavam: que nomear uma coisa com precisão é o mesmo que verificar que a recebeste.

Esse pressuposto está por todo o lado. Está em cada integração que confia num webhook por trazer o identificador certo, em cada cache que responde por chave sem validar o conteúdo, em cada pipeline que descarrega latest e se diz reprodutível. Fixar um hash parecia seguro porque um hash é específico — mas especificidade não é verificação, e a distância entre as duas é exatamente onde vive esta classe de defeitos.

Entretanto, a exposição prática é pouco vistosa e imediata: um caminho de código capaz de mudar o que executa na máquina de um programador sem que ninguém aprove a mudança, na máquina menos segmentada do edifício.

Atualiza os agentes hoje. Depois passa uma hora a descobrir que plugins a tua equipa tem instalados, porque neste momento essa é uma pergunta a que a maioria das equipas não sabe responder — e é a mesma pergunta que a primeira revisão de segurança séria de um cliente vai fazer.

Fontes: The Register, «AI coding agents' 0-click RCE flaw could hand attackers keys to the kingdom», 17 de setembro de 2026 — a cronologia da divulgação, as duas vias de ataque e as posições dos fabricantes. Help Net Security, «Zero-click RCE vulnerability hit four major AI coding agents», 18 de setembro de 2026 — a descoberta em maio de 2026, a comunicação em junho, as versões corrigidas 2.1.179 e 0.146.0, e a formulação dos privilégios herdados pelo código executado. Cyber Security News — o mecanismo do ramo de 40 caracteres e a variante FETCH_HEAD que afeta o Gemini CLI. A investigação é da AIR. A generalização da secção 2, o argumento sobre a atualização automática da secção 3, o argumento do inventário da secção 5 e todas as recomendações são meus. Para o incidente anterior de cadeia de fornecimento nesta mesma linha, vê a enxurrada de pacotes no RubyGems, e para o modelo de permissões que limita até onde chega um plugin comprometido, vê os sistemas de permissões de agentes.

Related Posts

Um registo dava chaves de publicação antes de verificar o email. Depois chegaram 2000 pacotes14 de setembro de 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

AI Agents Need Permission Systems, Not Better Prompts — A Founder’s GuideJuly 14, 2026