Em 1 de junho de 2026, detetámos vários pacotes oficiais provenientes do Âmbito @redhat-cloud-services no npm foram comprometidos por um worm que rouba credenciais. Mais de 30 pacotes parecem ter sido afetados. O malware parece semelhante ao Malware Mini Shai-Hulud que foi recentemente disponibilizada em código aberto pela TeamPCP. Uma vez que as ferramentas foram disponibilizadas publicamente, outros agentes maliciosos têm agora acesso às mesmas técnicas e podem replicá-las ou adaptá-las. Os pacotes foram publicados através do GitHub Actions OIDC, indicando que o pipeline de CI/CD foi comprometido, e não um token npm. Se tiver instalado alguma versão de pacote afetada desde 1 de junho de 2026, considere todos secrets de CI, credenciais de nuvem, chaves SSH e tokens npm como comprometidos e altere-os imediatamente.
Cronologia da campanha Mini Shai-Hulud
- 22 de abril de 2026 - @bitwarden/cli foi comprometido através de um fluxo de trabalho do GitHub Actions adulterado. A carga útil identifica-se como «Shai-Hulud: The Third Coming».
- 29 de abril de 2026 — Quatro pacotes SAP do npm foram comprometidos devido a uma fuga de um token do npm através de uma compilação maliciosa de um pedido de pull no CircleCI.
- 30 de abril de 2026 — O PyTorch Lightning foi comprometido no PyPI, nas versões 2.6.2 e 2.6.3.
- 12 de maio de 2026 — O Mini Shai-Hulud ultrapassa os 160 pacotes, incluindo o Mistral e o Tanstack.
- 12 de maio de 2026 — A TeamPCP publica o código-fonte completo do Shai-Hulud no GitHub, juntamente com publicações no BreachForums a incentivar outras pessoas a realizarem as suas próprias campanhas.
- 19 de maio de 2026 — O pacote npm DurableTask da Microsoft foi comprometido, devido a uma conta do GitHub que já tinha sido comprometida anteriormente.
- 1 de junho de 2026 - Mais de 30
@redhat-cloud-servicespacotes npm comprometidos com Miasma, uma nova variante do Mini Shai-Hulud.
Miasma: O Shai-Hulud está de volta?
A carga útil incorporada nos pacotes afetados apresenta fortes semelhanças com o Mini Shai-Hulud, o malware de cadeia de abastecimento disponibilizado em código aberto pela TeamPCP. Curiosamente, esta versão autodenomina-se «Miasma» e parece ter substituído as conhecidas referências a «Dune» do Shai-Hulud por elementos da mitologia grega.
O TeamPCP é um grupo de cibercriminosos que vem a realizar ataques à Supply chain direcionados de CI/CD ataques à Supply chain vários meses. O seu malware «Mini Shai-Hulud» é um worm sofisticado destinado ao roubo de credenciais que se propaga através da republicação de versões com backdoor de pacotes aos quais a conta da vítima tem acesso. Já relatámos anteriormente violações que afetaram o Mistral e o TanStack, o Durable Task da Microsoft, o PyTorch Lightning, o Bitwarden CLI e o Intercom, todas elas atribuíveis à mesma ferramenta.
Quando a TeamPCP disponibilizou o Mini Shai-Hulud como código aberto, a ameaça passou a ir além de um único agente. Qualquer grupo pode agora adotar a estrutura, adaptá-la e implementá-la contra novos alvos.
Contorno de publicação de confiança
A publicação confiável é um mecanismo introduzido pelo npm para eliminar os tokens de publicação de longa duração dos pipelines de CI/CD, substituindo-os por tokens OIDC de curta duração emitidos pelo GitHub Actions. Foi concebido para ser mais seguro, mas, como demonstram ataques recentes, pode ser contornado se um atacante obtiver acesso a um pipeline de CI/CD através de uma vulnerabilidade ou de um token comprometido.
Descobrimos que a conta do GitHub de um funcionário da Red Hat foi comprometida e utilizada para enviar commits maliciosos e isolados diretamente para vários repositórios, contornando totalmente a revisão de código. Esses commits isolados continham um ficheiro de fluxo de trabalho (ci.yaml) e um script (_index.js).
nome: lançamento
em:
push:
ramos: ['*']
tarefas:
versão:
executa-se em: ubuntu-latest
permissões:
token de identificação: gravação
conteúdo: leitura
etapas:
- utiliza: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
- utiliza: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
- nome: preparar
executar: bun executar _index.js
env:
OIDC_PACKAGES: "@redhat-cloud-services/frontend-components-advisor-components, @redhat-cloud-services/chrome, @redhat-cloud-services/frontend-components, @redhat-cloud-services/frontend-components-config-utilities, @redhat-cloud-services/frontend-components-config, @redhat-cloud-services/eslint-config-redhat-cloud-services, @redhat-cloud-services/frontend-components-notifications, @redhat-cloud-services/frontend-components-remediations, @redhat-cloud-services/rule-components, @redhat-cloud-services/frontend-components-testing, @redhat-cloud-services/componentes-frontend-traduções, @redhat-cloud-services/tsc-transform-imports, @redhat-cloud-services/tipos, @redhat-cloud-services/componentes-frontend-utilitários"
WORKFLOW_ID: "ci.yaml"
SUFIXO_DO_ID_DO_REPOSITÓRIO: "RedHatInsights/frontend-components"Quando o fluxo de trabalho é executado, instala o Bun e executa _index.js, passando-lhe uma lista de pacotes de destino através do OIDC_PACOTES variável de ambiente. O script utiliza a id-token: escrever autorização para solicitar um token OIDC de curta duração ao GitHub e, em seguida, utiliza esse token para se autenticar diretamente no ponto de extremidade de publicação de confiança do npm e publicar versões com backdoor de todos os pacotes da lista.
Este é o mesmo padrão fundamental observado nos ataques ao TanStack e ao Bitwarden: o próprio pipeline de CI/CD torna-se a superfície de ataque, enquanto a publicação fiável baseada em OIDC — concebida para eliminar tokens de longa duração — se torna um sinal de confiança enganador.
O script de pré-instalação
Cada pacote comprometido declara um script de pré-instalação no seu ficheiro package.json que executa automaticamente o ficheiro index.js do Node.js em cada instalação do npm, antes de qualquer código da aplicação ser executado e antes de o programador ter qualquer indício de que algo está errado.
"scripts": {
"preinstall": "node index.js"
}
O ficheiro index.js contém uma carga útil de 4,2 MB, oculta por várias camadas de ofuscação.
O que ele rouba
Tal como nos ataques anteriores do Mini Shai-Hulud, a carga maliciosa realiza uma varredura abrangente de credenciais em fornecedores de serviços na nuvem, ambientes de CI/CD e ferramentas de desenvolvimento. No que diz respeito à integração contínua (CI), tem como alvo secrets do GitHub Actions, secrets GITHUB_TOKEN e ACTIONS_RUNTIME_TOKEN. No que diz respeito às credenciais na nuvem, recolhe chaves de acesso e tokens de sessão da AWS, credenciais padrão de aplicações e ficheiros de chaves de contas de serviço do GCP, bem como credenciais de entidades de serviço e tokens de identidade gerida do Azure. Além disso, procura tokens do HashiCorp Vault, tokens de contas de serviço do Kubernetes e ficheiros kubeconfig, tokens de publicação do npm e do PyPI, chaves privadas SSH, credenciais de registos Docker, chaves GPG e quaisquer ficheiros .env que consiga encontrar no sistema de ficheiros.
Como a Aikido detecta isso
Se você é um usuário Aikido, verifique seu feed central e filtre por problemas de malware. Isso aparecerá como um problema crítico 100/100. O Aikido reanalisa todas as noites, mas recomendamos acionar uma reanálise manual agora.
Se você ainda não é um usuário Aikido, pode criar uma conta e conectar seus repositórios. Nossa cobertura de malware está incluída no plano gratuito, não é necessário cartão de crédito.
Para uma cobertura mais abrangente em toda a sua equipa, a Proteção de Dispositivos Aikido oferece-lhe visibilidade e controlo sobre os pacotes de software instalados nos dispositivos da sua equipa. Abrange extensões de navegador, bibliotecas de código, plug-ins de IDE e dependências de compilação, tudo num único local. Impedir o malware antes que seja instalado.
Para proteção futura, considere Aikido Safe Chain (open source). O Safe Chain se integra ao seu fluxo de trabalho existente, interceptando comandos npm, npx, yarn, pnpm e pnpx e verificando pacotes contra Aikido Intel antes da instalação.
Indicadores de Compromisso
Se tiver instalado alguma das seguintes versões de pacotes, considere todos secrets de CI, credenciais de nuvem, chaves SSH e tokens npm como comprometidos e atualize-os imediatamente:
@redhat-cloud-services/chrome(2.3.1, 2.3.2)@redhat-cloud-services/cliente-de-conformidade(4.0.3, 4.0.4)@redhat-cloud-services/config-manager-client(5.0.4, 5.0.5)@redhat-cloud-services/cliente-de-direitos(4.0.11, 4.0.12)@redhat-cloud-services/eslint-config-redhat-cloud-services(3.2.1, 3.2.2)@redhat-cloud-services/componentes-frontend(7.7.2, 7.7.3)@redhat-cloud-services/componentes-frontend-componentes-do-conselheiro(3.8.2)@redhat-cloud-services/componentes-frontend-configuração(6.11.3, 6.11.4)@redhat-cloud-services/utilitários-de-configuração-de-componentes-frontend(4.11.2, 4.11.3)@redhat-cloud-services/componentes-frontend-notificações(6.9.2, 6.9.3)@redhat-cloud-services/correções-de-componentes-frontend(4.9.2, 4.9.3)@redhat-cloud-services/teste-de-componentes-frontend(1.2.1, 1.2.2)@redhat-cloud-services/traduções-de-componentes-frontend(4.4.1, 4.4.2)@redhat-cloud-services/componentes-frontend-utilitários(7.4.1, 7.4.2)@redhat-cloud-services/hcc-feo-mcp(0.3.1, 0.3.2)@redhat-cloud-services/hcc-kessel-mcp(0.3.1, 0.3.2)@redhat-cloud-services/hcc-pf-mcp(0.6.1, 0.6.2)@redhat-cloud-services/host-inventory-client(5.0.3, 5.0.4)@redhat-cloud-services/insights-client(4.0.4, 4.0.5)@redhat-cloud-services/integrações-cliente(6.0.4, 6.0.5)@redhat-cloud-services/clientes-javascript-partilhados(2.0.8, 2.0.9)@redhat-cloud-services/cliente-de-notificações(6.1.4, 6.1.5)@redhat-cloud-services/patch-client(4.0.4, 4.0.5)@redhat-cloud-services/guias-rápidos-para-clientes(4.0.11, 4.0.12)@redhat-cloud-services/rbac-client(9.0.3, 9.0.4)@redhat-cloud-services/correções-cliente(4.0.4, 4.0.5)@redhat-cloud-services/componentes-de-regra(4.7.2, 4.7.3)@redhat-cloud-services/sources-client(3.0.10, 3.0.11)@redhat-cloud-services/cliente-de-inventário-topológico(3.0.10, 3.0.11)@redhat-cloud-services/tsc-transform-imports(1.2.2)@redhat-cloud-services/tipos(3.6.1, 3.6.2, 3.6.4)@redhat-cloud-services/vulnerabilidades-cliente(2.1.8, 2.1.9)
