Pacotes NPM Infectados: Shai-Hulud Engoliu o Supply Chain

Pacotes npm infectados deixaram de ser um susto pontual em 2026 e viraram o pano de fundo permanente do desenvolvimento JavaScript. Em menos de doze meses, o worm autopropagável Shai-Hulud sequestrou contas de mantenedores, plantou backdoors em mais de 796 bibliotecas e atingiu projetos como TanStack, AntV, Axios, NX e até a infraestrutura interna da OpenAI. Se o seu package.json foi tocado neste ciclo, esse post mostra o que mudou, como detectar contaminação e como blindar o pipeline antes do próximo CVE.

TL;DR — o que você precisa saber sobre pacotes npm infectados em 2026

• Shai-Hulud é um worm autopropagável: rouba credenciais npm da máquina ou CI da vítima e publica versões maliciosas de tudo que aquele mantenedor controla, sem precisar de servidor C2.
• Em 2026 já aconteceram quatro ondas grandes: TanStack (11 maio), AntV (300+ versões, 19 maio), Axios (março) e o worm CanisterSprawl, que usa IA para variar payloads.
• O alvo principal são tokens de cloud (AWS/GCP), chaves de assinatura macOS, segredos de CI/CD e chaves de API de IA (OpenAI, Anthropic, Mistral).
• A defesa não é "atualizar tudo cego" — é congelar versões, auditar scripts de lifecycle e desativar postinstall arbitrário.
• Times brasileiros que rodam IA em produção estão na linha de frente porque seus CI runners executam npm install com privilégios e tokens vivos no ambiente.

O que aconteceu com os pacotes npm infectados em 2026

A timeline dos pacotes npm infectados nos últimos seis meses lê como prontuário de UTI:

• Novembro de 2025 — surge o Shai-Hulud original, primeiro worm npm a se autorreplicar lendo o próprio código fonte do payload.
• 24 de novembro de 2025 — Shai-Hulud 2.0 acelera a propagação e adiciona execução em preinstall, fugindo de auditorias que só olham o código publicado.
• 31 de março de 2026 — a versão 1.14.1 do Axios é publicada às 00:21 UTC com uma dependência fantasma chamada plain-crypto-js, implantando um trojan de acesso remoto antes de qualquer code review.
• 11 de maio de 2026 — em uma janela de seis minutos (19:20–19:26 UTC) são publicadas 84 versões maliciosas em 42 pacotes do TanStack, incluindo @tanstack/react-router (12M downloads semanais). A OpenAI confirma dois dispositivos internos comprometidos e força rotação dos certificados de assinatura macOS para ChatGPT, Codex e Atlas até 12 de junho.
• 19 de maio de 2026 — uma rajada automatizada de 22 minutos publica mais de 300 versões maliciosas em 323 pacotes da AntV, ampliando o raio de explosão para o ecossistema chinês de visualização de dados.

O total acumulado: 796 pacotes únicos comprometidos, ~20 milhões de downloads semanais infectados, mais de 25 mil repositórios maliciosos no GitHub e a confirmação de que pacotes npm infectados não são mais incidente — são paisagem.

Anatomia do worm Shai-Hulud

Essa família de pacotes npm infectados não é spam — é arquitetura de software malicioso bem desenhada. O ciclo segue quatro estágios reproduzíveis.

Estágio 1 — comprometimento da conta do mantenedor

O ponto de entrada quase sempre é o mesmo: phishing direcionado, token npm vazado em log público, ou uma chave OIDC roubada de um runner do GitHub Actions. No caso TanStack, o ataque sequestrou o pipeline legítimo de release com identidade OIDC válida, o que fez o pacote sair com SLSA provenance assinada — a primeira vez que isso foi documentado.

Estágio 2 — backdoor em todos os pacotes da vítima

Com o token na mão, o worm não publica em um pacote — publica em todos. O script enumera o que aquele mantenedor controla via npm whoami + npm access ls-packages e injeta o payload em até 100 pacotes por execução, com bump de versão minor para não gerar suspeita imediata.

Estágio 3 — exfiltração via GitHub público

O payload do Shai-Hulud 2.0 usa repositórios públicos do GitHub como canal de C2 reverso. Ele cria um repo na conta da vítima com um nome aleatório, despeja segredos coletados (variáveis de ambiente, arquivos .env, ~/.aws/credentials, ~/.npmrc, ~/.docker/config.json) e atacantes simplesmente fazem scraping desses repos com queries de busca.

Estágio 4 — autopropagação

