Malware Miasma compromete 32 pacotes npm da Red Hat e rouba credenciais de desenvolvedores

O que aconteceu com os pacotes npm da Red Hat

32 pacotes oficiais foram infectados sem que os desenvolvedores percebessem

Em 1 de junho de 2026, pesquisadores das empresas Aikido Security e OX Security identificaram que pelo menos 32 pacotes do namespace oficial @redhat-cloud-services no registro npm continham codigo malicioso. No total, 96 versoes diferentes foram comprometidas. Esses pacotes somavam cerca de 117.000 downloads semanais, o que significa que a janela de exposicao pode ter afetado dezenas de milhares de ambientes de desenvolvimento ao redor do mundo. A Red Hat confirmou o incidente, removeu os pacotes e afirmou que nao identificou impacto em sistemas de clientes ou em producao interna.

O que e o ataque Miasma e de onde veio

Uma variante do worm Mini Shai-Hulud com capacidade de auto-propagacao

O malware inserido nos pacotes e uma variante do worm Mini Shai-Hulud, batizada pelos pesquisadores de "Miasma: The Spreading Blight". A campanha foi atribuida ao grupo TeamPCP, que chegou a disponibilizar o framework do ataque como codigo aberto, o que amplia consideravelmente o risco de campanhas similares por outros agentes de ameaca. O worm nao apenas rouba dados: ele e projetado para se auto-propagar para repositorios downstream, infectando projetos que dependem dos pacotes comprometidos.

Como o malware entrou nos pacotes oficiais

O pipeline de CI/CD foi sequestrado, nao uma conta individual do npm

O vetor de entrada foi a comprometacao de uma conta GitHub de um funcionario da Red Hat. Com esse acesso, os atacantes injetaram commits orfaos maliciosos em dois repositorios do namespace RedHatInsights, contornando o processo de revisao de codigo. A publicacao dos pacotes infectados foi feita atraves de tokens OIDC do GitHub Actions, o que significa que o proprio pipeline de integracao continua foi sequestrado. Cada pacote comprometido continha um hook de pre-instalacao em package.json que executava automaticamente um payload ofuscado de 4,2 MB com multiplas camadas de descriptografia (arrays numericos, transformacoes ROT e blocos AES-128-GCM).

O que o Miasma rouba da sua maquina

Uma varredura agressiva por qualquer credencial acessivel ao desenvolvedor

O worm realiza uma varredura sistemica pela maquina do desenvolvedor e por servicos conectados. Na categoria de CI/CD, captura GITHUB_TOKEN e ACTIONS_RUNTIME_TOKEN. Em cloud, vai atras de credenciais da GCP, Azure e AWS, incluindo chaves e tokens temporarios. Na infraestrutura, busca tokens Vault, contas Kubernetes e arquivos kubeconfig. No ambiente de desenvolvimento, rouba chaves SSH, tokens npm e PyPI, chaves GPG e arquivos .env. Em gerenciadores de segredo, tenta acessar AWS Secrets Manager, Azure Key Vault e GCP Secret Manager. Os dados sao exfiltrados para repositorios GitHub publicos criados pelo atacante sob a conta da propria vitima, com a descricao "Miasma: The Spreading Blight".

Como o malware se esconde e persiste

O trafego malicioso se mistura com chamadas legitimas de ferramentas de IA

O Miasma usa duas tecnicas principais de camuflagem. Primeiro, o trafego de exfiltracao e disfarado como chamadas a api.anthropic.com:443/v1/api, misturando-se ao trafego normal de equipes que utilizam servicos de IA. Segundo, o malware verifica a presenca de solucoes de seguranca como CrowdStrike, SentinelOne e Carbon Black antes de executar, e evita sistemas configurados em russo. Para persistencia, injeta hooks em ferramentas de IA para desenvolvedores, incluindo Claude Code, Codex, Gemini e GitHub Copilot, alem de criar tarefas no VS Code que re-executam o codigo malicioso ao abrir qualquer projeto. No Linux, instala um servico chamado kitty-monitor.service; no macOS, um plist com.user.kitty-monitor.plist.

