Miasma Worm Hits 32 npm Packages in Red Hat Supply Chain Attack
Security

Miasma Worm Hits 32 npm Packages in Red Hat Supply Chain Attack

By Grzegorz Gikiewicz · · 13 min read
#Supply Chain Security#npm#Red Hat#Malware#Cybersecurity

On June 1, 2026, security researchers uncovered one of the most sophisticated supply chain attacks targeting the JavaScript ecosystem. Thirty-two official npm packages under Red Hat’s @redhat-cloud-services scope were compromised with a self-replicating credential-stealing worm dubbed “Miasma.” This incident represents a dangerous evolution in software supply chain warfare, demonstrating how trusted publishing mechanisms can be weaponized against even the most security-conscious organizations.

TL;DR: Over 30 official Red Hat npm packages were infected with the Miasma worm, a variant of the Mini Shai-Hulud malware, through a compromised GitHub Actions OIDC trusted publisher. The malware steals cloud credentials from AWS, Azure, and GCP, exfiltrates them via encrypted channels, and can self-replicate across downstream packages. If you installed affected versions between June 1-2, 2026, treat all exposed credentials as compromised and rotate them immediately.

How Did Red Hat’s npm Packages Get Compromised?

What Is the Miasma Worm?

The Miasma campaign is a sophisticated supply chain attack that leverages multiple layers of obfuscation and a novel execution chain. Unlike traditional malware that might simply download a payload, Miasma uses a multi-stage loader designed to evade detection:

  • Stage 1: A preinstall hook in package.json executes node index.js automatically during npm install
  • Stage 2: A 4.1 MB JavaScript file wrapped in Caesar cipher encoding
  • Stage 3: AES-128-GCM decryption reveals two payloads—a Bun runtime bootstrapper and the main credential harvester
  • Stage 4: The malware executes under Bun (not Node) to harvest credentials and exfiltrate them

The attack begins when a developer or CI/CD system runs npm install on an affected package. The malicious preinstall script executes before any application code runs, making it completely invisible to developers who never import or use the package.

How Did the Attackers Bypass Red Hat’s Security?

Evidence suggests that a Red Hat employee’s GitHub account was compromised—the patient zero that enabled this entire attack chain. The attacker used this account to push malicious “orphan commits” to two RedHatInsights repositories, bypassing normal code review processes.

What makes this attack particularly concerning is how it abused npm’s Trusted Publishing feature. By compromising the GitHub Actions OIDC token, the attacker could publish malicious package versions with valid SLSA provenance attestations. These tampered packages appeared cryptographically verified and trustworthy, bypassing many supply chain security controls that rely on provenance verification alone.

The first commit containing the signature string “Miasma: The Spreading Blight” appeared on May 29, 2026, suggesting the attackers had been testing or laying groundwork for days before the main attack.

What Credentials Does Miasma Steal?

Which Cloud Providers Are Targeted?

The Miasma worm casts an exceptionally wide net for credentials. Security researchers from Socket, Wiz, Aikido, and Mend have identified targeting for:

  • AWS: Access keys, secret keys, session tokens, and IMDSv2 credentials from EC2/ECS
  • Azure: Service principal credentials, managed identity tokens, and Key Vault secrets
  • GCP: Application default credentials and service account key files
  • HashiCorp Vault: Tokens and authentication material
  • Kubernetes: Service account tokens and kubeconfig files
  • GitHub Actions: OIDC tokens, PATs, and workflow secrets
  • npm and PyPI: Publishing tokens and maintainers’ credentials
  • SSH: Private keys and Git credentials
  • Password managers: Bitwarden and 1Password vault data

One of the most concerning aspects is how this variant represents an evolution from previous Mini Shai-Hulud campaigns. Wiz researchers noted the addition of specialized collectors for GCP and Azure identities, suggesting an increased attacker focus on cloud infrastructure access rather than just credential harvesting.

How Are the Stolen Credentials Exfiltrated?

The Miasma worm uses a sophisticated dual-channel exfiltration strategy:

Primary Channel: Encrypted HTTPS POST to api.anthropic.com:443/v1/api with a custom envelope format that compresses and encrypts stolen data using AES-256-GCM before transmission.

Fallback Channel: If the primary channel fails, the malware uses stolen GitHub tokens to commit encrypted JSON files to repositories the victim can access. These commits carry messages like “IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner:“—a chilling attempt to prevent token revocation by threatening consequences.