Último estágio: o worm reaproveita os tokens npm encontrados no sistema da vítima para publicar versões backdoored em outros pacotes que aquele dev tenha acesso publish — geralmente como colaborador em libs de empresas. É o que transformou a campanha em pandemia: cada vítima vira vetor.

Os incidentes que marcaram 2026 — tabela comparativa

Data	Pacote / família	Impacto	Vetor inicial
24/11/2025	Shai-Hulud 2.0 (genérico)	796 pacotes, 20M downloads/sem	Token npm vazado
31/03/2026	[email protected]	RAT em milhões de apps Node.js	Conta mantenedor sequestrada
11/05/2026	TanStack (42 pacotes)	12M+ downloads/sem, OpenAI atingida	OIDC do release pipeline
19/05/2026	AntV (323 pacotes)	Ecossistema de dataviz inteiro	Conta mantenedor
Maio/2026	NX	Acesso admin AWS em <72h	Chave roubada no CI
Em curso	CanisterSprawl	Worm orquestrado por LLM	Phishing + automação IA

Note a aceleração: de um worm grande em novembro para quatro ondas em seis meses. O custo de operar campanhas assim despencou e a barreira de entrada hoje é menor do que rodar um SaaS.

Por que o ecossistema npm é tão vulnerável

O npm carrega cerca de 3 milhões de pacotes e ultrapassa 17 bilhões de downloads por semana, e essa escala é exatamente o que torna pacotes npm infectados tão letais. Cinco motivos estruturais que ninguém resolveu ainda:

1. Lifecycle scripts arbitrários — qualquer package.json pode rodar postinstall, preinstall ou prepare com permissão total no ambiente do dev. É feature, não bug, e existe desde 2012.
2. Dependência transitiva profunda — o axios parece uma lib só, mas puxa cerca de 50 deps indiretas. Você confia em quem você confia em quem você confia.
3. Assinatura opcional até pouco tempo atrás — só em 2025 o SLSA provenance virou padrão, e o TanStack mostrou que provenance assinada não impede o ataque se o pipeline já está comprometido.
4. Tokens npm de longa duração — a maioria dos devs não rotaciona o token publicado em 2019. Sem rotação, basta vazar uma vez.
5. Cultura de "atualizar logo" — Dependabot abre PR, alguém clica "merge" sem ler o diff, pipeline puxa a versão 1.14.1 recém-publicada e o RAT está dentro em quarenta minutos.

Quem é o alvo dos pacotes npm infectados em 2026

O alvo mudou. Em 2023 era cripto-bro com chave privada no .env. Em 2026 o cardápio é mais saboroso:

• Fintechs e exchanges brasileiras — chaves de wallets quentes valem o ataque inteiro.
• Times que rodam IA em produção — chaves da OpenAI e da Anthropic são revendidas em mercados black-hat por dezenas de milhares de dólares cada.
• Pipelines CI com OIDC para AWS/GCP — escalada para infraestrutura completa em menos de 72 horas, como mostrou o caso NX.
• Empresas com pipelines macOS — chaves de assinatura permitem distribuir malware como se fosse seu app legítimo, como tentaram contra a OpenAI.
• Times brasileiros de SaaS B2B — alvos macios, costumam ter .npmrc global no Mac do dev senior com permissão publish em libs corporativas.

Se a sua stack roda Node + IA + Cloud, você está no funil. Não é paranoia, é o relatório Cloud Threat Horizons H1 2026 do Google{target="_blank"} apontando para isso preto no branco.

Como detectar se você instalou um pacote npm infectado

Não dá pra terceirizar isso totalmente — mas dá pra processar bem rápido. Roteiro que aplicamos aqui na Agathas Web em todos os apps customizados de Moodle e na infra do Voyia:

1. Liste pacotes recém-atualizados nas últimas 72h: npm ls --depth=0 --json | jq '.dependencies | to_entries[] | {name: .key, version: .value.version}'.
2. Cruze com listas públicas de comprometidos — Socket, Snyk Vulnerability DB, OSV-Scanner e o feed da StepSecurity publicam IOCs em tempo quase real.
3. Procure scripts suspeitos no package.json instalado: find node_modules -name package.json -exec grep -l "postinstall\|preinstall" {} \; e leia cada um.
4. Cheque seu próprio GitHub por repositórios criados sem você lembrar — o Shai-Hulud 2.0 deposita segredos em repos públicos com nomes aleatórios na sua conta.
5. Audite ~/.npmrc e .npmrc do projeto — qualquer token sem 2FA enforce é alvo.
6. Reveja os 30 últimos npm install no CI — se algum apareceu em horário fora do padrão (3h da manhã, fim de semana), trate como suspeito.

