Miasma: How a Stolen Red Hat Account Turned npm Provenance Into a Trojan Horse

The Attack That Made Trust Signals Untrustworthy

Software supply chain security has spent the last three years building toward a single North Star: provenance. If you can cryptographically prove that a package was built from a known repository, by a known workflow, at a known time — you should be safe. The Miasma worm, which detonated across the @redhat-cloud-services npm namespace on June 1, 2026, dismantled that assumption in a single afternoon.

By compromising a Red Hat employee’s GitHub account and weaponizing the very OIDC trusted-publishing pipeline designed to eliminate long-lived secrets, attackers published 96 malicious package versions — all bearing valid SLSA provenance signatures. The packages had real download numbers, a trusted namespace, and cryptographic attestations from Sigstore. To any automated security scanner, they looked completely clean.

The incident is not just a Red Hat problem. It is a proof-of-concept that the supply-chain trust architecture the industry has converged on — OIDC short-lived tokens, SLSA provenance, Sigstore attestations — can be turned against itself the moment a single human account is compromised.

How Miasma Weaponized Trust Signals

1. Account hijacking via spearphishing

Aikido Security’s analysis of the June 1 incident shows that a specific Red Hat employee GitHub account was compromised, allowing attackers to push malicious orphan commits directly to three repositories — RedHatInsights/frontend-components, RedHatInsights/javascript-clients, and RedHatInsights/platform-frontend-ai-toolkit — bypassing code review entirely. The account takeover enabled two waves of malicious publishes: one at 10:53 AM UTC and a second at 1:44 PM UTC, both on June 1, 2026.

The initial access vector was not a zero-day in GitHub or npm. It was a human. Spearphishing a single developer with repository write access is enough to unlock the entire CI/CD trust chain — because modern pipelines are designed to trust the identity of whoever pushes the commit.

Miasma did not appear from nowhere. Wiz Research traced the attack lineage to a broader campaign that hit Bitwarden CLI on April 22, four SAP packages on April 29, PyTorch Lightning on April 30, and Microsoft’s DurableTask package on May 19. By May 12, the underlying toolkit — dubbed “Mini Shai-Hulud” by the threat actor group TeamPCP — had been openly published as source code, enabling independent actors to adapt it. Miasma is one such adaptation, replacing the original Dune mythology references with Greek mythology, and adding new credential collectors targeting GCP and Azure identities.

2. GitHub Actions OIDC abuse to generate trusted attestations

The critical abuse was not brute force — it was elegance. Microsoft’s security blog documents that once inside the Red Hat repositories, attackers created a ci.yaml GitHub Actions workflow with id-token: write permissions — the standard configuration for trusted publishing. This workflow triggered “on push to any branch,” executed an obfuscated _index.js payload, and then requested a short-lived OIDC identity token from GitHub’s token service. That token was exchanged with npm’s trusted publishing endpoint to publish packages under the @redhat-cloud-services scope with valid SLSA provenance attestations generated via Sigstore’s Fulcio and Rekor services.

From the perspective of npm’s package registry, the publish was indistinguishable from a legitimate Red Hat CI/CD run. The attestation chain was intact. The namespace was correct. The workflow ID matched. SLSA provenance, which the security community has marketed as the antidote to supply chain attacks, became the mechanism that made the malicious packages more convincing — not less.

Crucially, Miasma generated a uniquely encrypted payload for each infection, bypassing hash-based detection rules that security tools typically use to flag known-bad package versions.

3. Preinstall script for credential sweep

The malicious package included a preinstall hook — "preinstall": "node index.js" — that fires automatically during npm install, before a developer has any opportunity to inspect what they installed. The dropper weighed 4.2 MB and used layered obfuscation: a large character-code array reconstructed at runtime, decoded through a ROT-based Caesar cipher transformation, then dynamically executed via eval(). Subsequent stages added AES-128-GCM encryption and Obfuscator.io string-array protection, ultimately executing a Bun-based payload.

The credential harvest was comprehensive. According to Microsoft’s detailed technical breakdown, the malware targeted: GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN; AWS IAM credentials and Secrets Manager; Azure IMDS OAuth2 tokens and Key Vault access; GCP service-account tokens; HashiCorp Vault tokens; Kubernetes service account credentials; npm and PyPI tokens; SSH keys; Docker credentials; GPG keys; .env files; and browser-stored credentials. Any developer or CI runner that executed npm install on an affected version potentially exfiltrated credentials across every cloud they had access to.

