Ataque à cadeia de suprimentos Miasma: código malicioso encontrado em pacotes npm de @redhat-cloud-services

Em 1º de junho de 2026, pesquisadores identificaram código malicioso embutido em pelo menos 32 versões de pacotes publicados sob o namespace npm @redhat-cloud-services, um conjunto de componentes de frontend e clientes de API que alimentam o Red Hat Hybrid Cloud Console. As versões comprometidas incluem um script preinstall que executa uma carga maliciosa ofuscada assim que um pacote é instalado, coletando credenciais de desenvolvedores e da nuvem e tentando se propagar para outros pacotes que a vítima pode publicar. Os pacotes afetados somam, em média, cerca de 80 mil downloads por semana, então o raio de impacto vai muito além dos próprios pipelines da Red Hat.

A campanha foi batizada de Miasma, e sua carga maliciosa é uma versão levemente modificada do worm (Mini) Shai-Hulud, que o TeamPCP tornou open source no início deste ano. Se você instalou algum pacote @redhat-cloud-services ou criou um projeto que depende de um deles, trate o caso como um incidente ativo e considere expostos todos os segredos que passaram pelas máquinas afetadas.

Resumo

• O quê: Código malicioso (worm que se autopropaga + ladrão de credenciais) embutido em versões publicadas no npm.

• Namespace: @redhat-cloud-services (componentes de frontend e clientes de API do Red Hat Hybrid Cloud Console).

• Escopo: Pelo menos 32 versões de pacotes no namespace, com cerca de 80 mil downloads semanais no total. Publicadas em duas ondas.

• CVE: Nenhum atribuído. Acompanhado por meio de alertas da Snyk. A Snyk classifica o alerta principal com nota 9,3 (Crítico, CVSS v4.0) e maturidade de exploração como Em ataque.

• Causa raiz: Uma conta GitHub de um funcionário da Red Hat foi comprometida e usada para enviar commits órfãos maliciosos que solicitaram um token OIDC para publicar no npm e lançaram pacotes com proveniência SLSA válida.

• Status: A maioria das versões maliciosas foi revogada no npm poucas horas após a divulgação; algumas ainda estavam disponíveis enquanto a análise continuava. A investigação está em andamento.

• Ação: Fixe as dependências em versões não afetadas, reinstale com scripts desativados e altere todas as credenciais que poderiam ser acessadas a partir de uma estação de trabalho ou executor de CI afetado.

O que aconteceu

Os pacotes do namespace @redhat-cloud-services são dependências de build do Hybrid Cloud Console: componentes React compartilhados (@redhat-cloud-services/frontend-components, frontend-components-utilities, frontend-components-notifications), clientes de API gerados (rbac-client, host-inventory-client, compliance-client e cerca de duas dúzias de outros) e ferramentas de suporte. Alguns deles, por si só, recebem um volume significativo de tráfego. Para verificar rapidamente o escopo informado, a API de downloads do npm mostra que os maiores pacotes, como @redhat-cloud-services/types, têm dezenas de milhares de downloads por semana:

1# https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes
2curl -s "https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes"
3# {"downloads":15060, ... }

A soma dos downloads na última semana completa (de 25 a 31 de maio de 2026) dos pacotes afetados chega a cerca de 79 mil, em linha com os aproximadamente 80 mil citados neste incidente. As modificações não autorizadas foram identificadas pela primeira vez em 1º de junho de 2026.

As versões maliciosas foram publicadas em duas ondas em 1º de junho. Quando os alertas foram divulgados, o npm já havia revogado a maioria das versões comprometidas, mas algumas ainda estavam disponíveis durante a análise.

Detalhes técnicos

O gatilho executado durante a instalação

Cada versão comprometida adiciona um hook executado durante a instalação. O npm executa scripts preinstall automaticamente durante npm install, antes da execução de qualquer código seu. Portanto, basta resolver a dependência para acionar a carga maliciosa:

1{
2  "scripts": {
3    "preinstall": "node index.js"
4  }
5}

O arquivo index.js que ele chama é um arquivo JavaScript excepcionalmente grande e muito ofuscado. O autor usou eval() e decodificação de strings baseada em ROT para ocultar a lógica, um padrão de técnicas visto em variantes anteriores do Shai-Hulud. Depois de decodificada, a carga maliciosa se revela um coletor de credenciais e worm com várias etapas.