Se encontrar qualquer indicador, revogue todos os tokens (npm, GitHub, AWS, OpenAI, Anthropic) antes de tentar limpar. A janela média de exploração ativa hoje é de 48 horas.

Como proteger seu projeto na prática

Defesa real contra pacotes npm infectados não é uma feature, é higiene contínua. O que efetivamente reduz superfície:

• npm ci em vez de npm install no CI — instala exatamente o package-lock.json, sem resolver versões novas.
• Lockfile commitado e revisado em todo PR. Mudou de tamanho sem motivo? Audite o diff.
• npm config set ignore-scripts true no ambiente CI e na máquina dos devs. Quebra dois ou três pacotes legítimos, mas neutraliza 90% dos worms.
• Tokens npm com expiração curta (90 dias) e 2FA obrigatório para publish.
• Mirror privado com Verdaccio, Artifactory ou GitHub Packages — você decide quando uma versão entra no inventário.
• SLSA provenance verificada no install (npm install --audit-signatures) — não é bala de prata, mas filtra os ataques menos sofisticados.
• Dependabot com revisão humana obrigatória — chega de auto-merge em libs com mais de 1M de downloads.
• Escaneamento contínuo com Socket, Snyk ou OSV-Scanner no CI, falhando o build em CVE crítico recém-publicado.
• Rotação trimestral de tokens npm, GitHub Actions, AWS access keys.

Nenhum item isolado é mágico. Combinados, reduzem o blast radius de "caos total" para "susto resolvível antes do café".

O que muda quando a IA escreve seu package.json

A IA generativa criou um vetor novo que ninguém viu vindo: typosquatting potencializado. Copilot, Cursor e Claude às vezes sugerem nomes de pacotes que não existem — chamados de hallucinated packages — e atacantes registram esses nomes no npm para colher o npm install de quem aceita a sugestão sem checar.

Pior: o CanisterSprawl observado em 2026 usa LLMs para gerar variações automatizadas dos payloads, mudando hashes, ordem de exfiltração e nomes de funções para escapar de detectores baseados em assinatura. É worm que se reescreve.

A contramedida não é abandonar IA — é instituir que toda dep sugerida por IA passa por verificação manual antes de virar npm install. Confira o número de downloads, a idade do pacote, o histórico de versões e se o nome bate exatamente com o oficial.

Próximos passos — governança de dependências

Deixar de tratar pacotes npm infectados como acidente exige montar processo. Os quatro itens mínimos:

1. Inventário e SBOM — gere um Software Bill of Materials por release com cyclonedx-npm ou syft. Sem SBOM, você não sabe o que tem; sem saber o que tem, você não defende.
2. Política de aprovação para nova dep — qualquer adição em dependencies precisa de revisor humano e justificativa no PR. Dependência interna padrão é mais barato que CVE.
3. Limite de devDeps — devDeps rodam no CI com os mesmos privilégios que prod. Trate com o mesmo rigor.
4. Monitoramento e playbook de incidente — quem revoga? Quem comunica clientes? Quem rotaciona? Decida antes do incidente, não durante.

Essa é a mesma disciplina que aplicamos em projetos críticos como a API Oficial do WhatsApp Business, onde uma dependência envenenada significa vazar conversas de clientes — não dá pra terceirizar essa governança para o npm install.

Conclusão — pacotes npm infectados não são mais exceção

A grande mudança de 2026 não é técnica, é cultural. Pacotes npm infectados deixaram de ser "raridade lamentável" para virarem "cenário base esperado". Quem segue tratando npm install como operação confiável vai ser pego — não é se, é quando.

O movimento que recomendo: mude o modelo mental de "vou atualizar quando der" para "toda nova versão é código não-confiável até prova em contrário". Lockfile congelado, scripts desativados, mirror privado, rotação de tokens, scan no CI. Em paralelo, monte um playbook de incidente com prazos de minutos, não de dias.

Aqui na Agathas Web aplicamos esse modelo em todos os projetos de Moodle customizado, Voyia (atendimento WhatsApp) e integrações com IA. O custo é uma cerimônia pequena por mês; o benefício é não acordar para descobrir que o cliente está vazando segredos pelo postinstall de uma transitiva sequestrada às três da manhã.

Se você não sabe por onde começar a auditoria do seu próprio package.json, é exatamente esse o pedido pra abrir como ticket interno na sua equipe ainda esta semana — antes do próximo Shai-Hulud.