Miasma supply-chain malware exposes NHI trust gaps in npm

At a glance

What this is: A supply-chain compromise of 32 npm packages used install-time malware and stolen GitHub access to spread backdoored versions and harvest credentials.

Why it matters: It matters because CI/CD, developer workstations, and package pipelines all become identity attack surfaces when secrets, tokens, and publishing trust are not tightly governed.

By the numbers:

• A critical supply-chain attack has compromised 32 official npm packages under the @redhat-cloud-services scope.
• The attack occurred in two waves: 10:53 to 10:53:33 UTC and 13:44 to 13:46:47 UTC.

👉 Read Orca Security's analysis of the Miasma npm supply-chain compromise

Context

Miasma is a supply-chain compromise in which malicious code was inserted into trusted npm packages and then executed automatically during installation. For identity teams, the problem is not only package integrity. It is the fact that build systems, GitHub workflows, cloud credentials, and developer secrets were all part of the same trust chain.

The article shows how quickly a single compromised human account can turn into a non-human identity problem. Once the attacker controlled GitHub workflows, they could publish signed-looking package updates, harvest credentials from build environments, and cascade into downstream systems that trusted those packages. That is a typical pattern for modern open-source supply-chain abuse, not an isolated edge case.

Key questions

Q: How should security teams handle a supply-chain malware event that runs during npm install?

A: They should treat the install path as an execution path and assume any secrets present in that environment may be exposed. Immediate containment means removing affected versions, isolating build systems, rotating credentials reachable from those systems, and checking workflow identity, not just package checksums. The key point is that install-time code can act before application controls ever start.

Q: Why do build pipelines create such a large NHI compromise risk?

A: Build pipelines often hold multiple high-value credentials in one place, including cloud keys, publishing tokens, SSH material, and CI secrets. If a workflow or developer account is compromised, the attacker can sweep across those identities quickly and reuse them for lateral movement or package publication. The risk is concentration of trust, not just poor secret hygiene.

Q: What breaks when provenance attestation is treated as a complete trust signal?

A: Provenance can show where a package came from, but it does not guarantee the publishing identity was uncompromised at release time. If an attacker controls the workflow, they can still produce artifacts that look legitimate. Organisations that rely on attestation alone can miss the more important question of who controlled the release path when the artifact was created.

Q: Who should be accountable when compromised npm packages spread through CI and developer systems?

A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.

Technical breakdown

How preinstall hooks turn package install into code execution

The malware ran through npm's preinstall lifecycle hook, which executes before application code and before many review controls have a chance to inspect runtime behaviour. In practice, that means a dependency install can become an execution event. The payload was obfuscated JavaScript, about 4.2 MB in size, which makes static review harder and hash-based detection less reliable when each infection is uniquely encrypted. For identity teams, the important detail is that build-time execution inherits the privileges and secrets present in the environment, not the intended permissions of the package itself.

Practical implication: Treat dependency installation as an execution boundary and isolate build environments from standing secrets.

GitHub Actions OIDC and provenance can be abused when publishing trust is lost

The attacker used GitHub Actions workflows and OIDC tokens to publish backdoored packages with valid SLSA provenance attestations. That matters because provenance only proves that a pipeline ran, not that the pipeline was trusted at the moment it executed. If an attacker controls the workflow, they can still generate artifacts that appear legitimate to downstream consumers. This is a classic trust-chain failure in software supply security: the signing or attestation system is intact, but the identity controlling it is no longer trustworthy.

Practical implication: Separate workflow identity, publishing rights, and approval paths so one compromised account cannot mint trusted releases.

Credential sweep behaviour shows why install-time secrets are high value

The malware searched for GitHub tokens, AWS keys and session tokens, GCP credentials, Azure service principal material, Vault tokens, Kubernetes kubeconfigs, npm and PyPI publish tokens, SSH keys, Docker registry credentials, GPG keys, and .env files. That breadth is the point. A compromised build or developer environment often aggregates several identity domains at once, so one infection can become multi-cloud credential exposure in seconds. The worm's self-propagating design increases the blast radius further because stolen tokens can be reused to compromise additional repositories and packages.

Practical implication: Remove long-lived secrets from build and developer contexts and assume every exposed token is reusable until proven otherwise.

Threat narrative

Attacker objective: The attacker aimed to turn trusted package distribution into a credential-harvesting and propagation channel for wider supply-chain compromise.

1. Entry began when a Red Hat employee's GitHub account was compromised and malicious workflows were inserted into three RedHatInsights repositories to gain publishing control.
2. Credential access followed when the compromised packages executed a preinstall payload that swept cloud tokens, registry secrets, SSH keys, and workflow credentials from install environments.
3. Impact came as the worm published 32 malicious npm packages, enabling downstream credential theft, additional package compromise, and broader supply-chain propagation.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build pipelines have become non-human identity concentrations, not just software delivery systems. This incident worked because package publishing, workflow execution, cloud access, and secret storage were collocated inside the same trust zone. Once a single GitHub account or workflow identity is compromised, the attacker inherits a dense cluster of NHIs that were never meant to share a failure domain. The practitioner implication is that build systems must be governed as identity infrastructure, not only as DevOps tooling.