O que a carga maliciosa faz

O núcleo funcional corresponde à estrutura do (Mini) Shai-Hulud, embora referências à mitologia grega tenham substituído os elementos cosméticos originais inspirados em Duna (como o uso de spartan). Os repositórios recém-criados pelos atacantes trazem a descrição Miasma: The Spreading Blight, um indicador útil para investigação.

Na execução, a carga:

• Coleta segredos e credenciais do ambiente local e do contexto de CI: variáveis de ambiente, tokens em ~/.npmrc, chaves SSH, tokens do GitHub e segredos de CI/CD.

• Enumera identidades na nuvem. A mudança mais significativa nesta variante é a inclusão de dois novos coletores para GCP e Azure, que enumeram todas as identidades que o host infectado pode assumir, e não apenas segredos estáticos. Variantes anteriores se concentravam em roubar credenciais; esta busca mapear e alcançar o próprio plano de controle da nuvem.

• Propaga-se. Consulta o registro em busca de outros pacotes que a identidade comprometida pode publicar e os republica com a mesma carga maliciosa. É isso que transforma o comprometimento de um único mantenedor em um worm.

Causa raiz: conta comprometida, proveniência válida

Vale a pena se deter neste detalhe. O código malicioso não entrou por meio de um typosquat nem de uma dependência transitiva comprometida. As evidências indicam que a conta GitHub de um funcionário da Red Hat foi comprometida e usada para enviar commits órfãos maliciosos diretamente para dois repositórios RedHatInsights, contornando a revisão de código.

Esses commits adicionaram um workflow mínimo do GitHub Actions que:

1. Era acionado ao enviar alterações para qualquer branch.

2. Solicitava um token de identidade OIDC do GitHub por meio de id-token: write.

3. Executava uma carga maliciosa ofuscada (_index.js) que publicava os pacotes no npm.

Como a publicação foi executada no contexto do Actions de um repositório legítimo, as versões resultantes vieram com atestados de proveniência SLSA válidos. A proveniência estava tecnicamente correta: o pacote realmente foi compilado pelo workflow daquele repositório. O que ela não podia revelar é que o próprio workflow não era autorizado. É a mesma brecha explorada pelo TeamPCP contra o TanStack algumas semanas antes, quando uma proveniência forjada, mas válida, permitiu que pacotes maliciosos passassem por uma verificação ingênua. O caso também ecoa o roubo de tokens no executor visto no comprometimento do GitHub Action do Trivy. Verificar a proveniência é necessário, mas, por si só, não basta.

Análise do impacto

Os números de downloads diretos subestimam a exposição real. Esses pacotes são dependências de build de um console corporativo, então a maioria das instalações ocorre em estações de trabalho de desenvolvedores e executores de CI — justamente os ambientes com mais credenciais de nuvem de longa duração, tokens de registro e PATs do GitHub. O comportamento de worm agrava o risco: um único desenvolvedor que instale uma versão afetada e tenha permissão para publicar outros pacotes pode dar início à próxima onda.

Você pode ter sido afetado se, desde a primeira publicação maliciosa em 1º de junho de 2026, ocorreu alguma das situações a seguir:

• Um npm install / npm ci que resolveu uma versão afetada de @redhat-cloud-services em uma estação de trabalho ou executor de CI.

• Um build em um ambiente de nuvem cujo executor tivesse identidades do GCP, da AWS ou do Azure, considerando os novos coletores de identidade na nuvem.

A exploração não exige nenhuma configuração especial da sua parte. O hook preinstall é executado por padrão. O único requisito é ter instalado uma versão afetada.

Detecção

1. Encontre versões afetadas nos arquivos de lock. Pesquise o namespace em package-lock.json / pnpm-lock.yaml / yarn.lock:

1grep -r "@redhat-cloud-services" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

Compare as versões resolvidas com os alertas da Snyk listados na seção Referências. O alerta principal da Snyk sinaliza @redhat-cloud-services/frontend-components nas versões <=7.7.2; os limites variam por pacote, então verifique cada alerta.

2. Faça uma varredura com a Snyk. O banco de dados da Snyk já inclui alertas para as versões maliciosas, então um teste padrão vai sinalizá-las:

1snyk test --file=package-lock.json

