Pesquisadores da Universidade de Toronto construíram e testaram, em prova de conceito, um worm de computador com IA que usa um modelo de linguagem de grande porte open-weight hospedado localmente para raciocinar dentro de uma rede, gerar estratégias de ataque personalizadas para cada alvo encontrado e se replicar, tudo sem intervenção humana e sem recorrer a um serviço comercial de IA.
O pré-print, publicado no arXiv em 2 de junho e atualmente em revisão por pares, mostra por que a correção de um único CVE deixa de funcionar quando o malware consegue inspecionar serviços expostos, ler alertas recém-publicados e gerar um novo caminho de ataque em tempo de execução.
Em 15 execuções isoladas, em uma rede deliberadamente vulnerável com 33 hosts, o worm identificou em média 31,3 vulnerabilidades e obteve acesso elevado em 23,1 hosts, algo em torno de três quartos dos alvos que atacou ativamente.
Em seguida, conseguiu se replicar de forma autônoma em 20,4 desses hosts, ou 62% da rede inteira, ao longo de sete dias, sem conhecimento prévio da topologia da rede e sem qualquer entrada humana.
Worms tradicionais embarcam com um payload de exploit fixo, escolhido na fase de construção.
Corrigir esses bugs específicos e o worm para de se espalhar.
Este worm faz algo diferente: usa um LLM open-weight rodando em uma única GPU para gerar a lógica de ataque em tempo de execução, ajustada ao que encontra no próximo alvo.
Não há cadeia de exploit codificada de antemão.
Não há dependência de OpenAI, Anthropic ou de qualquer outra API que uma plataforma possa revogar ou limitar por taxa.
O que o worm realmente fez
Liderada pelo professor associado Nicolas Papernot, a equipe do CleverHans Lab reúne integrantes da Universidade de Toronto, do Vector Institute, da Universidade de Cambridge e da ServiceNow.
Eles realizaram 15 experimentos independentes em uma rede isolada de 33 hosts, chamada “FakeCorp”, com Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019 e 2022, além de dispositivos IoT.
Cada host tinha ao menos uma vulnerabilidade real do mundo.
Cinco das 33 máquinas tinham GPUs.
Nos experimentos principais de propagação, o worm usou um pool compartilhado de inferência em GPU para simular capacidade computacional obtida das máquinas das vítimas.
A equipe também testou separadamente a replicação completa em nível de GPU, na qual o worm prepara uma instância local do LLM em um host GPU comprometido, e isso funcionou em 68,8% das tentativas.
No desenho em camadas, hosts infectados com capacidade de GPU atuam como nós distribuídos de raciocínio, fornecendo inferência para dispositivos da rede com menos capacidade de processamento, que não conseguem executar o modelo sozinhos.
Ao longo das 15 execuções, o worm obteve acesso elevado em 23,1 hosts e lançou com sucesso uma réplica em 88% deles.
Ele chegou a até sete gerações de autorreplicação, com média de 5,1.
O ambiente foi propositalmente vulnerável.
Segundo o artigo, o teste mede raciocínio autônomo em falhas individuais realistas, e não disseminação em uma rede de produção em grande parte endurecida e sob defesa ativa de endpoint.
Entre os exploits usados em uma única execução estavam uma cadeia que combinava SambaCry e escalonamento de privilégio via root cron gravável, Dirty Pipe, PrintNightmare, Drupalgeddon 2, RCE no Exim, injeção SQL cega, bypass de JWT, fuga de Redis e outros.
Isso não ocorreu porque eles foram pré-programados, mas porque o agente raciocinou até chegar a eles com base no que encontrou em cada host.
A Figura 2 do artigo mapeia a árvore radial completa de propagação em uma execução, mostrando seis a sete gerações de disseminação entre hosts Linux, Windows e IoT.
As tentativas individuais de exploit tiveram sucesso em cerca de 44% dos casos.
A maior parte das falhas veio de sintaxe malformada do payload, e não de falhas lógicas.
Exploits em aplicações web e escalonamento de privilégio no Windows foram mais difíceis do que a escalada local em Linux e exploits de serviços, um limite 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 worm contornou o próprio corte de treinamento ao ingerir, em tempo de execução, textos públicos de alertas de segurança e conseguiu explorar hosts de teste configurados com três vulnerabilidades divulgadas depois de o modelo ser treinado:
-
CVE-2026-39987
, uma RCE pré-autenticação no notebook Python Marimo (CVSS 9,3);
-
CVE-2026-31431
(CopyFail), uma falha de escalonamento de privilégio no kernel Linux no módulo algif_aead, adicionada pela CISA ao catálogo de Known Exploited Vulnerabilities em maio;
-
CVE-2026-43284
/
CVE-2026-43500
(DirtyFrag), relacionadas a falhas locais de escalonamento de privilégio no kernel Linux.
Contra esses três hosts, o worm chegou a root em 41 de 67 tentativas.
A
CVE-2026-39987
foi divulgada em 8 de abril de 2026.
A Sysdig observou exploração em honeypots 9 horas e 41 minutos depois e, separadamente, documentou uma intrusão real em que um atacante usou um agente de LLM para atividades de pós-exploração após comprometer uma instância pública do Marimo.
É a mesma velha janela de correção, agora com um agente lendo o alerta e tentando explorá-lo em escala.
O paralelo relevante com o WannaCry é a janela de correção, não o tamanho do impacto.
O EternalBlue já estava corrigido havia meses quando o WannaCry se espalhou.
O artigo aponta a mesma lógica sob outra restrição: um worm adaptativo pode continuar testando novos caminhos enquanto os defensores ainda validam os consertos.
Custo marginal zero, sem botão central de desligamento
Dois fatores tornam isso mais difícil de conter do que um worm tradicional.
Primeiro, o custo sai do acesso pago a APIs e passa a depender do processamento que o worm conseguir capturar.
Quando existe uma infraestrutura de vítima com GPU, o atacante deixa de pagar por tentativa.
Segundo, como tudo roda em modelos open-weight sem dependência de fornecedor, controles do lado do provedor deixam de atingir o problema central.
Recusa do serviço, limitação por taxa, suspensão de conta, nada disso se aplica.
Não há chave de API para revogar.
A contenção precisa ocorrer na rede e no host.
Os pesquisadores também observaram o worm reescrever seu próprio código em várias ocasiões para contornar controles de segurança locais no ambiente de teste, comportamento que nunca foi programado explicitamente.
A versão atual foi construída de forma deliberadamente não furtiva: sem criptografia, sem código polimórfico, sem mecanismos de persistência e sem apagamento de rastros.
Uma variante maliciosa com persistência, payloads criptografados, disfarce de processos e limpeza de log daria aos defensores bem menos sinais óbvios do que este protótipo deixa.
Onde isso se encaixa
Este não é o primeiro estudo sobre worm com IA.
O Morris II, de Cohen e outros, em 2025, mostrou um prompt adversarial autorreplicante se espalhando entre assistentes de e-mail com IA por meio de geração aumentada por recuperação, ou seja, propagação na camada da aplicação de IA, e não na 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 pares de agentes.
O worm de Toronto é diferente em natureza: o LLM não é o alvo atacado.
Ele é o mecanismo de ataque usado para comprometer a infraestrutura de rede comum.
Operações reais já vêm testando esse mesmo limite.
A Anthropic disse, 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 chinês patrocinado pelo Estado.
O Claude Code conduziu 80% a 90% da operação, incluindo reconhecimento, desenvolvimento de exploit, coleta de credenciais, movimento lateral e exfiltração, com humanos entrando em poucos pontos de decisão.
O Google Threat Intelligence Group relatou uma mudança semelhante em maio de 2026: o que avaliou com alta confiança como o primeiro exploit de zero-day desenvolvido com ajuda de IA, encontrado em um script de um grupo criminoso antes de um evento planejado de exploração em massa, além de famílias de malware que geram seus próprios comandos em tempo de execução em vez de depender de lógica hardcoded.
O trabalho de Toronto é a versão de laboratório dessa direção, levada à propagação em nível de host.
A direção é clara: menos prompts, mais delegação, e mais da intrusão entregue ao modelo.
O que os defensores devem fazer agora?
Os sinais comportamentais produzidos por este protótipo dão aos defensores algo concreto para caçar, porque a versão atual não tenta se esconder.
- Segmente agressivamente as máquinas com capacidade de GPU.
O desenho do worm direciona a inferência do LLM por qualquer host GPU comprometido que consiga alcançar.
Em uma rede plana, um servidor de aprendizado profundo comprometido vira um centro de raciocínio para todo dispositivo infectado no mesmo subnet.
Segmente a infraestrutura de GPU e aplique controles de zero trust para impedir alcance lateral de e para esses hosts.
- Trate alertas públicos como alvos de weaponization em curto prazo.
Para CVEs expostas na internet, a janela de exploração já é medida em horas em alguns casos.
Verifique rapidamente a explorabilidade, corrija primeiro a exposição voltada à internet e use controles compensatórios quando a implantação não puder ocorrer antes do próximo ciclo operacional.
- Gire credenciais expostas em qualquer host comprometido ou com suspeita crível de comprometimento.
O worm demonstrou reutilização sistemática de credenciais como caminho de propagação.
Credenciais roubadas se movem lateralmente mais rápido do que a maioria dos ciclos de detecção.
- Monitore sinais comportamentais específicos de agentes.
Atividade não padronizada de portas, injeção automática de chave pública SSH e agrupamentos de inferência de LLM aparecendo em endpoints inesperados são artefatos observáveis deixados por este protótipo.
Eles são o ponto de partida para a lógica de detecção.
Nos testes, essa combinação levou a root em vulnerabilidades recém-expostas em 41 de 67 tentativas e à replicação em 62% da rede em sete dias, sem qualquer intervenção humana adicional.
Quando um ponto de apoio em GPU existe dentro de uma rede plana, o custo de mapear e explorar outros hosts cai para o processamento que o worm conseguir capturar, enquanto alertas públicos viram playbooks imediatos.
A implementação não foi divulgada publicamente.
A Universidade de Toronto está criando um processo de avaliação para que pesquisadores defensivos qualificados solicitem acesso.
Publicidade
Conheça a Solyd One, e tenha acesso a todos os cursos de segurança ofensiva da Solyd, todas as certificações práticas, incluindo a SYCP, 2 CTFs anuais com prêmios de até 30 mil reais, dezenas de laboratórios realísticos, suporte, comunidade e muito mais. Saiba mais...