Supply chain no npm: pacotes AsyncAPI com 2 milhões de downloads semanais tomados por malware híbrido de 91 mil linhas

Pesquisadores da OX Security revelaram em 14 de julho que quatro pacotes npm da organização AsyncAPI foram comprometidos e receberam código malicioso: @asyncapi/generator 3.3.1, @asyncapi/generator-components 0.7.1, @asyncapi/generator-helpers 1.1.1 e @asyncapi/specs 6.11.2 (mais o alpha.1). Juntos, esses pacotes somam mais de 2 milhões de downloads semanais e alimentam ferramentas usadas por equipes que constroem APIs orientadas a eventos em todo o mundo. O payload injetado ultrapassa 91 mil linhas de código e combina infostealer, cripto-stealer e RAT com múltiplos canais de C2 baseados em IPFS e BitTorrent.

O que aconteceu

A AsyncAPI é uma das especificações mais adotadas para descrever APIs event-driven — o equivalente ao OpenAPI para arquiteturas assíncronas baseadas em Kafka, MQTT, AMQP e afins. O generator é usado para produzir código, documentação e stubs a partir da especificação, o que significa que ele roda dentro de pipelines de CI/CD, em máquinas de desenvolvedores e, em muitos casos, em processos de build automatizados que possuem acesso a segredos.

O atacante conseguiu comprometer a organização npm da AsyncAPI — o vetor exato ainda não foi divulgado, mas casos anteriores como Shai-Hulud e Miasma sugerem tokens de mantenedor roubados ou takeover de conta. Uma vez com acesso, publicou versões maliciosas com o payload embutido diretamente no arquivo JavaScript principal de cada pacote, tornando-o indistinguível do código legítimo até o momento em que é importado por um projeto.

É importante notar que a versão 12 do npm, lançada para justamente barrar execução automática via post-install scripts, não impediu o ataque. Os atacantes simplesmente colocaram o código no ponto de importação, contornando o controle sem precisar dele.

Como o ataque funciona

A arquitetura do malware é notavelmente sofisticada. O C2 primário aponta para 85.137.53.71, mas o payload usa IPFS (ipfs.io) como armazenamento redundante e como C2 de fallback, o que dificulta bloqueio via listas de reputação tradicionais. Além do IPFS, o código estabelece contato com nós bootstrap do BitTorrent — router.bittorrent.com, router.utorrent.com e dht.transmissionbt.com — para manter comunicação mesmo sob bloqueio de rede.

“Este é um ataque de supply chain multi-estágio altamente sofisticado. O malware funciona como um híbrido de info-stealer, cripto-stealer e Remote Access Trojan (RAT). Ele ativamente tenta confundir analistas ao imitar campanhas conhecidas como Miasma, e tem como alvo desenvolvedores e mantenedores de repositórios.”

Relatório da OX Security

Duas capacidades merecem destaque especial. A primeira é a auto-propagação: se o malware encontra tokens válidos para npm, PyPI ou Cargo na máquina infectada, tenta publicar-se automaticamente em pacotes que a vítima mantém nessas plataformas. Um único mantenedor comprometido vira um novo vetor de distribuição — o mesmo mecanismo que fez Shai-Hulud contaminar mais de 500 pacotes em setembro de 2025.

A segunda é a evasão inteligente: o malware verifica se está rodando em máquina virtual, se há EDR ativo e se o locale do sistema é russo. Se qualquer dessas condições for verdadeira, encerra silenciosamente. É prática comum de operadores que querem evitar sandboxes e não infectar máquinas em sua própria jurisdição — um forte indicador do provável ponto de origem do grupo.

Quem é afetado

• Times que usam AsyncAPI Generator em pipelines de build para gerar documentação, código-cliente ou stubs
• Desenvolvedores que instalaram qualquer das versões afetadas entre 8 e 14 de julho de 2026 em máquinas de trabalho
• Máquinas de CI/CD (GitHub Actions, GitLab Runners, Jenkins) que executaram npm install com os pacotes comprometidos
• Todos os projetos npm, PyPI e Cargo mantidos pelos desenvolvedores infectados — vetor de propagação secundária
• Ambientes que armazenam segredos como NPM_TOKEN, PYPI_TOKEN, CARGO_TOKEN ou GITHUB_TOKEN em variáveis de ambiente acessíveis pelo processo Node

Análise

O ataque à AsyncAPI é, junto com Shai-Hulud (2025) e Miasma (2025), a terceira grande campanha de supply chain em npm em menos de doze meses. O padrão está claro: atacantes já não perseguem pacotes obscuros para experimentar cadeias de exploração; eles atacam pacotes com milhões de downloads semanais e usam a auto-propagação para transformar cada máquina infectada em ponto de distribuição.

A defesa embutida na v12 do npm — barrar post-install scripts — foi importante, mas o ataque à AsyncAPI mostra sua principal limitação: proteger apenas o momento de instalação ignora que o código malicioso executa quando é importado. E qualquer pacote sério é importado. Precisamos de mecanismos que operem também em runtime: capability-based imports (à la Deno permissions), sandboxing por default e sinais de reputação transparentes por versão publicada, não apenas por pacote.

As referências deliberadas ao Miasma dentro do código são particularmente instrutivas. Trata-se de misdirection consciente: o atacante quer que analistas gastem tempo perseguindo atribuição errada. Isso indica maturidade operacional — quem escreveu esse malware já pensou na fase de resposta a incidentes e está tentando manipulá-la. É uma característica que costumávamos ver apenas em operações de estado-nação; hoje aparece em campanhas de crime organizado com foco financeiro.

Recomendações práticas

• Auditar package-lock.json e lockfiles em busca das versões comprometidas: @asyncapi/generator 3.3.1, generator-components 0.7.1, generator-helpers 1.1.1 e specs 6.11.2 (e 6.11.2-alpha.1)
• Se as versões forem encontradas: revogar imediatamente todos os tokens de desenvolvedor para npm, PyPI e Cargo em qualquer máquina que possa ter executado esses pacotes
• Rotacionar segredos armazenados em variáveis de ambiente durante o período de exposição (~8 a 14 de julho de 2026)
• Auditar releases e commits em registries próprios em busca de publicações não autorizadas feitas com credenciais comprometidas
• Monitorar conexões de saída de rede a partir de máquinas de desenvolvimento em busca de tráfego para nós bootstrap do BitTorrent (router.bittorrent.com, router.utorrent.com, dht.transmissionbt.com) e gateways IPFS — tráfego pouco comum em builds legítimos
• Bloquear ou alertar o IP 85.137.53.71 nos firewalls de saída de estações de desenvolvimento e runners de CI
• Adotar ferramentas de análise de comportamento como Snyk, Socket.dev ou Phylum, que detectam anomalias em pacotes recém-publicados antes da adoção

Fonte: Security Affairs