TL;DR
O Mini Shai-Hulud é um aviso sobre como um compromisso npm se espalha depois da primeira publicação maliciosa. O atacante não precisa comprometer diretamente cada aplicação downstream. Precisa de uma conta de maintainer, um caminho de CI ou um ponto de execução durante a instalação que exponha credenciais.
Em 2026-05-19, a Socket reportou 639 versões de pacotes comprometidas em 323 pacotes únicos numa vaga Mini Shai-Hulud concentrada no ecossistema @antv. O conjunto afetado incluía pacotes de gráficos, visualização, mapas e wrappers React usados por equipas de engenharia que talvez nunca tratem essas dependências como críticas para segurança.
O padrão é o problema real. npm é útil porque centraliza publicação, scanning e takedown. Essa mesma centralização torna-se perigosa quando scripts de ciclo de vida, trusted publishing e credenciais de maintainers são abusados para transformar pacotes numa rede de distribuição.
O que aconteceu na vaga AntV
A vaga AntV usou um ponto de entrada clássico em npm: execução durante instalação. A análise da Socket descreve um payload index.js na raiz que modificava package.json para executar durante preinstall.
Isto importa porque npm install, pnpm install e yarn install não são passos passivos de download. Scripts de ciclo de vida de pacotes podem executar código antes de um desenvolvedor rever o conteúdo do pacote ou correr a aplicação.
O payload estava fortemente ofuscado. A Socket reportou decoding de strings em runtime, exfiltração encriptada, uso da API do GitHub, uso da API do registry npm e um caminho HTTPS fixo de exfiltração. O objetivo não era apenas executar malware uma vez. O objetivo era recolher credenciais que permitissem ao malware publicar novamente.
Como o Mini Shai-Hulud cria o efeito bola de neve
O payload visa ambientes de desenvolvimento e CI/CD porque esses ambientes têm poder de publicação. Uma aplicação web pode precisar apenas de um pacote de gráficos, mas a máquina ou workflow que o instala também pode ter acesso a npm, GitHub, AWS, Kubernetes, Vault, SSH, Docker ou credenciais de bases de dados.
Os alvos de credenciais incluem:
- Tokens GitHub e material OIDC do GitHub Actions
- Tokens de publicação npm
- Credenciais AWS e metadados de instância
- Ficheiros de contas de serviço Kubernetes
- Tokens HashiCorp Vault
- Ficheiros de autenticação Docker
- Chaves SSH e chaves privadas
- Strings de ligação a bases de dados
Quando o malware encontra credenciais npm utilizáveis, consegue enumerar pacotes que a vítima pode manter, modificar tarballs, adicionar um hook de instalação, aumentar versões e republicar pacotes comprometidos sob uma identidade de maintainer confiável.
Porque Axios e TanStack importam
A vaga AntV não aconteceu isoladamente. O ecossistema npm viu uma série de incidentes em que atacantes abusam de maintainers confiáveis, dependências transitivas e automação CI/CD.
A análise da Datadog sobre Axios descreve como um atacante sequestrou uma conta de maintainer do Axios em 2026-03-31 e publicou versões maliciosas de axios que adicionavam a dependência trojanizada plain-crypto-js. Essa dependência descarregava e executava um trojan de acesso remoto multiplataforma durante a instalação.
A análise da Endor Labs sobre TanStack mostra outra lição. A TanStack usava trusted publishing OIDC de npm, que remove tokens npm estáticos de longa duração. Mesmo assim, o atacante obteve um caminho de publicação válido através de mecânicas de repositório e workflow. O resultado foram versões maliciosas no namespace TanStack com proveniência aparentemente válida.
O fio condutor não é uma ferramenta quebrada. É a quantidade de autoridade concentrada em ambientes de desenvolvimento e workflows de release.
npm é ferramenta defensiva e caminho de ataque
npm dá aos defensores um local central para inspecionar pacotes, sinalizar malware, deprecar releases e revogar tokens. Esse modelo centralizado é melhor do que downloads opacos e isolados.
Mas npm também dá aos atacantes uma camada central de distribuição. Se um pacote confiável publica uma versão maliciosa, utilizadores downstream podem obtê-la através de instalações comuns, atualizações de lockfile, rebuilds de CI ou resolução de dependências transitivas.
| Funcionalidade npm | Valor defensivo | Valor para o atacante |
|---|---|---|
| Registry central | Permite scanning, avisos e takedown | Dá ampla distribuição a versões maliciosas |
| Scripts de ciclo de vida | Suportam setup de pacotes e builds nativos | Executam código atacante durante instalação |
| Contas de maintainer | Permitem publicar rapidamente | Transformam uma identidade comprometida em muitos pacotes envenenados |
| Trusted publishing | Reduz exposição de tokens de longa duração | Pode ser abusado se o workflow ou limite de confiança for comprometido |
A lição não é abandonar npm. A lição é reduzir confiança automática em cada etapa onde código executa.
O que as equipas devem fazer agora
Comece pelo ambiente de build e desenvolvimento. Qualquer máquina ou runner de CI que instalou um pacote afetado deve ser tratado como exposto até as credenciais serem revistas.
- Verificar lockfiles e logs do package manager para versões afetadas instaladas em ou depois de 2026-05-19
- Rodar credenciais npm, GitHub, cloud, Vault, SSH, Docker e bases de dados acessíveis a esses sistemas
- Auditar pacotes mantidos para versões inesperadas, hooks de instalação ou dependências git adicionadas
- Usar instalações estritas por lockfile como
npm ci,pnpm install --frozen-lockfileouyarn install --frozen-lockfile - Desativar scripts de ciclo de vida quando for prático com
--ignore-scripts, especialmente em jobs de CI que não precisam de builds nativos - Adicionar dependency cooldowns ou gates de revisão para que versões recém-publicadas não entrem automaticamente em produção
- Monitorizar tráfego de saída de CI e workstations de desenvolvedores para caminhos suspeitos de exfiltração
Estes controlos reduzem a probabilidade de um pacote malicioso se tornar um incidente de publicação em todos os pacotes que um desenvolvedor mantém.
Onde a cside se encaixa
A cside não é um scanner do registry npm e não substitui hardening de CI/CD. Continua a precisar de scanning de dependências, lockfiles, higiene de tokens e controlos estritos de release.
A cside cobre a parte da cadeia de fornecimento que executa no navegador. Muitos sites de produção carregam scripts de terceiros, SDKs, payloads de tag managers, analytics e código entregue dinamicamente que nunca se comporta como uma dependência npm fixa. Um pacote ou fornecedor pode parecer legítimo em build e ainda assim entregar comportamento arriscado ao navegador mais tarde.
A cside monitoriza comportamento de scripts enquanto executam no navegador do utilizador. Isso inclui alterações de scripts, acesso inesperado a dados, tentativas suspeitas de exfiltração e atividade browser-side que scanners de dependências não conseguem ver quando o código já está em produção.
A defesa certa é em camadas: proteger o caminho do registry, endurecer CI, rodar segredos rapidamente e monitorizar comportamento em runtime onde os utilizadores realmente executam o código.
