On June 1, 2026, a worm calling itself Miasma began publishing malicious releases under the @redhat-cloud-services npm scope — the namespace behind the frontend components and API clients that power Red Hat's Hybrid Cloud Console. Snyk's security research team identified at least 32 compromised releases across packages including @redhat-cloud-services/frontend-components (versions up to 7.7.2), frontend-components-utilities, frontend-components-notifications, rbac-client, host-inventory-client, compliance-client, and @redhat-cloud-services/types, which together see roughly 80,000 combined weekly downloads. On Snyk's own CVSS v4.0 scoring, the lead advisory came in at 9.3, in the Critical band, and Snyk flagged it as already being actively exploited in the wild. The malicious releases went out in two waves; public disclosure came around 1 PM UTC on June 1, with most versions revoked at that point and two still live, and a second wave carrying GCP and Azure cloud-identity collectors was identified roughly 90 minutes later — with additional compromised versions still surfacing the next day. What makes Miasma worth studying isn't just the payload; it's that every one of those 32 releases carried a cryptographically valid SLSA provenance attestation, because the thing that got compromised wasn't the build pipeline's cryptography — it was a trusted maintainer's identity. That distinction is the whole lesson.
What actually happened in the Miasma attack?
A Red Hat employee's GitHub account was compromised, and the attacker used that access to push malicious commits — including orphan commits — that created a new GitHub Actions workflow. That workflow requested an OIDC token and used it to publish npm packages under the legitimate @redhat-cloud-services scope, with valid provenance attached, because the publishing identity itself was the real, trusted one. Snyk's researchers traced the payload to a preinstall script that ran an obfuscated JavaScript blob using eval() and ROT-style string decoding, executing automatically the moment anyone ran npm install. The malware harvested environment variables, npm publish tokens, SSH keys, GitHub tokens, and CI/CD secrets, and the second wave added collectors specifically targeting GCP and Azure cloud-identity metadata. From there it spread on its own: using the stolen publishing rights, it looked up which other packages that same identity was allowed to release, then pushed itself into every one of them without any further action from the attacker — the difference between a worm and a one-time backdoor. Snyk described Miasma as a lightly reskinned descendant of the Shai-Hulud worm that the group TeamPCP had open-sourced earlier in 2026.
Why did valid SLSA provenance and a recognizable scope not stop this?
Provenance and scope reputation both answer a narrower question than most teams assume they answer. SLSA provenance proves an artifact was built by a specific pipeline from a specific source commit, signed with a specific identity — it says nothing about whether that identity was, at the moment of signing, actually under the control of the person you trust. A scope name like @redhat-cloud-services carries decades of institutional reputation, and consumers routinely treat "it's under a big vendor's namespace" as an implicit security signal, sometimes explicitly excluding well-known scopes from stricter review. Miasma exploited exactly that gap: the attestation was real, the signer was the real Red Hat OIDC pipeline, and the scope was the real scope — because the compromise happened one layer upstream, at the human maintainer's GitHub credentials, before any of the cryptography ran. A verification check that only asks "is this signed by an allow-listed identity" passes every one of these 32 releases. The lesson isn't that provenance is worthless — it's that provenance answers "who built this" and never "should this identity currently be trusted," which is a continuously changing fact that a static allow-list can't capture on its own.
How did the worm's propagation mechanism work?
Once Miasma had a valid publishing token, the attacker was effectively out of the loop for every subsequent step: the payload itself checked which additional packages that token could touch, then rode along into each one, which is how a single stolen credential turned into 32-plus tainted releases in roughly a day. This self-propagation pattern is what separates a worm from a simple malicious-package upload: a typosquat or a single poisoned release requires an attacker to keep manually publishing, but a worm converts one compromised identity into an expanding blast radius with no further attacker action required. Snyk's timeline shows the practical consequence — the second wave, with the GCP/Azure collectors, was identified about 90 minutes after the first disclosure, and by June 2 researchers had already added newly discovered compromised versions to the advisory as they kept finding additional affected releases. Any defense that relies on catching and revoking each malicious version individually is racing a process that, by design, outpaces manual triage.
What should downstream consumers of scoped packages actually check?
Consumers need controls that evaluate package behavior and install-time activity, not just the identity a package claims to come from, because Miasma demonstrates that identity alone was insufficient even when it was genuinely valid. That means flagging install-time script execution — preinstall and postinstall hooks that reach the network, decode obfuscated strings, or read environment variables and credential files — as suspicious behavior independent of which scope published the package. Safeguard's Eagle malware detection is built for exactly this gap: it analyzes package behavior, including obfuscated payloads and credential-harvesting patterns in install scripts, rather than relying solely on the reputation of the publishing scope or organization. On the provenance side, Safeguard's build-provenance signing already routes every signature through sigstore workload identity and the public Rekor transparency log, so any signing event — including one from a newly or unusually used identity — leaves a permanent, independently auditable record instead of a private log entry only the vendor can see. That doesn't stop a compromised-but-legitimate identity from signing in the first place, which is exactly what happened with Miasma, but it narrows the detection window by making every signature checkable against history after the fact. For teams that want to remove upstream scope trust from the equation entirely for their most sensitive dependencies, a curated registry of vetted, continuously rescanned packages avoids depending on any single maintainer's account security in the first place.
What does Miasma change about how teams should think about supply chain trust?
Miasma should push teams to stop treating "recognizable vendor scope" and "valid signature" as terminal signals and start treating them as one input into a continuously reassessed trust decision. The account that gets compromised is nearly always a real, previously trustworthy one — that's what makes credential and OIDC-token compromise effective in the first place — so any control that only checks identity against a static allow-list will pass a worm that has stolen that identity's keys. The practical shift is toward behavioral detection at install time, continuous monitoring for anomalous signing or publishing activity even from known-good identities, and rapid revocation tooling that assumes some fraction of "trusted" releases will eventually turn out not to be. Snyk's swift identification and disclosure of both attack waves within hours is itself evidence of what mitigates worm-style campaigns like this: not preventing every compromise, since credential theft will keep happening, but shrinking the window between publication and detection so a self-propagating payload gets caught before it reaches the packages your build actually pulls in.