What Security Teams Must Do

1. Audit your CI/CD OIDC token scopes now

The id-token: write permission is the keystone of trusted publishing — but it is also the attack surface Miasma exploited. Every GitHub Actions workflow in your organization that carries this permission must be reviewed. The scope should be locked to the minimum required operation: if a workflow publishes to npm, it should not simultaneously have contents: write or packages: write permissions. Enforce branch-protection rules so that workflow files in .github/workflows/ can only be modified by a restricted set of maintainers with mandatory review — not by anyone with push access.

Wiz recommends implementing dependency allowlisting and SBOM generation so that any new package version pulled into a build triggers an alert before it executes. The preinstall hook attack works because npm install is treated as a safe, automated operation — removing that assumption is the first practical control.

2. Treat provenance as a signal, not a guarantee

SLSA provenance and Sigstore attestations tell you how a package was built and from where — they do not tell you whether the account that triggered the build was legitimately controlled by its owner at the time of the build. Miasma’s attestations were cryptographically valid because the build ran on GitHub’s infrastructure using a legitimate (if hijacked) account.

The industry needs to layer additional signals on top of provenance: behavioral anomaly detection (a workflow that has never published before suddenly publishing 32 package versions in two bursts is an anomaly), account-level risk scoring (was the GitHub account recently accessed from an unusual location?), and time-bounded trust (a provenance attestation for a package version published 12 hours after the last legitimate version should trigger human review, not automatic installation). Provenance is a necessary condition for trust — not a sufficient one.

3. Enforce preinstall script review in your npm policy

The --ignore-scripts flag to npm install prevents preinstall and postinstall hooks from executing. For production CI pipelines that do not need lifecycle scripts, this flag should be a non-negotiable default. Microsoft explicitly recommended this in its Miasma remediation guidance. In enterprise environments, npm package policies should flag any package that newly introduces a preinstall script in an updated version — a pattern that has no benign use case in most production dependencies.

For teams already running affected versions, Microsoft advises rotating all exposed credentials immediately: GitHub tokens, cloud IAM credentials (AWS, GCP, Azure), SSH keys, npm and PyPI tokens, Kubernetes service accounts, and HashiCorp Vault tokens. The exfiltration happens silently at install time — assume that any system that ran an affected version is fully compromised until credential rotation is complete.

The Trust Paradox: When Provenance Becomes a Weapon

Miasma is the clearest demonstration yet that supply chain security’s current architecture has a single-point-of-failure: human accounts. OIDC trusted publishing was designed to eliminate the risk of stolen long-lived npm tokens — and it succeeded. Miasma did not need a long-lived token. It needed one compromised developer account and fifteen minutes of GitHub Actions runtime.

The broader attack campaign behind Miasma — spanning Bitwarden, SAP, PyTorch, and Microsoft’s DurableTask package over the six weeks preceding the Red Hat incident — shows that this is not opportunistic. Threat actors are systematically probing the trusted publishing infrastructure of major ecosystems, learning which packages have the highest downstream amplification (116,991 weekly downloads for the Red Hat scope alone), and timing compromises to hit pipelines before maintainers notice.

The policy response needs to catch up. SLSA Level 3 provenance provides strong guarantees about build infrastructure — but it says nothing about account hygiene. The next frontier is SLSA Level 4: hermetic, reproducible builds that decouple the artifact from any specific human account entirely. Until that becomes mainstream, provenance is a signal that sophisticated attackers have learned to forge by going one layer higher up the trust chain. Security teams that treat a green provenance badge as a cleared package are operating on an assumption Miasma has now invalidated.

Frequently Asked Questions

Sources & Further Reading

• Miasma Malware Targets npm Packages — The Hacker News
• Preinstall Persistence Inside Red Hat npm: Miasma Credential-Stealing Campaign — Microsoft Security Blog
• Miasma Supply Chain Attack Targeting Red Hat npm Packages — Wiz
• Red Hat npm Packages Compromised: Credential-Stealing Worm — Aikido Security