Notably, the worm contains no attacker-controlled command-and-control domains. Instead, it abuses legitimate vendor APIs (GitHub, npm, cloud metadata services) using stolen credentials, making network-based detection significantly more challenging.

Can Miasma Self-Replicate Across Packages?

What Makes This Worm Different From Static Malware?

The term “worm” is used deliberately here because Miasma doesn’t just steal credentials—it actively attempts to propagate. The payload includes code that can:

  1. Enumerate packages a stolen npm token has access to publish
  2. Repackage tarballs with the malicious preinstall hook
  3. Sign artifacts through Sigstore for apparent legitimacy
  4. Use npm’s OIDC trusted publishing to push malicious versions without static credentials

This propagation capability transforms Miasma from a credential thief into a potential supply chain contagion. Each compromised maintainer account becomes a beachhead for infecting downstream packages.

The malware also establishes persistence by injecting hooks into developer tools:

  • Modifying ~/.claude/settings.json to add SessionStart hooks for Claude Code
  • Creating .vscode/tasks.json with "runOn": "folderOpen" for automatic execution
  • Injecting workflows into .github/workflows/codeql.yml for CI/CD persistence

What Happens Once a System Is Infected?

Once executed, the Miasma payload performs several concerning actions:

  • Checks for Russian locale and skips execution if detected (a pattern also observed in GlassWorm campaigns)
  • Probes for endpoint protection from CrowdStrike, SentinelOne, Carbon Black, and StepSecurity
  • Attempts privilege escalation by modifying /mnt/runner sudoers file on GitHub Actions runners
  • Establishes background execution as a daemon process on non-CI systems
  • Downloads Bun runtime from GitHub if not present (from legitimate oven-sh/bun releases)

The malware creates a lock file (tmp.0987654321.lock) to prevent duplicate instances and uses __IS_DAEMON environment variable to track background execution, allowing it to continue scanning and exfiltrating even after the initial npm install completes.

Which Red Hat npm Packages Were Affected?

What Are the Specific Compromised Package Versions?

According to advisories from Aikido Security, Socket, and Mend.io, the following package versions were compromised:

@redhat-cloud-services/chrome 2.3.1 @redhat-cloud-services/compliance-client 4.0.3 @redhat-cloud-services/config-manager-client 5.0.4 @redhat-cloud-services/entitlements-client 4.0.11 @redhat-cloud-services/eslint-config-redhat-cloud-services 3.2.1 @redhat-cloud-services/frontend-components 7.7.2 @redhat-cloud-services/frontend-components-advisor-components 3.8.2 @redhat-cloud-services/frontend-components-config 6.11.3 @redhat-cloud-services/frontend-components-config-utilities 4.11.2 @redhat-cloud-services/frontend-components-notifications 6.9.2 @redhat-cloud-services/frontend-components-remediations 4.9.2 @redhat-cloud-services/frontend-components-testing 1.2.1 @redhat-cloud-services/frontend-components-translations 4.4.1 @redhat-cloud-services/frontend-components-utilities 7.4.1 @redhat-cloud-services/hcc-feo-mcp 0.3.1 @redhat-cloud-services/hcc-kessel-mcp 0.3.1 @redhat-cloud-services/hcc-pf-mcp 0.6.1 @redhat-cloud-services/host-inventory-client 5.0.3 @redhat-cloud-services/insights-client 4.0.4 @redhat-cloud-services/integrations-client 6.0.4 @redhat-cloud-services/javascript-clients-shared 2.0.8 @redhat-cloud-services/notifications-client 6.1.4 @redhat-cloud-services/patch-client 4.0.4 @redhat-cloud-services/quickstarts-client 4.0.11 @redhat-cloud-services/rbac-client 9.0.3 @redhat-cloud-services/remediations-client 4.0.4 @redhat-cloud-services/rule-components 4.7.2 @redhat-cloud-services/sources-client 3.0.10 @redhat-cloud-services/tsc-transform-imports 1.2.2 @redhat-cloud-services/types 3.6.1 @redhat-cloud-services/vulnerabilities-client 2.1.8

Red Hat removed these packages from the npm registry within 48 hours of detection, but any versions installed during the exposure window should be considered potentially harmful.

How Can I Check If My Systems Are Affected?

Security researchers recommend several detection methods:

For lockfiles:

# Search package-lock.json for affected packages
grep -E '@redhat-cloud-services/[a-z0-9-]+:' package-lock.json

