O Miasma Worm não precisa de CVE. Não explora uma vulnerabilidade no código. Ele abusa da infraestrutura de confiança que construímos para nos proteger — e que funciona exatamente como projetada. Na Tech86, acompanhamos em tempo real como sete dias de ataques coordenados transformaram SLSA, Sigstore e credenciais legítimas em vetores de comprometimento em massa. O resultado: mais de 400 artefatos rastreados entre npm e PyPI por pesquisadores de segurança, e zero CVEs atribuídos até o momento.
7 dias, 4 superfícies de entrega simultâneas
O Miasma Worm operou em quatro frentes paralelas entre 1º e 7 de junho de 2026, segundo pesquisadores de segurança que rastrearam o incidente. Cada frente explorou um vetor diferente de confiança — e cada uma passou pelas verificações que deveriam detectá-la.
Em 1º de junho, dezenas de pacotes @redhat-cloud-services no npm foram publicados com scripts preinstall maliciosos. Segundo dados do npm, dezenas de milhares de downloads semanais foram afetados. Os tokens OIDC roubados do GitHub Actions passaram pela verificação de proveniência SLSA via Sigstore, Fulcio e Rekor. Os pacotes passam em npm audit signatures — porque as assinaturas são genuínas.
Em 4 de junho, 57 pacotes npm usaram binding.gyp — compilação nativa que bypassa ferramentas de monitoramento de scripts. Incluindo @vapi-ai/server-sdk, com centenas de milhares de downloads mensais segundo estatísticas do npm. No total, centenas de milhares de downloads mensais afetados, segundo pesquisadores de segurança que rastrearam o incidente.
Em 5 de junho, um commit malicioso no repositório Azure/durabletask no GitHub disparou quando desenvolvedores abriram o repositório em agentes de IA como Claude Code, Gemini CLI, Cursor ou VS Code. Sem npm install. Sem build. Abriu, executou. Segundo reportes de segurança, o GitHub teria desabilitado dezenas de repositórios Microsoft em questão de minutos. A Azure/functions-action saiu do ar, e todo pipeline CI/CD que referenciava Azure/functions-action@v1 quebrou globalmente.
Em 7 de junho, dezenas de wheels PyPI em 19 pacotes usaram .pth startup hooks — uma variante denominada Hades. O código executa em todo startup do interpretador Python, independentemente de qual pacote foi importado.
O que o Miasma rouba — e por que isso não termina
O escopo de exfiltração do Miasma é abrangente: credenciais AWS, Azure, GCP, Kubernetes, HashiCorp Vault, GitHub, npm, chaves SSH e dados de browser. Segundo pesquisadores de segurança que rastrearam o incidente, o código fonte do toolkit foi publicado como código aberto em 9 de junho — o que significa que campanhas derivadas são praticamente garantidas.
Um detalhe que ilustra a gravidade: a mesma conta de contribuidor comprometida em maio no PyPI (durante o incidente com durabletask) foi usada novamente em junho, segundo reportes de segurança. As credenciais nunca foram completamente rotacionadas. O atacante reutilizou acesso que deveria ter sido revogado.
A infraestrutura de confiança funcionou — e isso é o problema
O aspecto mais perturbador do Miasma Worm é que a infraestrutura de proveniência funcionou exatamente como projetada. O problema é que o atacante usou credenciais legítimas para atestar código malicioso como confiável. Verificação de assinatura não detecta isso porque as assinaturas são genuínas. SLSA confirma que o pacote veio de onde diz que veio — mas não codifica o que estava dentro.
Na Tech86, essa é a lição central que extraímos: proveniência não é segurança. É procedência. Enquanto a indústria tratar atestação de origem como garantia de segurança, atacantes continuarão usando nossa própria infraestrutura de confiança contra nós. O Miasma Worm é a prova operacional disso.
A convergência que ninguém esperava
O Miasma Worm não é um ataque isolado. É a convergência operacional de três padrões que a comunidade de segurança vinha observando separadamente: auto-replicação tipo worm, autonomia de agente e comprometimento de supply chain de software. Até então, cada padrão havia sido documentado de forma independente — um worm experimental, um agente autônomo, vulnerabilidades isoladas em supply chains de software. O Miasma é tudo isso operando em conjunto, em um único ataque em produção, com quatro superfícies de entrega simultâneas.
Essa convergência muda o modelo de ameaça. Não basta proteger o supply chain de software. Não basta monitorar agentes de IA. Não basta auditar pacotes. É preciso proteger os três vetores ao mesmo tempo, porque o próximo Miasma vai operar da mesma forma — e provavelmente com mais superfícies.
O que muda a partir de agora
Na Tech86, a conclusão que tiramos é direta: a defesa perimetral tradicional não alcança ataques que abusam da infraestrutura de confiança. WAF bloqueia tráfego malicioso na borda, mas não intercepta um npm install cujo pacote tem assinatura válida e proveniência SLSA verificada. O Miasma entra com credenciais legítimas e assinaturas genuínas — não pela porta da frente. É por isso que nossa Segurança Ofensiva combina monitoramento de integridade de pipelines, verificação de comportamento de pacotes em produção e caça proativa a vetores de supply chain — porque o ataque de hoje se infiltra onde a infraestrutura confia, não onde o perímetro vigia.
Seu npm audit signatures passa. Seu SLSA verifica. Seu CI/CD confia. E o atacante está dentro.