Worm Mini Shai-Hulud compromete pacotes do TanStack, Mistral AI, Guardrails AI e outros projetos
Os ataques na cadeia de suprimentos de software estão ficando cada vez mais sofisticados, e a campanha mais recente do grupo TeamPCP é um exemplo bem claro disso.
Batizada de Mini Shai-Hulud, a ofensiva comprometeu pacotes de projetos como TanStack, Mistral AI, Guardrails AI, UiPath e OpenSearch, além de dezenas de outros distribuídos via npm e PyPI.
O número assusta: mais de 170 pacotes afetados e impressionantes 518 milhões de downloads acumulados nas versões comprometidas. Pelo menos 400 repositórios com credenciais roubadas foram criados como parte da onda de ataque, todos contendo a string Shai-Hulud: Here We Go Again.
Não é um ataque comum.
Estamos diante de um worm com capacidade de autoproliferação, que se espalha por toda a cadeia sem precisar roubar tokens de publicação tradicionais, explorando credenciais e infraestruturas de CI/CD legítimas para se mover de um mantenedor para outro de forma quase invisível.
O que mais chama atenção aqui não é só a escala, mas a engenharia por trás do ataque.
Pela primeira vez em um caso documentado, pacotes maliciosos foram publicados com proveniência SLSA Build Level 3 válida, aquele conjunto de garantias que deveria sinalizar exatamente o oposto: que o software é confiável e que o processo de build não foi adulterado.
Múltiplos relatórios de empresas como Aikido Security, Endor Labs, SafeDep, Socket, StepSecurity e Snyk confirmaram os detalhes técnicos da campanha. Ao longo deste artigo, vamos detalhar como tudo isso funcionou na prática, quais projetos foram comprometidos, o que o malware faz depois de instalado e o que desenvolvedores precisam saber agora para proteger seus ambientes. 🔍
Como o Mini Shai-Hulud se espalhou pela cadeia de suprimentos
Para entender a gravidade do que aconteceu, é preciso entender a lógica por trás da movimentação do Mini Shai-Hulud. Diferente de ataques convencionais, onde um agente malicioso precisa comprometer individualmente cada conta de mantenedor ou roubar tokens de autenticação, esse worm funciona de maneira muito mais inteligente e assustadora. Ele age dentro de ambientes de integração contínua já autorizados, aproveitando pipelines de CI/CD que os próprios projetos utilizam no dia a dia para construir e publicar versões. Isso significa que o código malicioso circula com todas as permissões necessárias, sem levantar alarmes imediatos nos sistemas de detecção tradicionais.
O mecanismo de autoproliferação é o ponto central de tudo. Quando o worm ganha acesso ao ambiente de build de um mantenedor, ele não fica parado. Ele localiza um token npm publicável com a configuração bypass_2fa definida como true, enumera todos os pacotes publicados pelo mesmo mantenedor e troca um token OIDC do GitHub por um token de publicação específico para cada pacote, contornando completamente a autenticação tradicional. A partir daí, replica o comportamento malicioso para esses novos ambientes, publicando versões comprometidas em registros como npm e PyPI de forma automatizada. Todo esse ciclo acontece sem interação humana direta, o que explica a velocidade com que o ataque alcançou mais de 170 pacotes em um intervalo relativamente curto de tempo.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
A técnica utilizada no ecossistema TanStack é particularmente engenhosa. Segundo a análise post-mortem publicada pelo próprio TanStack, o comprometimento envolveu um ataque encadeado via GitHub Actions que explorou o gatilho pull_request_target, envenenamento do cache do GitHub Actions e extração em tempo de execução de um token OIDC diretamente da memória do processo runner. Os atacantes prepararam o payload malicioso em um fork do GitHub através de um commit órfão, injetaram o código nos tarballs publicados no npm e então sequestraram o workflow legítimo do repositório TanStack/router para publicar as versões comprometidas com proveniência SLSA válida.
O que torna essa campanha ainda mais preocupante é justamente o fato de que os pacotes publicados carregavam proveniência SLSA Build Level 3 válida. O framework SLSA, que significa Supply Chain Levels for Software Artifacts, foi criado para oferecer garantias sobre a integridade do processo de construção de software. Um pacote com essa certificação deveria, em teoria, ser seguro, rastreável e livre de adulterações. Mas como o ataque operou dentro de infraestruturas legítimas, ele conseguiu gerar essa proveniência de forma tecnicamente correta, enganando até os mecanismos de verificação mais rigorosos.
Como explicou o pesquisador Peyton Kennedy, da Endor Labs, o commit órfão disparou uma execução de workflow do GitHub Actions contra a superfície legítima do TanStack/router. Como a configuração de trusted publisher do OIDC concedia confiança no nível do repositório, sem escopo restrito a uma branch protegida ou arquivo de workflow específico, o workflow disparado por aquele commit conseguiu solicitar um token de publicação npm válido e de curta duração.
É a primeira vez que esse tipo de contorno foi documentado em escala real, e isso redefine o que a comunidade entende como garantia de segurança em builds automatizados. 😬
TanStack, Mistral AI e Guardrails AI entre os projetos comprometidos
O TanStack é um dos ecossistemas mais populares do mundo JavaScript moderno. Projetos como TanStack Query, TanStack Router e TanStack Table são usados por milhares de aplicações em produção ao redor do globo, com downloads diários na casa dos milhões. O comprometimento do TanStack recebeu o identificador CVE-2026-45321, com uma pontuação CVSS de 9.6 em 10.0, indicando severidade crítica. O incidente impactou 42 pacotes e 84 versões em todo o ecossistema TanStack.
Quando um pacote desse nível de adoção é comprometido, o impacto potencial vai muito além dos números diretos de download. Desenvolvedores que utilizam essas bibliotecas como dependências em seus próprios projetos também acabam expostos sem saber, criando um efeito cascata que se multiplica ao longo de toda a cadeia produtiva de software.
O TanStack informou que rastreou o comprometimento e confirmou que nenhum token npm foi roubado diretamente, e que o workflow de publicação npm em si não foi comprometido. O vetor de ataque foi a exploração encadeada do sistema de GitHub Actions e OIDC.
A abordagem técnica variou entre os alvos
Um detalhe técnico importante é que a abordagem do ataque variou entre os diferentes alvos. No caso do TanStack, diferente da onda anterior que atingiu pacotes SAP, onde os pacotes comprometidos adicionavam um hook de preinstall para disparar a sequência de infecção, o cluster TanStack adotou uma estratégia diferente. Os pacotes incluíam um arquivo JavaScript dentro do tarball e adicionavam uma dependência opcional que apontava para um pacote hospedado no GitHub. Essa dependência continha um hook de ciclo de vida prepare que executava o payload JavaScript através do runtime Bun.
Já as atualizações nos pacotes da Mistral AI seguiram a abordagem anterior, substituindo o conteúdo do arquivo package.json com um hook de preinstall para invocar node setup.mjs, que fazia o download do Bun e executava o mesmo malware JavaScript.
No caso da Mistral AI, a situação tem uma camada adicional de complexidade. A empresa é uma das mais relevantes no cenário atual de modelos de linguagem de grande escala, e seus pacotes oficiais são utilizados por desenvolvedores que integram capacidades de inteligência artificial em aplicações e serviços. A análise da Microsoft sobre o pacote malicioso mistralai no PyPI revelou que ele foi projetado para baixar um stealer de credenciais de um servidor remoto e inclui lógica de reconhecimento por país para evitar ambientes em idioma russo, além de uma ramificação destrutiva com geofencing que tem uma chance de 1 em 6 de executar o comando rm -rf / quando o sistema parece estar em Israel ou Irã.
O comprometimento do Guardrails AI na versão 0.10.1 no PyPI é especialmente notável porque o código malicioso executa na importação. O pacote verifica se está rodando em sistemas Linux, faz o download de um artefato Python remoto, salva em /tmp/transformers.pyz e executa com python3 sem nenhuma verificação de integridade.
Lista completa de pacotes comprometidos identificados
Além do TanStack e Mistral AI, a campanha se espalhou para diversos outros pacotes, incluindo alguns no PyPI:
- [email protected] (PyPI)
- [email protected] (PyPI)
- @opensearch-project/[email protected], 3.6.2, 3.7.0 e 3.8.0
- @squawk/[email protected]
- @squawk/[email protected]
- @squawk/[email protected]
- @tallyui/[email protected], 1.0.2 e 1.0.3
- @tallyui/[email protected], 1.0.2 e 1.0.3
Segundo dados da OX Security, o incidente afetou mais de 170 pacotes em ambos os registros npm e PyPI. A diversidade dos alvos sugere que a estratégia do grupo não foi focar em um único ecossistema, mas sim mapear conexões entre mantenedores e projetos para maximizar o alcance de cada novo ponto de entrada conquistado. Essa abordagem sistêmica é o que diferencia o Mini Shai-Hulud de campanhas anteriores. 🔐
O que o malware faz depois de instalado
Uma vez que um pacote comprometido é instalado no ambiente de um desenvolvedor ou em um pipeline de CI/CD, o Mini Shai-Hulud começa a operar em múltiplas frentes. Os pacotes npm afetados foram modificados para incluir um arquivo JavaScript ofuscado chamado router_init.js, projetado para analisar o ambiente de execução e lançar um stealer de credenciais abrangente capaz de mirar em provedores de nuvem, carteiras de criptomoedas, ferramentas de IA, aplicativos de mensagens e sistemas de CI, incluindo GitHub Actions.
Os dados coletados são exfiltrados para o domínio filev2.getsession.org. O uso da infraestrutura do Session Protocol é uma tentativa deliberada dos atacantes de evadir detecção, já que o domínio dificilmente será bloqueado em ambientes corporativos por pertencer a um serviço de mensagens descentralizado e focado em privacidade.
Múltiplos mecanismos de persistência
O malware demonstra um nível notável de sofisticação nos mecanismos de persistência que implementa:
- Hooks de persistência no Claude Code e VS Code: O malware se instala de forma a sobreviver a reinicializações do sistema e se re-executar toda vez que as IDEs são iniciadas.
- Serviço gh-token-monitor: Um serviço dedicado que monitora e re-exfiltra tokens do GitHub continuamente.
- Workflows maliciosos do GitHub Actions: Dois workflows são injetados para serializar segredos do repositório em um objeto JSON e fazer upload dos dados para um servidor externo em api.masscan.cloud.
- Fallback via GraphQL: Como opção alternativa, os dados criptografados são commitados em repositórios controlados pelos atacantes sob o nome de autor [email protected] através da API GraphQL do GitHub, usando os tokens roubados.
O dead-mans switch: uma armadilha para quem tenta reagir
Um dos comportamentos mais agressivos e inéditos introduzidos nesta campanha é a instalação de um dead-mans switch. Trata-se de um shell script que verifica periodicamente se um token npm criado pelo malware não foi revogado, consultando o endpoint api.github.com/user a cada 60 segundos. O token possui a descrição provocativa IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.
Se o desenvolvedor revogar o token pelo painel do npm, o script dispara uma rotina destrutiva que executa rm -rf ~/ na máquina infectada, essencialmente transformando o malware em um wiper. Essas mudanças indicam que o TeamPCP está se tornando mais agressivo e evoluindo suas técnicas a cada nova campanha.
Isso é extremamente importante: desenvolvedores não devem revogar os tokens npm antes de isolar e criar uma imagem forense do sistema. Reagir precipitadamente pode resultar na destruição completa dos dados da máquina. 🚨
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Por que este ataque muda as regras do jogo
O grupo TeamPCP demonstrou um nível de sofisticação técnica que vai além do que se via em campanhas anteriores de ataques na cadeia de suprimentos. A combinação entre autoproliferação, uso de infraestruturas legítimas e geração de proveniência SLSA válida cria um cenário onde as defesas tradicionais simplesmente não são suficientes. Ferramentas de varredura de vulnerabilidades que dependem de assinaturas conhecidas não detectam o problema porque o código malicioso chega embrulhado em processos tecnicamente corretos.
Como destacou o pesquisador Ashish Kurmi, da StepSecurity, o ataque publicou versões maliciosas através do próprio pipeline de release do GitHub Actions do projeto, usando tokens OIDC sequestrados. Em uma escalação extremamente rara, os pacotes comprometidos carregam atestações de proveniência SLSA Build Level 3 válidas, tornando este o primeiro worm npm documentado que produz pacotes maliciosos com atestação validamente emitida.
Avital Harel, líder de pesquisa em segurança da Upwind, contextualizou bem a gravidade: esta campanha reflete uma mudança mais ampla nos ataques à cadeia de suprimentos, saindo do comprometimento isolado de pacotes para uma propagação orientada por identidade através de infraestrutura de CI/CD confiável. Uma vez que os atacantes ganham acesso a workflows de publicação e identidades de pipeline, o próprio processo de entrega de software se torna o mecanismo de distribuição. O desafio para os defensores é que grande parte dessa atividade pode parecer legítima na superfície, o que torna a visibilidade comportamental durante instalações e builds cada vez mais importante.
O que desenvolvedores precisam saber agora
A primeira coisa que qualquer desenvolvedor ou equipe de engenharia deve entender é que proveniência válida não é mais sinônimo de segurança absoluta. O fato de o Mini Shai-Hulud ter conseguido publicar pacotes com certificação SLSA Build Level 3 legítima obriga a comunidade a revisar o peso que essa garantia tem dentro de um processo de avaliação de segurança. Isso não significa abandonar o uso de frameworks como SLSA, que continuam sendo ferramentas valiosas dentro de uma estratégia mais ampla. Significa que eles precisam ser tratados como uma camada de verificação entre várias, e não como um atestado definitivo de que um pacote é seguro para uso em produção.
Práticas como auditoria frequente de dependências, uso de lockfiles atualizados e monitoramento ativo de mudanças nos pacotes utilizados são mais importantes do que nunca. Ferramentas que alertam sobre publicações inesperadas de novas versões, especialmente em pacotes amplamente utilizados, podem ser um diferencial importante para detectar atividades suspeitas antes que elas se espalhem pelo ambiente.
Ações práticas para proteger seu ambiente
- Não revogue tokens npm imediatamente se suspeitar de comprometimento. Isole e crie uma imagem forense do sistema primeiro para evitar ativar o dead-mans switch.
- Revise configurações de OIDC trusted publisher para garantir que a confiança esteja escopada para branches protegidas e arquivos de workflow específicos, não para o repositório inteiro.
- Audite os segredos armazenados em pipelines de CI/CD e implemente o princípio do menor privilégio para tokens de publicação.
- Monitore publicações inesperadas em pacotes que você mantém ou dos quais depende, especialmente versões que aparecem fora do ciclo normal de release.
- Implemente verificações comportamentais que analisem o que os pacotes fazem em tempo de execução, não apenas o que eles parecem ser no momento da instalação.
- Verifique suas dependências contra as listas de versões comprometidas publicadas pelas empresas de segurança que analisaram a campanha.
Os compromissos de segurança precisam evoluir junto com as ameaças. Campanhas como a do Mini Shai-Hulud mostram que os atacantes estão investindo tempo e conhecimento técnico para entender exatamente como os sistemas de confiança do ecossistema open source funcionam, e depois explorar exatamente esses mecanismos. A resposta da comunidade não pode ser menos sofisticada do que isso.
Como destacou a análise da Socket, esta atividade mais recente mostra a campanha continuando a se propagar tanto no npm quanto no PyPI, com pacotes afetados abrangendo infraestrutura de busca, ferramentas de IA, pacotes de desenvolvimento relacionados à aviação, automação empresarial, ferramentas de frontend e ecossistemas adjacentes a CI/CD.
A segurança da cadeia de suprimentos de software se tornou, de uma vez por todas, uma responsabilidade coletiva que exige atenção contínua e colaboração ativa entre mantenedores, empresas e a comunidade de segurança. O Mini Shai-Hulud não é apenas mais um incidente na lista crescente de ataques supply chain. É um ponto de inflexão que demonstra como a confiança automatizada, quando explorada por agentes sofisticados, pode se transformar na maior vulnerabilidade de todo o ecossistema. 🛡️