# Extract versions for comparison
jq -r '.dependencies + .devDependencies | to_entries[]
  | select(.key | startswith("@redhat-cloud-services/"))
  | "(.key)@(.value)"' package.json

For host indicators:

  • Presence of unexpected bun binary under OS temp directory (/tmp/b-/bun on Linux)
  • Files matching /tmp/p*.js pattern
  • Modified ~/.claude/settings.json with suspicious SessionStart hooks
  • Modified .vscode/tasks.json with "runOn": "folderOpen"
  • GitHub repositories with branches named chore/add-codeql-static-analysis
  • Committed results/ directories with encrypted JSON files

For GitHub activity:

  • Search for branches with oidc- prefix not created by your team
  • Look for commits containing Miasma: The Spreading Blight or IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner
  • Audit workflow runs that consumed affected dependencies during the exposure window

What Should I Do If I’m Affected?

Immediate Response Steps

If you’ve installed any of the affected package versions, security experts recommend treating your systems as credential-compromised and taking immediate action:

  1. Isolate affected hosts — Disconnect from networks and preserve logs for forensic analysis
  2. Rotate ALL exposed credentials — This includes AWS keys, Azure service principals, GCP service accounts, GitHub tokens, npm tokens, SSH keys, and any secrets stored in accessed vaults or password managers
  3. Audit GitHub and npm activity — Review for unexpected repositories, branches, or package versions published during the exposure window
  4. Hunt for persistence artifacts — Check for modified configuration files in developer tools and CI/CD systems
  5. Remove malicious package versions — Uninstall affected versions and replace with known-clean predecessors
  6. Invalidate build artifacts — For CI/CD systems, suspend affected workflow runs and invalidate artifacts produced during the exposure window

Long-Term Security Improvements

This incident highlights several important lessons for supply chain security:

  • Provenance is not enough — The malicious packages had valid SLSA provenance attestations because they were published through compromised trusted publishing. Runtime behavior monitoring and package analysis are essential complements to provenance verification.
  • Least privilege matters — Restrict GitHub Actions token permissions and separate build, test, and publishing jobs to limit blast radius. This mirrors lessons from the 6 Windows zero-day exploits incident where overly broad permissions amplified damage.
  • Disable lifecycle scripts by default — Where feasible, install dependencies with --ignore-scripts and allowlist required install scripts for known packages.
  • Monitor for package behavior — Tools like Socket, Aikido, and Wiz can detect suspicious package behaviors including install-time execution, credential harvesting, and encrypted exfiltration.

Why Did This Happen?

The open-sourcing of Mini Shai-Hulud by TeamPCP has fundamentally changed the threat landscape. As Socket researchers noted, “attribution remains unclear” because the publicly available tooling lowers the barrier to entry for any threat actor who wants to conduct similar attacks.

What was once the signature technique of a single group is now a commodity framework that can be adapted and deployed by anyone. This is the same pattern seen in the 6 Windows zero-day exploits incident where widely-used platforms become attractive targets. The Miasma variant specifically replaces Dune-themed references from previous campaigns with Greek mythology, suggesting adaptation rather than direct copying by the original authors.

How Does This Compare to Other Supply Chain Attacks?

Where Does Miasma Rank Among npm Security Incidents?

The Miasma campaign joins a growing list of high-profile npm supply chain attacks:

  • TanStack (February 2026): 14 packages compromised via GitHub Actions OIDC abuse
  • Axios (September 2025): Malicious versions published through maintainer account takeover
  • PyTorch Lightning (December 2025): Dependency confusion attack targeting CI/CD pipelines
  • Mistral AI (January 2026): Package hijacking through GitHub token theft

What makes Miasma particularly concerning is the combination of trusted publishing abuse, sophisticated multi-stage obfuscation, and self-replication capability. The use of Bun instead of Node for payload execution, the EDR evasion checks, and the establishment of persistence in developer tools all represent tactics that exceed what we’ve seen in previous campaigns.

The attack also demonstrates the risks of OIDC trusted publishing when the underlying GitHub account or Actions workflow is compromised. Unlike static npm tokens that can be rotated, OIDC-based publishing doesn’t have a static credential to revoke—once the GitHub account is compromised, the attacker gains persistent publishing capability until the compromise is detected and the account is secured.

What Are the Technical Indicators of Compromise?

Network and IOCs

