TL;DR: o worm npm Mini Shai-Hulud
O Mini Shai-Hulud é um aviso sobre como um compromisso npm se espalha depois da primeira publicação maliciosa. O atacante não precisa de comprometer diretamente cada aplicação downstream. Precisa apenas 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, grafos, mapas e wrappers para React usados por equipas de engenharia que talvez nunca considerem essas dependências como críticas para a segurança.
O padrão é o problema real. O npm é útil porque centraliza a publicação, o scanning e o 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.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O que aconteceu na vaga AntV
A vaga AntV usou um ponto de entrada conhecido do npm: execução durante a instalação. A análise da Socket descreve um payload index.js na raiz que modificava o package.json para que o payload corresse durante o preinstall.
Isto importa porque npm install, pnpm install e yarn install não são passos passivos de download. Os scripts de ciclo de vida dos pacotes podem executar código antes de um programador rever o conteúdo do pacote ou correr a aplicação.
O payload estava fortemente ofuscado. A Socket reportou que usava 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 era recolher credenciais que permitissem ao malware publicar novamente, não apenas executar uma vez.
Como o Mini Shai-Hulud cria o efeito bola de neve
O payload visa ambientes de desenvolvimento e de CI/CD porque esses ambientes têm poder de publicação. Uma aplicação de navegador pode precisar apenas de um pacote de gráficos, mas a máquina ou workflow que o instala também pode ter acesso a credenciais de npm, GitHub, AWS, Kubernetes, Vault, SSH, Docker ou bases de dados.
Os alvos de credenciais incluem:
- Tokens do 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 do HashiCorp Vault
- Ficheiros de autenticação Docker
- Chaves SSH e chaves privadas
- Strings de ligação a bases de dados
Assim que o malware encontra credenciais npm utilizáveis, consegue enumerar os pacotes que a vítima pode manter, modificar tarballs de pacotes, adicionar um hook de instalação, aumentar versões e republicar pacotes comprometidos sob uma identidade de maintainer confiável.
Porque é que Axios e TanStack importam
A vaga AntV não aconteceu isoladamente. O ecossistema npm tem visto uma série de incidentes em que atacantes abusam de maintainers confiáveis, dependências transitivas e automação de CI/CD.
A análise da Datadog sobre o Axios descreve como um atacante sequestrou uma conta de maintainer do Axios em 2026-03-31 e publicou versões maliciosas do 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 o TanStack mostra outra lição. O TanStack usava trusted publishing OIDC do npm, o que elimina tokens npm estáticos de longa duração. Mesmo assim, o atacante conseguiu obter um caminho de publicação válido através de mecânicas de repositório e de workflow. O resultado foram versões maliciosas em todo o namespace do TanStack com proveniência aparentemente válida.
Nenhuma ferramenta isolada e defeituosa explica o padrão. O fio condutor comum é a quantidade de autoridade concentrada nos ambientes de desenvolvimento e nos workflows de release.
O npm é ao mesmo tempo ferramenta defensiva e caminho de ataque
O 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 o npm também dá aos atacantes uma camada central de distribuição. Se um pacote confiável publica uma versão maliciosa, os 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 a configuração de pacotes e builds nativos | Executam código do atacante durante a instalação |
| Contas de maintainer | Permitem publicar rapidamente | Transformam uma identidade comprometida em muitos pacotes envenenados |
| Trusted publishing | Reduz a exposição de tokens de longa duração | Pode ser abusado se o workflow ou o limite de confiança for comprometido |
A lição é reduzir a confiança automática em cada etapa onde o código executa, não abandonar o npm.
O que as equipas devem fazer agora
Comece pelo ambiente de build e de desenvolvimento. Qualquer máquina ou runner de CI que tenha instalado 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 de npm, GitHub, cloud, Vault, SSH, Docker e bases de dados acessíveis a esses sistemas
- Auditar pacotes de que é maintainer para detetar 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 cooldowns de dependências ou gates de revisão para que versões de pacotes recém-publicadas não entrem automaticamente em produção
- Monitorizar tráfego de saída de CI e de estações de trabalho de programadores 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 programador mantém.
Onde a cside se encaixa
A cside não é um scanner do registry npm e não substitui o 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 runtime do navegador. Muitos sites de produção carregam scripts de terceiros, SDKs, payloads de tag managers, pacotes de 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 time e ainda assim entregar comportamento arriscado ao navegador mais tarde.
A cside monitoriza o comportamento dos scripts enquanto estes executam no navegador do utilizador. Isso inclui alterações de scripts, acesso inesperado a dados, tentativas suspeitas de exfiltração e atividade do lado do navegador que os scanners de dependências não conseguem ver quando o código já está em produção.
A defesa certa é feita em camadas: proteger o caminho do registry, endurecer o CI, rodar segredos rapidamente e monitorizar o comportamento em runtime onde os utilizadores realmente executam o código.