Quais outras organizacoes ja foram afetadas

A mesma familia de malwares ja comprometeu Bitwarden, SAP, OpenAI e outros

O incidente com a Red Hat nao foi isolado. A mesma familia de malwares ja foi encontrada em pacotes mantidos por organizacoes como Bitwarden, SAP, Mistral, TanStack, OpenAI e o proprio GitHub. Esse padrao indica uma campanha coordenada e persistente contra a cadeia de suprimentos de software, com foco em organizacoes que publicam pacotes muito baixados por desenvolvedores. O framework de ataque open-sourced pelo TeamPCP significa que qualquer ator de ameaca pode replicar a campanha com relativa facilidade.

Como identificar se sua maquina foi comprometida

Verifique esses arquivos e servicos antes de revogar qualquer credencial

Se voce ou sua equipe instalou qualquer versao dos pacotes @redhat-cloud-services a partir de 1 de junho de 2026, verifique a presenca desses indicadores antes de tomar qualquer acao: no Linux, cheque a existencia do servico kitty-monitor.service com systemctl status kitty-monitor.service; no macOS, verifique o plist em ~/Library/LaunchAgents/com.user.kitty-monitor.plist; em qualquer sistema, verifique se ~/.claude/settings.json foi modificado, se .vscode/tasks.json contem tarefas desconhecidas e se .github/workflows/codeql.yml foi alterado. Atencao importante: o malware pode apagar o diretorio home do usuario se um token GitHub for revogado antes de remover a persistencia. Remova a persistencia primeiro, revogue as credenciais depois.

O que fazer se voce instalou os pacotes afetados

Trate todas as credenciais como comprometidas e siga esta ordem de acoes

A primeira acao e isolar as maquinas que executaram npm install com os pacotes afetados, desconectando-as da rede enquanto a investigacao acontece. Em seguida, remova os mecanismos de persistencia descritos na secao anterior antes de qualquer revogacao de credenciais. Somente entao rotacione todas as credenciais de CI/CD, cloud, SSH e npm. Audite artefatos de build criados durante a janela de exposicao e revise os repositorios GitHub da organizacao para commits nao autorizados, especialmente via GraphQL. A analise foi conduzida em conjunto por Aikido Security, JFrog, Microsoft, OX Security, Socket, StepSecurity e Wiz.

Como se proteger de ataques a cadeia de suprimentos npm

Auditoria de dependencias e monitoramento de hooks sao o primeiro passo

Algumas praticas reduzem significativamente a superficie de ataque. Audite periodicamente os scripts de pre e pos-instalacao dos seus pacotes com npm install --ignore-scripts seguido de uma revisao manual. Use ferramentas como socket.dev ou similares para monitorar comportamentos suspeitos em novas versoes de dependencias. Adote lockfiles rigorosos (package-lock.json ou yarn.lock) e configure alertas para atualizacoes automaticas de versao. Em pipelines de CI/CD, use tokens com o menor privilegio possivel e com escopo restrito por repositorio. Por fim, considere ambientes de build isolados que nao tenham acesso a credenciais de producao.

O que esse incidente revela sobre a seguranca do ecossistema

Quando ate organizacoes de grande porte sao comprometidas, nenhum pacote e automaticamente confiavel

O ataque Miasma deixa uma licao dura: a reputacao de uma organizacao nao e garantia de seguranca dos seus pacotes. A Red Hat, a Bitwarden, a SAP e a OpenAI sao nomes respeitados, e ainda assim tiveram pacotes comprometidos pela mesma familia de malwares. O ponto de falha nao foi o codigo em si, mas o processo humano ao redor dele: uma conta GitHub comprometida foi suficiente para sequestrar um pipeline inteiro. Para desenvolvedores e times de seguranca, a mensagem e clara: dependencias devem ser tratadas como codigo externo nao confiavel, auditado antes de cada nova versao que entra no seu projeto.