Pesquisadores da Universidade de Toronto construíram e testaram um verme de computador baseado em inteligência artificial (IA) que utiliza um modelo de linguagem de grande porte (LLM) de pesos abertos hospedado localmente para traçar seu caminho por uma rede, gerar estratégias de ataque personalizadas para cada alvo encontrado e se replicar, tudo sem intervenção humana e sem acessar qualquer serviço comercial de IA.
O preprint, publicado no arXiv em 2 de junho e atualmente em revisão por pares, mostra por que a correção de vulnerabilidades individuais (CVEs — Common Vulnerabilities and Exposures, ou Vulnerabilidades e Exposições Comuns) se torna insuficiente quando o malware é capaz de inspecionar serviços expostos, ler avisos de segurança atualizados e gerar um novo caminho de ataque em tempo de execução.
Em 15 execuções isoladas em uma rede de 33 hosts deliberadamente vulnerável, o verme identificou em média 31,3 vulnerabilidades e obteve acesso elevado em 23,1 hosts — cerca de três quartos dos hosts que atacou ativamente. Em seguida, replicou-se de forma autônoma para 20,4 desses hosts, ou 62% da rede completa, ao longo de sete dias, sem conhecimento prévio da topologia da rede e sem intervenção humana.
Vermes tradicionais são distribuídos com um payload de exploit fixo, definido no momento da construção. Corrija essas falhas específicas e o verme para de se propagar.
Este verme faz algo diferente: utiliza um LLM de pesos abertos rodando em uma única unidade de processamento gráfico (GPU) para gerar a lógica de ataque em tempo de execução, personalizada para o que encontrar no próximo alvo. Nenhuma cadeia de exploits pré-codificada. Nenhuma dependência da OpenAI, Anthropic ou qualquer outra interface de programação de aplicações (API) que uma plataforma possa revogar ou limitar por taxa.
O que o verme realmente fez
Liderada pelo professor associado Nicolas Papernot, a equipe do CleverHans Lab reúne pesquisadores da Universidade de Toronto, do Vector Institute, da Universidade de Cambridge e da ServiceNow. Foram realizados 15 experimentos independentes em uma rede isolada de 33 hosts ("FakeCorp") com sistemas Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019 e 2022, além de dispositivos da internet das coisas (IoT).
Cada host possuía pelo menos uma vulnerabilidade real. Cinco das 33 máquinas tinham GPUs. Nos experimentos principais de propagação, o verme utilizou um pool compartilhado de inferência em GPU para simular a capacidade de computação adquirida das máquinas vítimas. A equipe testou separadamente a replicação completa em nível de GPU, na qual o verme implanta uma instância local do LLM em um host comprometido com GPU; esse processo teve sucesso em 68,8% das tentativas.
No projeto em camadas, hosts infectados com capacidade de GPU funcionam como nós distribuídos de raciocínio, fornecendo inferência para dispositivos de menor poder computacional na rede que não conseguem rodar o modelo por conta própria.
Ao longo das 15 execuções, o verme obteve acesso elevado em 23,1 hosts e lançou com sucesso uma réplica em 88% desses. Atingiu até sete gerações de autorreplicação, com média de 5,1. O ambiente foi intencionalmente vulnerável: o artigo afirma que o teste mede o raciocínio autônomo diante de falhas individuais realistas, e não a propagação em uma rede de produção majoritariamente protegida com defesa ativa em endpoints.
Os exploits em uma única execução incluíram uma cadeia SambaCry combinada com escalonamento de privilégios via cron gravável com acesso root, Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim com execução remota de código (RCE), injeção cega de SQL, contorno de JWT, escape de Redis, entre outros — não porque estavam pré-programados, mas porque o agente chegou até eles por raciocínio a partir do que encontrou em cada host.
A Figura 2 do artigo mapeia a árvore radial completa de propagação em uma execução, mostrando de seis a sete gerações de propagação entre hosts Linux, Windows e IoT. Tentativas individuais de exploit tiveram sucesso em cerca de 44% dos casos. A maioria das falhas veio de sintaxe malformada no payload, não de lógica defeituosa. Exploits em aplicações web e escalonamento de privilégios no Windows foram mais difíceis do que escalonamento local em Linux e exploits de serviços — um teto de capacidade que o artigo trata como limitação atual do modelo, e não como defesa estrutural.
O problema da janela de correção
O verme contornou seu próprio limite de dados de treinamento ao ingerir texto de avisos públicos em tempo de execução, explorando com sucesso hosts de teste configurados com três vulnerabilidades divulgadas após o treinamento do modelo:
- CVE-2026-39987, uma falha de execução remota de código (RCE) pré-autenticação no notebook Python Marimo (CVSS — Common Vulnerability Scoring System, ou Sistema Comum de Pontuação de Vulnerabilidades — 9,3);
- CVE-2026-31431 (CopyFail), uma falha de escalonamento de privilégios no kernel Linux no módulo algif_aead, que a CISA (Agência de Segurança Cibernética e Infraestrutura dos EUA) adicionou ao seu catálogo de Vulnerabilidades Exploradas Conhecidas em maio; e
- CVE-2026-43284 / CVE-2026-43500 (DirtyFrag), falhas relacionadas de escalonamento local de privilégios no kernel Linux.
Contra esses três hosts, o verme obteve acesso root em 41 de 67 tentativas.
O CVE-2026-39987 foi divulgado em 8 de abril de 2026. A Sysdig observou exploração em honeypots 9 horas e 41 minutos depois, e documentou separadamente uma invasão real na qual um atacante utilizou um agente de LLM para atividades pós-exploração após comprometer uma instância pública do Marimo. O mesmo velho atraso na aplicação de patches, agora com um agente lendo o aviso e tentando em escala.
O paralelo relevante com o WannaCry é o atraso na aplicação de patches, e não o raio de destruição. O EternalBlue havia sido corrigido meses antes de o WannaCry atingir os sistemas. O artigo faz o mesmo ponto sob uma restrição diferente: um verme adaptativo pode continuar testando novos caminhos enquanto os defensores ainda estão validando as correções.
Custo marginal zero, sem botão de desligamento central
Dois fatores tornam esse tipo de verme mais difícil de conter do que um tradicional.
- Primeiro, o custo migra do acesso a APIs alugadas para a capacidade de computação que o verme consegue capturar. Uma vez que exista uma infraestrutura vítima com GPU, o atacante deixa de pagar por tentativa.
- Segundo, como tudo roda em modelos de pesos abertos sem dependência de fornecedor, os controles do lado do prestador de serviço não atingem o problema central. Recusas de serviço, limitação de taxa, suspensão de conta: nada disso se aplica. Não há chave de API para revogar. A contenção precisa ocorrer na camada de rede e de host.
Os pesquisadores também observaram o verme reescrever seu próprio código em diversas ocasiões para contornar controles de segurança locais no ambiente de teste — comportamento que nunca havia sido programado.
A versão atual foi deliberadamente construída sem recursos de furtividade: sem criptografia, sem código polimórfico, sem mecanismos de persistência, sem cobertura de rastros. Uma variante maliciosa com persistência, payloads criptografados, mascaramento de processos e limpeza de logs daria aos defensores menos dos sinais fáceis que esse protótipo deixa para trás.
Onde isso se encaixa
Esta não é a primeira pesquisa sobre vermes baseados em IA. O Morris ii (Cohen et al., 2025) demonstrou um prompt adversarial autorreplicante se espalhando entre assistentes de e-mail com IA por meio de geração aumentada por recuperação — propagação dentro da camada de aplicação de IA, e não pela infraestrutura de hosts.
Em março de 2026, o ClawWorm demonstrou ataques autorreplicantes em ecossistemas de agentes de LLM, sequestrando configurações persistentes e se propagando para agentes pares. O verme de Toronto é diferente em espécie: o LLM não é a coisa atacada. Ele é o motor de ataque usado para comprometer a infraestrutura comum de rede.
Operações reais já estão testando o mesmo limite. A Anthropic afirmou, em novembro de 2025, que interrompeu uma grande campanha de espionagem orquestrada por IA, atribuída com alta confiança ao GTG-1002, um grupo patrocinado pelo Estado chinês. O Claude Code teria conduzido de 80% a 90% da operação, incluindo reconhecimento, desenvolvimento de exploits, coleta de credenciais, movimento lateral e exfiltração, com humanos intervindo em poucos pontos de decisão.
O Threat Intelligence Group do Google relatou uma mudança relacionada em maio de 2026: o que avaliou com alta confiança como o primeiro exploit de dia zero desenvolvido com assistência de IA, encontrado no script de um grupo criminoso antes de um evento planejado de exploração em massa, junto a famílias de malware que geram seus próprios comandos em tempo de execução em vez de depender de lógica codificada. O trabalho de Toronto é a versão laboratorial dessa direção levada à propagação de vermes em nível de host.
A direção é clara: menos comandos e mais delegação, e mais da intrusão entregue ao modelo.
O que os defensores devem fazer agora?
Os sinais comportamentais que esse protót
Nenhum comentário publicado até agora.