Como o ataque Mini Shai‑Hulud publicou centenas de pacotes maliciosos no npm em poucos minutos

O ecossistema de software open source funciona, em grande parte, na base da confiança: confiança nos mantenedores dos projetos, nos pipelines de CI/CD que geram os releases e nas assinaturas criptográficas que garantem a origem do código. A campanha Mini Shai‑Hulud mostrou como essa confiança pode ser explorada em larga escala.

Em maio de 2026, um grupo identificado como TeamPCP executou uma série de ataques à cadeia de suprimentos de software envolvendo npm (JavaScript) e PyPI (Python). Os invasores comprometeram projetos populares, publicaram centenas de versões maliciosas e utilizaram a própria infraestrutura legítima de build dos projetos para fazer esses pacotes parecerem autênticos.

Um dos episódios mais impressionantes ocorreu em 19 de maio de 2026, quando os atacantes publicaram 637 versões maliciosas em 323 pacotes npm em cerca de 22 minutos após comprometer uma conta de mantenedor ligada ao ecossistema @antv, bastante usado em bibliotecas de visualização de dados.

Pesquisadores de segurança consideram o caso um dos ataques mais sofisticados já registrados contra a cadeia de suprimentos open source — principalmente porque os artefatos maliciosos carregavam assinaturas e registros de proveniência válidos, algo que normalmente serviria para provar que o software é legítimo.

O que foi a campanha Mini Shai‑Hulud

O Mini Shai‑Hulud não foi um incidente isolado, mas uma campanha em várias etapas que atingiu diferentes projetos e organizações.

Entre 10 e 12 de maio de 2026, relatórios de segurança indicam que o grupo comprometeu mais de 170 pacotes npm e PyPI distribuídos em 19 namespaces, publicando mais de 400 versões maliciosas.

Entre os projetos afetados estavam bibliotecas e ferramentas ligadas a:

• TanStack
• Mistral AI
• UiPath
• OpenSearch
• Guardrails AI

Essas bibliotecas são usadas por milhares de aplicações e ferramentas de desenvolvimento. Somadas, acumulavam centenas de milhões de downloads históricos, o que amplia enormemente o impacto potencial de qualquer comprometimento.

Uma onda posterior do ataque focou no ecossistema AntV, um conjunto de bibliotecas JavaScript populares para visualização de dados, que somam cerca de 16 milhões de downloads semanais no npm.

Como mais de 600 versões maliciosas foram publicadas tão rápido

A velocidade do ataque chamou atenção porque os invasores exploraram algo comum no desenvolvimento moderno: automação de releases.

Na onda de 19 de maio, os atacantes teriam comprometido a conta npm do mantenedor associada ao pacote atool.

Com acesso de mantenedor, eles puderam:

• publicar novas versões automaticamente
• disparar scripts de release
• atualizar vários pacotes em paralelo

Projetos grandes frequentemente usam scripts ou pipelines de CI/CD para publicar pacotes automaticamente. Uma única conta comprometida pode acionar processos que liberam versões em dezenas ou centenas de pacotes.

Isso permitiu que o ataque publicasse centenas de artefatos maliciosos em minutos, algo praticamente impossível de fazer manualmente.

O abuso do GitHub Actions, OIDC e do “trusted publishing”

Outro ponto crítico do Mini Shai‑Hulud foi o uso indevido de mecanismos modernos de segurança que deveriam tornar a publicação de pacotes mais segura.

Muitos projetos open source hoje usam o chamado trusted publishing com GitHub Actions. Nesse modelo, o pipeline de CI obtém um token temporário de identidade usando OpenID Connect (OIDC) e publica o pacote sem precisar armazenar credenciais permanentes.

Os invasores exploraram esse fluxo.

Em alguns projetos comprometidos, pesquisadores descobriram que os atacantes conseguiram:

• sequestrar ou manipular workflows do GitHub Actions
• extrair tokens OIDC temporários da memória do runner
• usar esses tokens para autenticar publicações no npm

Como o próprio pipeline oficial fazia o publish, o pacote parecia ter sido lançado pelo sistema legítimo do projeto.

Malware com assinatura “legítima”

O ataque foi ainda mais preocupante porque afetou mecanismos de verificação modernos da cadeia de suprimentos.

Muitos pipelines hoje produzem proveniência SLSA e assinam artefatos com certificados Sigstore. Essas assinaturas permitem que desenvolvedores confirmem que um pacote foi gerado por um workflow confiável.

No Mini Shai‑Hulud, os invasores conseguiram obter certificados legítimos usando identidades de CI comprometidas e tokens OIDC. Como resultado, os pacotes maliciosos foram distribuídos com proveniência SLSA Build Level 3 válida e assinaturas criptográficas legítimas.

Do ponto de vista de verificação automática, tudo parecia correto: o pacote estava assinado, rastreável a um workflow real e publicado por um pipeline confiável.

O problema não era o sistema de assinatura em si — era que o ambiente de build confiável já havia sido comprometido.

O que o malware tentava roubar

Os pacotes contaminados incluíam código voltado para coletar segredos e credenciais usadas por desenvolvedores e infraestrutura.

Entre os dados visados estavam:

• tokens de CI/CD
• chaves de provedores de nuvem
• tokens de acesso do GitHub ou npm
• chaves SSH
• outras credenciais usadas por desenvolvedores

Ao roubar esses dados, o malware poderia comprometer novos repositórios ou pipelines de publicação e continuar se espalhando pelo ecossistema.

Esse comportamento fez com que pesquisadores descrevessem o Mini Shai‑Hulud como um “worm” de cadeia de suprimentos, capaz de se propagar de projeto em projeto.

Por que o ataque preocupa todo o ecossistema JavaScript

O caso revelou vários problemas estruturais na segurança do open source moderno.

Primeiro, mostrou que infraestruturas consideradas confiáveis podem ser usadas contra o próprio ecossistema. Mesmo mecanismos avançados como SLSA, Sigstore e OIDC não impedem um ataque se o pipeline de build estiver comprometido.

Segundo, evidenciou que uma única conta de mantenedor pode impactar centenas de pacotes. O incidente do AntV demonstrou como um único comprometimento pode gerar centenas de releases maliciosos em poucos minutos.

Terceiro, bibliotecas populares amplificam o impacto. Muitos projetos dependem de outros pacotes — as chamadas dependências transitivas — o que significa que uma atualização maliciosa pode se espalhar para milhares de aplicações.

Por fim, pesquisadores associam o Mini Shai‑Hulud a uma campanha mais ampla do grupo TeamPCP que também envolveu o comprometimento de ferramentas como o plugin Checkmarx Jenkins AST e múltiplos ecossistemas open source.

Como essas técnicas dependem de automação e padrões comuns de CI/CD, especialistas alertam que ataques semelhantes ou variantes copiadas provavelmente aparecerão.

A lição para desenvolvedores e empresas

O incidente reforça um ponto cada vez mais claro na segurança de software: assinaturas criptográficas e verificação de proveniência não são suficientes se o ambiente que produz o software for comprometido.

Por isso, muitas organizações estão reforçando práticas como:

• isolamento de runners de CI
• restrição de permissões em workflows
• monitoramento de publicações suspeitas
• auditoria contínua de dependências

À medida que builds automatizados e artefatos assinados se tornam padrão, a segurança do ecossistema depende cada vez mais da proteção de infraestrutura de CI/CD e identidades de desenvolvedores.

O Mini Shai‑Hulud mostrou quão rápido essa confiança pode ser explorada — e como o impacto pode se espalhar por todo o mundo open source.