Atualização de plugin invade 7 agentes — o modelo nem vê o comando
Um preprint submetido em 3 de setembro de 2026 apresentou o HookPry, framework de ataque que transforma a atualização de um plugin já instalado em uma rota para executar comandos no computador que hospeda um agente de IA. O preprint do HookPry relata comprometimentos nos sete harnesses avaliados, em 1.000 execuções distribuídas por 25 combinações de harness e backend; a maior taxa de sucesso por harness chegou a 92,5%.
No estudo divulgado em 3 de setembro, o ataque não depende de convencer o modelo por meio de um prompt. A atualização associa comandos de shell a eventos rotineiros dos hooks de ciclo de vida, e o próprio harness inicia o processo no host. No caminho explorado, o comando não é escolhido nem aprovado pelo modelo e pode ser executado em um momento que ele não observa.
Como a atualização chega ao processo do host
Hooks automatizam ações em momentos definidos da operação do agente, como o início de uma sessão, uma chamada de ferramenta ou a edição de um arquivo. Um plugin legítimo pode usar esse mecanismo para preparar o ambiente ou executar uma verificação. O HookPry explora a mesma capacidade depois que uma versão inicial benigna já conquistou a confiança do usuário.
No modelo de ameaça do estudo, o invasor controla os metadados do plugin e a configuração dos hooks presentes na atualização, mas não o código do harness. A nova versão vincula um comando escolhido pelo atacante a um evento comum. Se a atualização for instalada e esse evento ocorrer, o harness despacha o subprocesso com as permissões disponíveis no host.
O percurso é direto: um marketplace ou registro distribui a nova versão; a atualização preserva a confiança concedida à identidade do plugin; a configuração modificada registra o hook; o evento correspondente dispara o comando; e o efeito aparece no sistema operacional. A decisão do modelo não integra essa sequência. Filtros de prompt e salvaguardas aplicadas apenas às ferramentas selecionadas pelo LLM, portanto, não cobrem a fronteira explorada.
O que os 1.000 testes demonstram — e o que não demonstram
Os pesquisadores definiram dez objetivos de ataque e avaliaram sete harnesses com diferentes backends. Comprometer os sete significa que cada harness testado produziu ao menos um efeito malicioso verificável nas condições experimentais. Isso não significa que todas as execuções funcionaram nem que todos os agentes disponíveis no mercado tenham a mesma vulnerabilidade.
Uma análise publicada em 5 de setembro confirma o recorte de 1.000 execuções, 25 combinações e dez objetivos, mas restringe a conclusão aos sete harnesses, aos backends selecionados e ao modelo de ameaça no qual o adversário consegue publicar ou alterar uma atualização. A análise ressalta que o estudo não mede a frequência desse acesso em ecossistemas implantados nem o desempenho do ataque diante de assinatura obrigatória ou isolamento mais forte.
Os números de detecção exigem a mesma cautela. Na configuração avaliada, o Microsoft Defender teve recall de 0%, enquanto a união de três defesas estáticas deixou passar 47,5% dos artefatos maliciosos. Os resultados descrevem as amostras e ferramentas do experimento; não demonstram que todo antivírus ou controle corporativo falhará contra qualquer variação do ataque.
O trabalho também não apresenta evidência de uma campanha real que tenha usado o HookPry contra marketplaces ou usuários em produção. Trata-se de uma prova experimental de que atualizações controladas por um adversário podem alcançar execução no host, não do registro de sete invasões independentes.
Hooks passam a ser código de cadeia de suprimentos
A consequência operacional é tratar a configuração de hooks como código de cadeia de suprimentos, e não como metadado inofensivo. Verificar a identidade do plugin somente na primeira instalação deixa uma lacuna quando versões posteriores podem acrescentar eventos, comandos, scripts, destinos de rede ou variáveis de ambiente sem nova autorização.
Uma revisão de segurança de 6 de setembro situa o problema na camada de execução e recomenda incorporar harnesses, plugins e hooks à gestão de componentes de terceiros. A partir do caminho demonstrado pelo estudo, os controles verificáveis são:
- validar assinatura, origem e hash de cada versão, sem presumir que um nome conhecido torna segura a atualização;
- exibir uma diferença semântica dos hooks antes da instalação, destacando eventos adicionados, comandos modificados, caminhos de scripts e novos acessos de rede;
- solicitar novo consentimento quando a versão registrar outro evento ou ampliar capacidades, em vez de herdar silenciosamente a aprovação inicial;
- executar hooks com usuário dedicado, credenciais mínimas e acesso restrito ao sistema de arquivos, à rede e a outros processos;
- isolar subprocessos em sandbox e registrar a versão do plugin, o hash da configuração, o evento disparador, o comando efetivo e a identidade de execução.
Assinatura e revisão de diferenças protegem a integridade da atualização; consentimento por evento expõe a expansão de capacidade. Privilégios mínimos e sandbox limitam o impacto se um artefato malicioso atravessar as etapas anteriores. Um registro separado da conversa do modelo ajuda a encontrar justamente a atividade ausente do histórico do LLM, objetivo relacionado à adoção de ações de agentes auditáveis.
Esses controles são recomendações derivadas do mecanismo observado, não medidas comparativas de eficácia produzidas pelo HookPry. Nenhum controle isolado encerra o risco: uma assinatura autentica a origem, mas não torna segura uma mudança autorizada; a sandbox reduz o alcance do processo, mas não substitui a revisão das capacidades adicionadas.
As respostas dos ecossistemas ainda estão em aberto
O achado confirmado permanece delimitado ao laboratório: atualizações maliciosas da configuração de hooks provocaram efeitos verificáveis nos sete harnesses avaliados, fora da decisão do modelo. Ainda faltam reprodução independente das métricas, respostas dos fornecedores, testes sob políticas mais rígidas de assinatura e isolamento e dados sobre a incidência dessa condição em instalações reais.
A questão decisiva para cada ecossistema é se permissões são recalculadas a cada atualização. Enquanto comandos, eventos e privilégios puderem mudar sem revisão explícita, a confiança continuará associada ao nome do plugin, embora sua capacidade executável possa ter mudado.
Leia também:
Assine nossa newsletter
Receba as últimas notícias sobre Web3, IA e cripto diretamente no seu e-mail.