Linha do Tempo de uma Campanha em Escala
No dia 1 de junho de 2026, pesquisadores de segurança identificaram um comprometimento massivo na cadeia de suprimentos de software que afetou mais de 30 pacotes npm oficiais da Red Hat. Batizada de “Miasma”, a operação utilizou uma conta GitHub comprometida de um funcionário da Red Hat para injetar código malicioso em pacotes do ecossistema @redhat-cloud-services, acumulando mais de 116 mil downloads semanais. Este incidente não é isolado — ele representa o capítulo mais recente de uma campanha orquestrada que já atingiu Bitwarden, SAP, PyTorch Lightning, Mistral, TanStack e Microsoft desde abril de 2026.
O Que é o Miasma?
Miasma é uma variante do malware Mini Shai-Hulud, originalmente desenvolvido e open-sourced pelo grupo TeamPCP em maio de 2026. O nome “Miasma” (do grego, “miasma” — mancha ou contaminação) foi uma escolha temática do atacante, que trocou as referências originais de Dune por mitologia grega. Os repositórios criados pelos atacantes traziam a descrição “Miasma: The Spreading Blight”.
“Se você instalou qualquer versão comprometida desde 1º de junho de 2026, considere todos os segredos de CI, credenciais de nuvem, chaves SSH e tokens npm como comprometidos — e rotacione-os imediatamente.” — Aikido Security
Mecanismo do Ataque: Trusted Publishing Bypass
A técnica utilizada revela uma sofisticação preocupante. O atacante, tendo comprometido a conta GitHub de um funcionário da Red Hat, realizou os seguintes passos:
- Push de orphan commits — commits órfãos que substituíam o histórico do repositório, pulando completamente o processo de code review.
- Workflow malicioso — cada commit continha um arquivo
ci.yamlque solicitava permissãoid-token: writedo GitHub Actions. - OIDC para npm — o workflow solicitava um token OIDC de curta duração do GitHub e o usava para autenticar diretamente no endpoint de trusted publishing do npm.
- Publicação com provenance — as versões comprometidas eram publicadas com assinaturas SLSA válidas, o que torna a detecção por ferramentas de verificação de integridade muito mais difícil.
# Estrutura do workflow malicioso
name: release
on:
push:
branches: ['*']
jobs:
release:
runs-on: ubuntu-latest
permissions:
id-token: write # Solicita token OIDC
contents: read
steps:
- uses: actions/checkout@v4
- uses: oven-sh/setup-bun@v1
- name: prepare
run: bun run _index.js
env:
OIDC_PACKAGES: "pkg1, pkg2, ..."
O script _index.js era um payload JavaScript de 4.2 MB altamente ofuscado, utilizando eval() e decodificação ROT. Cada infecção recebia um payload criptografado único, tornando IOCs baseados em hash pouco úteis.
O Que o Malware Rouba?
A execução ocorria automaticamente via script preinstall no package.json, antes mesmo de qualquer código legítimo ser executado. O malware realizava uma varredura completa do sistema:
- CI/CD: GitHub Actions secrets (
GITHUB_TOKEN,ACTIONS_RUNTIME_TOKEN) - AWS: Access keys, session tokens, credenciais IMDS
- GCP: Application Default Credentials, service account keys
- Azure: Service principal credentials, managed identity tokens
- Infraestrutura: Tokens HashiCorp Vault, kubeconfig, tokens Kubernetes
- Pacotes: Tokens de publicação npm e PyPI
- Criptografia: Chaves SSH privadas, chaves GPG
- Config: Arquivos
.envem todo o filesystem
Uma novidade nesta variante foi a adição de coletores de identidade na nuvem — o malware agora também enumera e exfiltra todas as identidades (GCP e Azure) acessíveis pela máquina infectada, não apenas credenciais estáticas.
Cronologia da Campanha Mini Shai-Hulud
O ataque Miasma não acontece no vácuo. Ele faz parte de uma campanha de supply chain que já dura mais de um mês:
| Data | Alvo | Vetor |
|---|---|---|
| 22 Abr 2026 | @bitwarden/cli | GitHub Actions workflow envenenado |
| 29 Abr 2026 | Pacotes SAP npm | Token npm vazado em PR malicioso |
| 30 Abr 2026 | PyTorch Lightning (PyPI) | Comprometimento direto |
| 12 Mai 2026 | Mistral, TanStack (160+ pacotes) | OIDC trusted publishing bypass |
| 12 Mai 2026 | TeamPCP publica código-fonte | Open-source do Shai-Hulud |
| 19 Mai 2026 | Microsoft DurableTask npm | Conta GitHub previamente comprometida |
| 1 Jun 2026 | Red Hat (Miasma) | Conta funcionario + OIDC bypass |
Pacotes Afetados (Principais)
Foram identificadas 96 versões comprometidas em 32 pacotes. Entre os mais críticos:
@redhat-cloud-services/chrome(2.3.1, 2.3.2)@redhat-cloud-services/frontend-components(7.7.2, 7.7.3, 7.7.5)@redhat-cloud-services/compliance-client(4.0.3, 4.0.4, 4.0.6)@redhat-cloud-services/topological-inventory-client(3.0.10, 3.0.11, 3.0.13)@redhat-cloud-services/rbac-client(9.0.3, 9.0.4, 9.0.6)@redhat-cloud-services/host-inventory-client(5.0.3, 5.0.4, 5.0.6)
Attribution: TeamPCP ou Copycat?
As TTPs (Táticas, Técnicas e Procedimentos) observadas no Miasma são consistentes com o modus operandi do TeamPCP — especialmente o uso de orphan commits, OIDC trusted publishing e a estrutura dos workflows. No entanto, como o TeamPCP tornou público o código-fonte do Mini Shai-Hulud em meados de maio, não é possível atribuir definitivamente este ataque ao grupo original. Pode ser um copycat utilizando as mesmas ferramentas.
Mitigacoes e Recomendacoes
Se sua equipe utiliza pacotes @redhat-cloud-services ou qualquer dependência do ecossistema Red Hat Hybrid Cloud Console, as seguintes ações são urgentes:
- Auditar versões — verifique se alguma das versões comprometidas está presente em seus lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml).
- Rotacionar credenciais — assuma comprometimento total de secrets de CI/CD, credenciais cloud, chaves SSH e tokens npm/PyPI.
- Revisar atividade GitHub — busque commits suspeitos, tokens recém-criados e execuções de workflow não autorizadas.
- Implementar allowlisting — mantenha listas de dependências aprovadas e utilize ferramentas como Aikido Safe Chain para verificar pacotes antes da instalação.
- Monitorar proveniência SLSA — implemente verificação de assinaturas SLSA em pipelines de CI/CD.
- Restringir trusted publishing — configure limites rigorosos no npm para quais repositórios e ambientes podem publicar usando OIDC.
- SBOM e análise de dependências — gere SBOMs regularmente (CycloneDX/SPDX) e cruze com feeds de inteligência de ameaças.
Contexto Adicional da Semana
Além do Miasma, outras notícias de segurança marcaram os primeiros dias de junho:
- CVE-2026-41089 (CVSS 9.8) — Vulnerabilidade crítica de RCE no Windows Netlogon está sendo explorada ativamente. Atacantes sem autenticação podem executar código remotamente em domain controllers. O patch foi lançado no Patch Tuesday de maio, mas a exploração em massa começou na última semana. O Centro de Cibersegurança da Belgica (CCB) emitiu alerta urgente.
- Instagram + Meta AI — Hackers estão sequestrando contas de alto perfil (incluindo a conta do Obama White House) ao explorar o assistente de suporte baseado em IA da Meta. O ataque requer apenas uma VPN com IP próximo à localização da vitima e uma solicitação para o chatbot alterar o email da conta.
- 1 em cada 10 novos dominios — O relatório da Interisle revelou que 8,5 milhões dos 84,9 milhões de dominios registrados em 2025 foram adicionados a blocklists de segurança. Cinco registradoras respondem por metade desses dominios maliciosos.
- Rust bane codigo gerado por IA — A linguagem Rust proibiu contribuições de código gerado por IA, seguindo o movimento do Zig e de algumas distribuições Linux.
- MITRE doa Caldera para Apache — A plataforma de emulação de adversarios foi transferida para a Apache Software Foundation, tornando-se Apache Caldera.
Conclusao
O ataque Miasma à Red Hat via npm representa um divisor de aguas na segurança da cadeia de suprimentos de software. A combinação de contas GitHub comprometidas com trusted publishing OIDC permite que atacantes publiquem código malicioso com assinaturas SLSA válidas, tornando a detecção extremamente desafiadora para equipes de segurança tradicionais.
Para equipes CSIRT e DevSecOps, a mensagem é clara: a cadeia de suprimentos de software não é mais apenas um risco teorico — é um vetor de ataque ativo e em escala industrial. Ferramentas de monitoramento de dependencias, SBOMs atualizados e políticas rigorosas de trusted publishing deixaram de ser “boas praticas” para se tornarem requisitos minimos de segurança operacional.
Pesquisa e analise: N00TROP1C — NULLTROPIC, 2026. Fontes: Aikido Security, Wiz Research, Snyk, Red Hat Security (RHSB-2026-006), Risky.Biz, BleepingComputer, KrebsOnSecurity, Interisle.

Deixe um comentário