Para as organizações, descobrir ativos e priorizar os riscos ajuda a encontrar todos os projetos e executores que usaram uma versão afetada e, em seguida, ordenar a correção de acordo com o nível real de exposição de credenciais em cada ambiente, em vez de tentar rastrear todas as instalações.

3. Procure indícios de comprometimento. Mesmo depois de remover o pacote, a carga maliciosa pode ter sido executada. Procure por:

• Repositórios novos e inesperados na sua organização do GitHub, especialmente os que tenham a descrição Miasma: The Spreading Blight.

• Workflows desconhecidos do GitHub Actions, principalmente os mínimos que solicitam id-token: write e são acionados quando há envio para qualquer branch.

• Tokens de acesso pessoal, chaves de implantação ou tokens npm criados recentemente que você não criou.

• Acessos anômalos aos metadados de identidade do GCP e do Azure a partir de executores de build.

Correção

A ordem das etapas é importante. Como essa família de malware é conhecida por instalar mecanismos de persistência e, em algumas variantes, gatilhos destrutivos, limpe o host antes de começar a revogar os tokens que ela está monitorando.

1. Pare de instalar as versões maliciosas. Fixe ou substitua suas dependências por versões confiáveis ou remova temporariamente os pacotes afetados. Em seguida, confirme que o arquivo de lock não resolve mais nenhuma versão sinalizada.

2. Reinstale com scripts desativados. Ao refazer uma árvore de dependências potencialmente afetada, bloqueie os scripts de instalação para impedir que uma versão maliciosa remanescente seja acionada novamente:

1rm -rf node_modules
2npm install --ignore-scripts

Você pode definir isso como padrão para um ambiente:

1npm config set ignore-scripts true

(Reative seletivamente para os pacotes que realmente precisem de etapas de build.)

3. Remova os mecanismos de persistência. Audite e limpe quaisquer hooks instalados pelo atacante antes de mexer nas credenciais: configurações de editores e agentes, como .claude/settings.json e .vscode/tasks.json.

4. Altere tudo o que podia ser acessado. Considere exposto todo segredo que uma máquina afetada pudesse acessar e altere-os por ordem de prioridade: tokens npm, PATs do GitHub e chaves SSH e, depois, credenciais de nuvem. Considerando os novos coletores, dê atenção especial às identidades de nuvem como GCP, AWS e Azure, incluindo quaisquer funções que um executor de CI pudesse assumir, não apenas chaves estáticas.

5. Limpe o GitHub. Exclua repositórios e workflows não autorizados, revise as execuções recentes do Actions em busca do padrão de publicação via OIDC descrito acima e confirme que nenhum pacote inesperado foi publicado nas suas contas.

6. Reforce o pipeline. Daqui em diante: exija revisão em branches protegidas para impedir que commits órfãos publiquem pacotes; limite a confiança do OIDC a branches e workflows específicos, em vez de repositórios inteiros; exija autenticação de dois fatores com proteção de publicação no npm; e combine a verificação de proveniência com verificações comportamentais, em vez de confiar apenas nos atestados. A lista de permissões de dependências, a geração de SBOM e um período de espera após a publicação antes de adotar novas versões ajudam a reduzir a janela explorada por esse tipo de ataque. As 10 práticas recomendadas de segurança para npm e as 8 dicas para proteger seu pipeline de CI/CD da Snyk abordam o restante.

Cronologia

• 1º de junho de 2026: Versões maliciosas publicadas no namespace @redhat-cloud-services durante a primeira onda.

• 1º de junho de 2026 (por volta de 13h UTC): Comprometimento divulgado publicamente; a maioria das versões maliciosas foi revogada, mas duas ainda estavam disponíveis.

• 1º de junho de 2026 (por volta de 14h UTC): Causa raiz divulgada: conta de funcionário comprometida e pacotes publicados via OIDC com proveniência SLSA válida.

• 1º de junho de 2026 (por volta de 14h20–15h UTC): Segunda onda de commits maliciosos identificada e incluída na cobertura, junto com detalhes da carga maliciosa sobre os novos coletores de identidade do GCP/Azure.

• 2 de junho de 2026: Novas versões comprometidas descobertas foram adicionadas aos pacotes existentes.

• Em andamento: Os alertas da Snyk para os pacotes afetados estão disponíveis. A investigação continua.