Miasma Shows the Hard Limit of Provenance in the Software Supply Chain

A newly disclosed software supply chain incident has placed dozens of npm packages under the @redhat-cloud-services namespace at the center of an active credential-stealing and self-propagating campaign.

According to Snyk’s investigation, malicious code was discovered in at least 32 package releases used by components and tooling associated with the Red Hat Hybrid Cloud Console. The payload executes during package installation, harvests credentials from developer and CI environments, and attempts to spread by publishing malicious updates to other packages accessible to the compromised identity.

The campaign has been named Miasma. Researchers describe it as a modified descendant of the earlier (Mini) Shai-Hulud worm.

Source: https://snyk.io/blog/miasma-supply-chain-attack-malicious-code-redhat-cloud-services-npm-packages/

What Changed#

The immediate issue is not a typo-squatted package or a poisoned dependency hidden deep in a transitive tree.

Evidence cited by Snyk indicates that a Red Hat employee GitHub account was compromised. The attacker allegedly used that access to push unauthorized orphan commits into legitimate repositories and introduce a minimal GitHub Actions workflow that requested an OIDC token and published packages to npm.

That distinction matters.

The resulting packages were published from legitimate repositories and carried valid SLSA provenance attestations. In other words, the build system accurately reported where the artifacts came from. What it could not determine was whether the workflow that produced those artifacts had been authorized.

This turns the incident into more than another npm compromise. It highlights a failure mode that many software supply chain discussions gloss over: trusted publishing infrastructure can faithfully attest to a malicious release if the attacker gains control of the trusted publishing context.

The malicious releases reportedly appeared in two publication waves on June 1, 2026. Most affected versions were revoked within hours of disclosure, although analysis was still ongoing when the findings were published.

Why It Matters#

The reported download volume is significant, but the operational exposure is potentially larger than download counts suggest.

Many of the affected packages are build-time dependencies used by developer workstations and CI runners. Those systems often contain exactly the assets attackers want: cloud credentials, package registry tokens, GitHub tokens, SSH keys, and deployment secrets.

The payload reportedly executes through an install-time hook. Because npm automatically runs lifecycle scripts during installation, exposure can occur before application code ever runs.

Researchers state that the malware harvests local credentials, enumerates cloud identities, and attempts to discover other packages the compromised identity can publish. That last capability is what transforms a package compromise into a worm.

The newer behavior appears particularly focused on cloud access. Earlier variants emphasized credential theft. Miasma reportedly adds collectors intended to enumerate available cloud identities and reachable control-plane access paths.

From a security operations perspective, that is an escalation in ambition. The objective is not merely collecting secrets but mapping what authority an infected environment can exercise.

The Provenance Problem#

One lesson stands out from the available evidence.

Provenance verification remains valuable. Organizations should continue verifying build origins, signatures, and attestations. But this incident reinforces that provenance answers a narrower question than many defenders assume.

It can demonstrate that an artifact came from a specific repository and workflow.

It cannot independently establish that the repository state, workflow definition, maintainer account, or publishing action was legitimate.

That distinction has appeared repeatedly across recent supply chain incidents. Attackers increasingly target maintainer access, CI systems, publishing permissions, and identity infrastructure because those paths allow malicious artifacts to inherit legitimate trust signals.

The result is a software supply chain environment where trusted publishing is necessary but insufficient.

Security controls that stop at signature verification may miss attacks that originate from compromised maintainers or compromised automation.

What to Check Now#

Organizations that installed affected releases should treat the event as an incident response problem rather than a routine package update.

Priority checks include:

• Identify whether affected @redhat-cloud-services package versions were installed on developer workstations or CI systems.
• Rebuild dependency inventories to determine where those versions entered the environment.
• Reinstall packages with install scripts disabled where appropriate during investigation.
• Rotate credentials that may have been reachable from affected systems.
• Review npm publishing permissions and maintainer access for packages under your control.
• Audit GitHub Actions workflows that can request OIDC tokens or publish artifacts.
• Search for unusual package publication activity originating from trusted identities.

Teams should also review cloud identity activity, not just static secrets. If the malware successfully enumerated or accessed cloud roles, token rotation alone may not provide a complete picture of exposure.

What Not to Overclaim#

Several important facts remain under investigation.

Public reporting currently points to a compromised GitHub account and unauthorized workflow activity, but the full intrusion path has not been established. The ultimate scope of downstream propagation is also unclear.

It is likewise too early to treat every package consumer as compromised. Installation of an affected version, execution context, available permissions, and accessible credentials all influence actual impact.

What is already clear is that this was not a conventional package registry attack. The trust chain itself appears to have been used as the delivery mechanism.

That makes Miasma relevant beyond the affected namespace. The incident is another reminder that open source security depends on more than artifact integrity. Maintainer access, identity controls, workflow governance, and operational monitoring remain part of the same trust boundary.

For defenders focused on software supply chain risk, that is the signal worth paying attention to.