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 código malicioso. No total, 96 versões 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 não identificou impacto em sistemas de clientes ou em produção interna.

O que é 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 atribuída ao grupo TeamPCP, que chegou a disponibilizar o framework do ataque como código aberto, o que amplia consideravelmente o risco de campanhas similares por outros agentes de ameaca. O worm não apenas rouba dados: ele e projetado para se auto-propagar para repositórios downstream, infectando projetos que dependem dos pacotes comprometidos.

Como o malware entrou nos pacotes oficiais

O pipeline de CI/CD foi sequestrado, não uma conta individual do npm

O vetor de entrada foi a comprometacao de uma conta GitHub de um funcionário da Red Hat. Com esse acesso, os atacantes injetaram commits orfaos maliciosos em dois repositórios do namespace RedHatInsights, contornando o processo de revisao de código. A publicação dos pacotes infectados foi feita atraves de tokens OIDC do GitHub Actions, o que significa que o próprio pipeline de integração contínua foi sequestrado. Cada pacote comprometido continha um hook de pre-instalação em package.json que executava automaticamente um payload ofuscado de 4,2 MB com múltiplas camadas de descriptografia (arrays numéricos, transformacoes ROT e blocos AES-128-GCM).

O que o Miasma rouba da sua maquina

Uma varredura agressiva por qualquer credencial acessível ao desenvolvedor

O worm realiza uma varredura sistémica pela maquina do desenvolvedor e por serviços 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 temporários. 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 são exfiltrados para repositórios GitHub públicos criados pelo atacante sob a conta da própria vitima, com a descrição "Miasma: The Spreading Blight".

Como o malware se esconde e persiste

O tráfego malicioso se mistura com chamadas legítimas de ferramentas de IA

O Miasma usa duas técnicas principais de camuflagem. Primeiro, o tráfego de exfiltracao e disfarado como chamadas a api.anthropic.com:443/v1/api, misturando-se ao tráfego normal de equipes que utilizam serviços de IA. Segundo, o malware verifica a presença de soluções de segurança como CrowdStrike, SentinelOne e Carbon Black antes de executar, e evita sistemas configurados em russo. Para persistência, injeta hooks em ferramentas de IA para desenvolvedores, incluindo Claude Code, Códex, Gemini e GitHub Copilot, além de criar tarefas no VS Code que re-executam o código malicioso ao abrir qualquer projeto. No Linux, instala um serviço chamado kitty-monitor.service; no macOS, um plist com.user.kitty-monitor.plist.

Quais outras organizações ja foram afetadas

A mesma família de malwares ja comprometeu Bitwarden, SAP, OpenAI e outros

O incidente com a Red Hat não foi isolado. A mesma família de malwares ja foi encontrada em pacotes mantidos por organizações como Bitwarden, SAP, Mistral, TanStack, OpenAI e o próprio GitHub. Esse padrão indica uma campanha coordenada e persistente contra a cadeia de suprimentos de software, com foco em organizações 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 serviços antes de revogar qualquer credencial

Se você ou sua equipe instalou qualquer versão dos pacotes @redhat-cloud-services a partir de 1 de junho de 2026, verifique a presença desses indicadores antes de tomar qualquer acao: no Linux, cheque a existência do serviço 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. Atenção importante: o malware pode apagar o diretório home do usuário se um token GitHub for revogado antes de remover a persistência. Remova a persistência primeiro, revogue as credenciais depois.

O que fazer se você 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 persistência descritos na secao anterior antes de qualquer revogacao de credenciais. Somente então rotacione todas as credenciais de CI/CD, cloud, SSH e npm. Audite artefatos de build criados durante a janela de exposicao e revise os repositórios GitHub da organização para commits não autorizados, especialmente via GraphQL. A análise 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 dependências e monitoramento de hooks são o primeiro passo

Algumas práticas reduzem significativamente a superfície de ataque. Audite periodicamente os scripts de pre e pos-instalação 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 versões de dependências. Adote lockfiles rigorosos (package-lock.json ou yarn.lock) e configure alertas para atualizações automáticas de versão. Em pipelines de CI/CD, use tokens com o menor privilegio possível e com escopo restrito por repositório. Por fim, considere ambientes de build isolados que não tenham acesso a credenciais de produção.

O que esse incidente revela sobre a segurança do ecossistema

Quando ate organizações de grande porte são comprometidas, nenhum pacote e automaticamente confiável

O ataque Miasma deixa uma licao dura: a reputacao de uma organização não e garantia de segurança dos seus pacotes. A Red Hat, a Bitwarden, a SAP e a OpenAI são nomes respeitados, e ainda assim tiveram pacotes comprometidos pela mesma família de malwares. O ponto de falha não foi o código 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 segurança, a mensagem e clara: dependências devem ser tratadas como código externo não confiável, auditado antes de cada nova versão que entra no seu projeto.