Static package trust is no longer enough when execution happens at install time. The preinstall hook made the package behave like an executable credential access vector, which means traditional dependency review looks in the wrong place. The useful control question is not whether the package name is trusted, but whether the environment grants secrets before code execution begins. Practitioners should treat lifecycle hooks as privileged execution surfaces and not as passive metadata.

Credential sprawl created the blast radius, but the deeper failure was shared trust across unrelated secret types. The same infected environment could reach cloud keys, registry tokens, SSH material, and signing keys because governance had not separated them by purpose or sensitivity. That is a classic NHI segmentation failure. Once the malware arrived, it did not need to choose a path, because the environment had already done that work for it. The implication is that one compromised build identity should never be able to traverse every secret class in a single step.

Supply-chain provenance can validate origin while still missing compromise of the publishing identity. Valid SLSA attestations did not stop the malicious release because provenance solved authenticity of the pipeline artifact, not trust in the operator of that pipeline. That gap is especially dangerous in open-source distribution, where consumers often assume signed or attested output means safe output. Practitioners should stop treating provenance as a stand-alone control and instead align it with workflow identity governance and secret isolation.

Ephemeral detection windows are now shorter than many response processes. The article's two attack waves and rapid spread show that package compromise can move from publishing abuse to downstream infection before routine review cycles complete. That means the operational unit is not the release, but the trust window between workflow compromise and first consumer install. Security teams need to reason about that window explicitly when deciding how to gate package ingestion and rotate secrets after exposure.

From our research:

• A critical supply-chain attack has compromised 32 official npm packages under the @redhat-cloud-services scope, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research on the 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
• That confidence gap means package trust, workflow identity, and secret governance need to be assessed together, not as separate programmes.

What this signals

Identity concentration inside build systems is the next operational blind spot. When one CI runner or publishing workflow can reach cloud keys, registry tokens, and signing material, the blast radius is already too large for traditional review cadences. Practitioners should map where secrets co-reside, then break those clusters apart before a dependency event forces the issue.

The relevant control pattern is closer to dependency trust segmentation than to classic patch management. Teams that already maintain package provenance checks should extend that discipline to workflow identity, because provenance without identity governance still permits malicious releases to look legitimate.

With 59.8% of organisations seeing value in dynamic ephemeral credentials, per the 2024 Non-Human Identity Security Report, this incident strengthens the case for making install-time secrets non-persistent and task-scoped.

For practitioners

• Isolate build-time secrets from package installation paths Run dependency installs in environments that do not contain cloud credentials, signing keys, or registry tokens. Use short-lived, task-scoped access for build jobs and keep sensitive credentials out of developer workstations and CI runners where lifecycle hooks can execute.
• Review GitHub workflow identity and publishing rights Audit who can modify release workflows, who can mint OIDC-backed tokens, and which repositories can publish to package registries. Separate workflow administration from package publishing so one compromised account cannot produce trusted artifacts across multiple projects.
• Treat all exposed secrets as compromised until rotated Rotate CI secrets, cloud access keys, SSH material, registry tokens, and any signing-related credentials that were reachable from infected build or developer environments. Check whether the affected secrets were reused across multiple systems before restoring trust.
• Enforce dependency allowlisting and SBOM validation Block unknown or unapproved package versions and verify software bills of materials against known-good dependency sets before deployment. Use this to catch poisoned packages in front-end builds, CI pipelines, and container image construction.

Key takeaways

• The breach shows that package installation can be an identity execution event, not just a software delivery step.
• Orca Security says 32 npm packages were compromised and the affected packages averaged about 80,000 weekly downloads, which shows the potential downstream blast radius.
• The control that would have mattered most was separating workflow publishing rights and build-time secrets from environments that can execute dependency hooks.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Software Provenance: Software provenance is evidence showing how an artifact was built, signed, and delivered. It helps verify origin, but it does not by itself prove the publishing identity was uncompromised or that the build environment was free of malicious activity.
• Workflow Identity: Workflow identity is the non-human identity used by CI/CD systems to authenticate and act during automated release steps. When that identity is compromised, an attacker can publish trusted-looking code, access secrets, and move laterally through connected repositories and build systems.
• Secret Sprawl: Secret sprawl is the accumulation of credentials across pipelines, developer machines, and tooling where they are harder to govern consistently. It increases the blast radius of any single compromise because many unrelated systems may share the same exposed tokens or keys.

Deepen your knowledge

Package poisoning, workflow identity, and secret isolation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern CI/CD and developer secrets in the same environment, it is worth exploring.

This post draws on content published by Orca Security: Miasma supply-chain malware compromise affecting @redhat-cloud-services npm packages. Read the original.