Miasma Turns npm Packages Into a Supply-Chain Worm

The Miasma campaign reportedly compromised Red Hat-related npm packages, targeting developer credentials, CI/CD systems, and cloud identities for further p

2026-06-01 GIGATAP Team #security
#security-advisory#supply-chain-security#npm

A Supply-Chain Worm Lands in Red Hat’s npm Ecosystem

A newly reported supply-chain attack campaign, tracked as Miasma, compromised multiple @redhat-cloud-services npm packages and embedded credential-stealing malware designed to spread through developer and CI/CD environments.

The immediate risk is not limited to a poisoned package installation. According to reporting and analysis cited by researchers, the malware attempts to harvest credentials, abuse software delivery pipelines, establish persistence on developer systems, and potentially use stolen access to continue contaminating downstream environments.

Source: https://thehackernews.com/2026/06/miasma-supply-chain-attack-compromises.html

What Changed#

Researchers describe Miasma as sharing key characteristics with earlier Mini Shai-Hulud-style supply-chain activity. The malware executes during package installation through an obfuscated preinstall hook and focuses on collecting high-value credentials from developer workstations and build systems.

Reported targets include GitHub Actions secrets, npm tokens, cloud credentials, Kubernetes and Vault material, SSH keys, Git credentials, and other sensitive files commonly found in software development environments.

Several affected packages were published under the @redhat-cloud-services namespace. Evidence cited by multiple security companies suggests the malicious code was introduced after a compromise involving a Red Hat employee GitHub account. Investigators believe malicious orphan commits were pushed into repositories in a way that bypassed normal code review controls.

The attribution picture remains unclear. Researchers note that tools associated with previous Shai-Hulud campaigns were reportedly released publicly, making copycat operations possible and reducing confidence in any early attribution claims.

One operational detail stands out: the malware is not designed merely to steal secrets and leave. Its behavior suggests an attempt to convert stolen credentials into additional supply-chain access, increasing the possibility of downstream compromise.

Why This Security Advisory Matters#

Many supply-chain incidents focus on a single repository, package, or credential set. Miasma appears to be aimed at something larger: the trust relationships that connect developer machines, cloud platforms, source-control systems, and automated build pipelines.

That distinction matters.

A stolen developer credential is already valuable. A stolen credential that can modify repositories, publish packages, alter workflows, or influence release artifacts can become a force multiplier.

Researchers observed behavior intended to interact directly with GitHub environments. The malware reportedly enumerates repositories accessible to compromised tokens and attempts to create workflow-related changes through GitHub APIs. The objective appears to be persistence and further propagation rather than simple data theft.

Another notable evolution is the increased focus on cloud identities. Researchers cited in the reporting observed new collection mechanisms targeting cloud access, including identities associated with major cloud providers.

That represents a meaningful shift in attacker priorities.

Earlier supply-chain campaigns often concentrated on extracting secrets. A campaign that seeks to map and leverage cloud identities is potentially pursuing durable operational access. For security operations teams, that expands the investigation scope beyond source code and package registries into cloud control planes and identity systems.

The campaign also reportedly generates uniquely encrypted payloads for each infection. If confirmed across affected samples, that design choice complicates detection, signature-based tracking, and large-scale incident correlation.

What Security Teams Should Check#

Organizations that installed affected package versions should treat the event as more than a routine dependency cleanup exercise.

Researchers recommend isolating impacted hosts and rotating exposed credentials. That includes GitHub tokens, npm credentials, cloud access keys, CI/CD secrets, SSH material, and any other sensitive assets accessible from the affected environment.

Key areas to review include:

  • GitHub repositories for unexpected commits, workflow changes, or automation modifications.
  • CI/CD systems for suspicious runs, artifacts, and deployment activity.
  • npm publishing activity associated with affected accounts.
  • Cloud identity usage and privilege changes.
  • Build outputs created during the exposure window.
  • Persistence artifacts left in developer tooling and project configuration files.

Particular attention should be paid to developer workstations. Researchers reported mechanisms intended to persist through configuration changes involving development tools and project files.

That creates a practical cleanup challenge. Removing a package from node_modules may eliminate one component of the infection chain without removing everything the malware changed afterward.

Organizations with mature security operations should consider validating whether software releases, container images, packages, or deployment artifacts produced during the exposure period can still be trusted.

In some environments, rebuilding and revalidating artifacts may be faster and safer than attempting to prove they were unaffected.

What Not to Overclaim#

The available reporting supports concern, but several important questions remain unresolved.

The identity of the threat actor has not been established with confidence.

The public reporting also does not demonstrate that every affected installation resulted in successful credential theft or downstream compromise. Exposure and compromise are not the same thing.

Similarly, the presence of propagation logic does not automatically mean large-scale worm activity occurred across all environments. Incident responders should avoid assuming worst-case outcomes without evidence from their own telemetry.

The strongest current conclusion is narrower and more useful: malicious code was introduced into trusted packages, the malware targeted developer and CI/CD environments, and organizations exposed to the affected versions should investigate accordingly.

A Reminder About Open Source Security#

Miasma reinforces a recurring lesson in open source security: code review alone is not sufficient when identity systems fail.

Package integrity, repository protections, artifact verification, credential hygiene, and monitoring of CI/CD environments increasingly determine whether a compromise remains isolated or becomes a supply-chain event.

The campaign’s emphasis on credentials, cloud identities, workflow manipulation, and persistence reflects how modern software ecosystems actually operate. Attackers are targeting the connections between systems, not just the systems themselves.

For defenders, that means patching is only one part of the response. Understanding who can publish, who can sign, who can deploy, and who can modify automation is often where the real containment work begins.