While Miasma contains no attacker-controlled domains, the following endpoints and patterns are detection opportunities:

  • Encrypted HTTPS to api.anthropic.com:443/v1/api from npm install processes
  • GitHub API writes to /contents/results/ paths during package installation
  • Unexpected requests to npm OIDC token exchange endpoints
  • GitHub GraphQL mutations for createCommitOnBranch
  • Sigstore endpoints (fulcio.sigstore.dev, rekor.sigstore.dev) from non-publishing contexts

File and Process Indicators

  • preinstall scripts executing node index.js
  • 4+ MB JavaScript files in package roots
  • Files matching /tmp/p*.js and /tmp/b-*/bun
  • bun run commands during dependency installation
  • Processes named with __IS_DAEMON environment variable
  • Lock files named tmp.0987654321.lock

Hash Values

Security researchers have published the following SHA-256 hashes for affected artifacts:

  • @redhat-cloud-services/chrome@2.3.1 tarball: 88896d478986d453f5da79b311de39d9b4b1bea95c21af1d8ef181b0f4e52fe9
  • Malicious index.js: 21b6409a7b84446310daca5409ad6112ac60a1e4bef97736e53fff5f63bfdef4
  • Decrypted main payload: 0dc06ecdaa63fe24859cfd955053c23245c536e4733480239d14bebf12688e35

What Is the Miasma Worm?

Miasma is a sophisticated supply chain malware variant that compromised 32 official Red Hat npm packages in June 2026. It’s derived from the Mini Shai-Hulud attack framework and uses multi-stage obfuscation to steal cloud credentials and self-replicate across packages.

How Did Miasma Compromise Red Hat Packages?

Attackers compromised a Red Hat employee’s GitHub account and used it to inject malicious commits into RedHatInsights repositories. By abusing GitHub Actions OIDC trusted publishing, they published malicious npm package versions with valid SLSA provenance attestations.

What Credentials Does Miasma Steal?

Miasma targets AWS, Azure, and GCP cloud credentials; GitHub Actions tokens; npm and PyPI publishing tokens; HashiCorp Vault tokens; Kubernetes service account tokens; SSH private keys; and credentials from password managers like Bitwarden and 1Password.

How Can I Detect Miasma Infection?

Check for affected package versions in lockfiles, look for unexpected bun binaries in temp directories, audit GitHub repositories for suspicious branches and commits, and monitor for encrypted exfiltration to api.anthropic.com during npm install operations.

What Should I Do If I Installed Affected Packages?

Immediately isolate affected systems, rotate all exposed credentials, audit GitHub and npm activity for the exposure window, hunt for persistence artifacts in developer tools, remove malicious package versions, and invalidate any build artifacts produced during the compromise period.

Is Provenance Verification Enough Protection?

No. Miasma packages had valid SLSA provenance because they were published through compromised trusted publishing. Organizations need runtime behavior monitoring and package analysis alongside provenance verification to detect sophisticated supply chain attacks.

What Makes Miasma Different From Previous npm Attacks?

Miasma uses Bun instead of Node for execution, includes EDR evasion checks, establishes persistence in developer tools, and demonstrates sophisticated multi-stage obfuscation. The self-replication capability also makes it a worm rather than static malware.

How Long Was Miasma Active?

The first “Miasma: The Spreading Blight” commits appeared on May 29, 2026. Red Hat removed the compromised packages from npm within 48 hours of detection on June 1, 2026, but any systems that installed affected versions during that window should be considered compromised.

Summary

The Miasma campaign represents a troubling evolution in software supply chain attacks. By compromising a Red Hat employee’s GitHub account and abusing npm’s trusted publishing mechanism, attackers demonstrated that even well-resourced organizations with mature security practices can fall victim to sophisticated supply chain intrusions.

The malware itself—a multi-stage, obfuscated credential harvester that executes under Bun with persistence mechanisms and self-replication capability—shows the level of sophistication now available to threat actors, especially following the open-sourcing of attack frameworks like Mini Shai-Hulud.

For organizations running JavaScript workloads, this incident underscores the importance of:

  • Runtime behavior monitoring alongside provenance verification
  • Least-privilege CI/CD configurations
  • Regular credential rotation and exposure audits
  • Dependency scanning before installation, not just after
  • Incident response plans that account for supply chain compromises

The research community—including Aikido Security, Socket, Wiz, Mend.io, and others—responded quickly to detect and analyze this campaign. But as attack frameworks become more accessible and detection-evasion techniques grow more sophisticated, defenders must assume that what was once cutting-edge capability will eventually become commodity.

Miasma isn’t the last supply chain attack we’ll see. It’s a sign of what’s coming.