A segurança da cadeia de suprimentos de software sofreu um golpe de proporções alarmantes. No dia 1º de junho de 2026, a empresa de segurança StepSecurity identificou que 32 pacotes npm oficiais gerenciados pela Red Hat, dentro do namespace @redhat-cloud-servicescodecode, foram comprometidos por um malware de roubo de credenciais. Não se trata de um ataque de typosquatting ou de pacotes falsos: são 96 versões legítimas, assinadas digitalmente e distribuídas pelo pipeline oficial de CI/CD da própria Red Hat. Juntas, essas versões acumulavam cerca de 117 mil downloads por semana, expondo um ecossistema inteiro a um risco silencioso e devastador.
O ataque que sequestrou a confiança
O que torna este incidente único é a sofisticação do vetor de entrada. Os invasores não se limitaram a publicar pacotes com nomes semelhantes. Eles comprometeram contas de funcionários da Red Hat no GitHub e, a partir delas, inseriram commits maliciosos diretamente nos repositórios oficiais da organização RedHatInsightscodecode. De posse do acesso, os atacantes abusaram dos tokens OIDC do GitHub Actions para obter credenciais de publicação no npm. O resultado? Pacotes adulterados foram publicados com assinatura SLSA (Supply-chain Levels for Software Artifacts) válida — o selo de integridade que deveria justamente atestar que o código veio de uma fonte confiável e não foi violado.
Nome, canal de distribuição, assinatura digital: todos os indicadores que um desenvolvedor usa para confiar em um pacote apontavam que aquele código era seguro. Era, na verdade, a isca perfeita.
O malware Miasma e a campanha Shai-Hulud
O malware embutido nos pacotes da Red Hat foi batizado de Miasma: The Spreading Blight e é considerado uma subvariante do worm Shai-Hulud, uma ameaça que assola o registro npm desde setembro de 2025. A campanha Shai-Hulud, conduzida pelo grupo de ataque TeamPCP, já havia escalado de forma consistente: cerca de 200 pacotes na primeira onda, 800 na segunda, e avançou para comprometer alvos de alto perfil como Axios (março de 2026, via contas sequestradas pelo grupo norte-coreano Sapphire Sleet), Bitwarden e SAP (abril), e TanStack, Mistral AI e OpenAI (maio).
O ponto de inflexão veio em 12 de maio de 2026, quando o TeamPCP tornou público o código-fonte do Shai-Hulud em um repositório Git e abriu um concurso no BreachForums com prêmio de 1000 dólares para quem executasse o maior ataque à cadeia de suprimentos. Com o código agora aberto, o ataque à Red Hat — ocorrido em 1º de junho — pode ter sido obra do grupo original ou de imitadores. A mecânica, porém, é a mesma: sequestrar a infraestrutura de CI/CD legítima e transformar a própria confiança em arma.
O payload de 4,2 MB e a coleta de credenciais
A porta de entrada do malware é um gancho preinstallcodecode inserido no package.jsoncodecode. No momento em que um desenvolvedor executa npm installcodecode, antes mesmo de qualquer código de aplicação ser carregado, um payload ofuscado de 4,2 MB é ativado. Um arquivo desse tamanho em uma biblioteca típica já é um forte sinal de anomalia, mas pipelines automatizados dificilmente param para inspecionar esse tipo de métrica.
O payload passa por três camadas de ofuscação, baixa um runtime Bun e executa o corpo principal do malware. A coleta de dados é abrangente e cirúrgica:
| Alvo | Dados coletados |
|---|---|
| GitHub Actions | Tokens, runtime tokens, tokens de requisição OIDC, tokens npm |
| AWS | Access keys, secret keys, session tokens, arquivos de credenciais |
| GCP | Credenciais padrão, chaves de service account |
| Azure | Tokens de service principal, tokens Managed ID |
| Kubernetes | Tokens de service account, arquivos kubeconfig |
| HashiCorp Vault | Tokens Vault, endereço Vault |
| npm / PyPI | Tokens de publicação (.npmrc, .pypirc) |
| SSH | Chaves privadas (RSA, Ed25519 etc.) |
| Docker | Credenciais de registro (config.json) |
| GPG | Anéis de chave (.gnupg/) |
| Variáveis de ambiente | Arquivos .env no sistema de arquivos |
Uma das técnicas mais engenhosas do malware é a leitura direta da memória do processo Runner.Workercodecode do GitHub Actions, acessando /proc/<pid>/memcodecode para extrair secrets que teoricamente estariam mascarados nos logs, mas que na memória do processo aparecem em texto puro.
Um worm que se auto-replica
A característica mais preocupante do Miasma é sua capacidade de auto-propagação. De posse dos tokens npm roubados, o malware publica novas versões com backdoor em outros pacotes aos quais a vítima tenha permissão de publicação. Como os tokens npm podem estar configurados com autenticação de dois fatores bypassada (via tokens de granularidade fina), até contas com 2FA ativo são vulneráveis. Basta um desenvolvedor ser infectado para que todos os pacotes sob sua responsabilidade se tornem novas fontes de infecção — sem qualquer ação adicional do atacante.
Além disso, o malware usa o GITHUB_TOKENcodecode roubado para fazer data exfiltration via GitHub Contents API, cometendo dados codificados em base64 diretamente nos repositórios da vítima. Como api.github.comcodecode raramente é bloqueado por políticas de rede em ambientes de CI, essa comunicação se camufla como tráfego legítimo de git.
Persistência nas ferramentas do dia a dia
Remover os pacotes comprometidos não encerra o ataque. O malware também injeta hooks no arquivo de configuração do Claude Code (~/.claude/settings.jsoncodecode) e no tasks.jsoncodecode do VS Code (.vscode/tasks.jsoncodecode). No caso do Claude Code, um hook SessionStartcodecode é adicionado, fazendo com que o código malicioso seja executado toda vez que o assistente é iniciado. No VS Code, um trigger folderOpencodecode dispara o código sempre que o desenvolvedor abre a pasta do projeto. Esses arquivos de configuração raramente são varridos por ferramentas de segurança, e a simples desinstalação do pacote npm não os remove.
Os sinais estavam lá
Dados da empresa de monitoramento de dark web WhiteIntel indicam que credenciais e cookies de sessão do GitHub de funcionários da Red Hat já haviam aparecido em logs de infostealers em 13 de abril e 15 de maio de 2026. O intervalo entre o vazamento e o uso efetivo no ataque foi de menos de 48 horas — tempo insuficiente para que equipes de segurança concluíssem revisões semanais. Esse gap de reação é um dos fatores que tornam a cadeia de suprimentos tão vulnerável.
A resposta da Red Hat
A Red Hat publicou o boletim de segurança RHSB-2026-006 e removeu as versões comprometidas do registro npm. A empresa afirma que os pacotes afetados são bibliotecas front-end e que, até o momento da investigação, nenhuma versão contaminada foi incluída em produtos finais da companhia, graças ao versionamento fixo utilizado nos builds. O ataque ocorreu em duas ondas: a primeira entre 10:53 e 10:53 UTC, e a segunda entre 13:44 e 13:46 UTC. A maior parte das versões maliciosas foi retirada no mesmo dia.
Para quem instalou as versões comprometidas, a recomendação é tratar todos os tokens e credenciais de GitHub, npm e nuvem como comprometidos e realizar a rotação imediata. Contudo, como o malware possui um mecanismo de “dead man’s switch” que pode executar ações destrutivas ao detectar a revogação de tokens, especialistas sugerem isolar e preservar a imagem do ambiente antes de qualquer rotação.
O modelo de confiança do npm está em xeque
A sequência de ataques em 2026 — Axios em março, Bitwarden e SAP em abril, TanStack, Mistral AI e OpenAI em maio, e agora Red Hat em junho — revela um padrão inquietante. Não são mais ataques de typosquatting ou dependência confusa, que um desenvolvedor experiente consegue detectar com ferramentas básicas. São contas legítimas, pipelines legítimos, assinaturas legítimas. A própria infraestrutura de confiança — nomes, downloads, SLSA — foi virada contra os desenvolvedores.
O que o caso da Red Hat demonstra é que confiar em um pacote porque ele é oficial, assinado e amplamente baixado já não é suficiente. O código-fonte do Shai-Hulud está disponível publicamente. Qualquer grupo com acesso a credenciais roubadas pode replicar o ataque. O ecossistema npm, construído sobre a premissa de que a identidade e a reputação são garantias, agora enfrenta um momento em que ambas podem ser sequestradas em horas.
Para o desenvolvedor brasileiro, a lição é prática: nenhum pacote, por mais oficial que pareça, está imune a uma injeção hostil via CI/CD. A única defesa real no curto prazo é a combinação de monitoramento contínuo de dependências, rotação frequente de credenciais e, principalmente, a desconfiação ativa — questionar até mesmo o que vem assinado com o selo de segurança mais confiável.
Leia também
- Mais de 5500 repositórios GitHub com backdoor: o ataque Megalodon
- Quando ferramentas de segurança se tornam armas: o caso Trivy e Axios
- Vazamento de 3800 repositórios internos do GitHub: a rota descoberta
- Alerta da Microsoft: contaminação do PyPI mistralai com armadilha de exclusão
- 416 pacotes npm infectados por worm, incluindo TanStack
- Aplicativo macOS da OpenAI visado pela Coreia do Norte
- Axios invadido via reunião falsa: o método dos hackers norte-coreanos
