What Happened
In early 2025, security researchers at Wiz discovered unauthorized code modifications in at least 32 package releases within Red Hat's npm namespace. These packages, linked to the Shai-Hulud malware family and dubbed "Miasma: The Spreading Blight," were designed to steal developer credentials and cloud service secrets. Before their removal, these compromised packages averaged 80,000 weekly downloads.
This attack wasn't about typosquatting or lookalike packages. Attackers modified legitimate packages within a trusted organizational namespace, bypassing many teams' initial trust filters.
Timeline
Initial Compromise: Attackers gained write access to Red Hat's npm namespace through an undisclosed method.
Malicious Modifications: 32 legitimate package releases were altered to include credential-harvesting code, which was absent from the corresponding GitHub source repositories.
Active Exfiltration: The malware created repositories titled "Miasma: The Spreading Blight" and began extracting developer credentials and cloud service tokens from environments where the packages were installed.
Discovery and Response: Wiz researchers identified the unauthorized modifications and reported them. Most malicious packages have since been removed from the npm registry.
Current Status: The attack vector into Red Hat's namespace has not been publicly disclosed. The full extent of credential exposure remains unknown.
Which Controls Failed or Were Missing
1. Package Integrity Verification
Your build pipeline likely trusts that the namespace owner ensures package integrity. However, the code in these packages didn't match the source repository. Without verifying that published packages match their declared source, you can't catch such modifications.
2. Credential Scope and Rotation
The malware targeted developer credentials and cloud service tokens. If your developers run npm install with access to production AWS keys, GCP service accounts, or database credentials, those secrets are exposed. Avoid long-lived production credentials in local environments.
3. Namespace Access Controls
Write access to Red Hat's npm namespace was compromised. Whether through compromised credentials, insufficient MFA, or overly permissive access policies, namespace protection failed. Most organizations don't audit who can publish to their npm namespace or enforce hardware MFA for publishing rights.
4. Runtime Monitoring
The malicious code executed during npm install and began exfiltrating data. Without monitoring outbound connections from your build environments, especially to unusual or newly-created repositories, you won't detect this type of data exfiltration until it's too late.
What the Relevant Standards Require
NIST 800-53 Rev 5 — SR-3 (Supply Chain Controls)
This control requires organizations to "employ integrity verification tools to detect unauthorized changes to software and firmware." For npm dependencies, this means:
- Verify package checksums against known-good values
- Compare published packages to their source repositories
- Maintain an approved package inventory with version pinning
NIST 800-53 Rev 5 — SR-4 (Provenance)
You need documented provenance for software components. When you pull @redhat/package-name, can you verify it was built from the expected source commit? Most teams cannot. The standard requires "a verifiable chain of custody for software components."
ISO 27001 — A.8.30 (Outsourced Development)
This control addresses security in development processes, including third-party code. You must assess and monitor the security of external dependencies. Pulling 80,000 weekly downloads of packages without verification mechanisms violates this requirement.
PCI DSS v4.0.1 — Requirement 6.3.2
If you process payment data, you must "maintain an inventory of bespoke and custom software, and third-party software components." That includes npm packages. You also need to identify security vulnerabilities—and unauthorized modifications count as vulnerabilities.
OWASP ASVS v4.0.3 — V14.2.1
This verification requirement states: "Verify that all components are up to date and that their integrity can be verified." The key word is integrity. Namespace trust isn't enough.
Lessons and Action Items for Your Team
Implement Package Provenance Verification
Start using tools that verify npm packages match their source repositories. Sigstore and SLSA (Supply Chain Levels for Software Artifacts) provide frameworks for this. At minimum:
- Pin exact versions in your
package-lock.json - Use
npm audit signaturesto verify signed packages - Consider running a private npm registry that only mirrors verified packages
Isolate Build Environments from Production Credentials
Your CI/CD pipeline should never have direct access to production secrets. Use:
- Short-lived, scoped credentials that expire after the build
- Secrets managers with role-based access (AWS IAM roles for service accounts, not long-lived keys)
- Separate build service accounts with read-only access to repositories and write-only access to artifact storage
If a developer's laptop gets compromised during npm install, production shouldn't be at risk.
Audit and Harden Your npm Namespace
If your organization publishes packages:
- Require hardware MFA for all accounts with publish rights
- Audit who has access to your namespace monthly
- Enable npm's two-factor authentication requirement for publishing
- Set up alerts for any package publication to your namespace
Monitor Outbound Connections from Build Environments
Deploy network monitoring on your CI/CD runners. Alert on:
- Connections to newly-registered domains
- Outbound traffic to non-approved package registries
- Large data transfers during dependency installation
The Miasma malware created repositories to receive stolen credentials. If your build environment suddenly starts pushing data to a GitHub repo you've never seen, that's your signal.
Create a Supply Chain Incident Response Plan
When you discover a compromised dependency, you need to know:
- Which builds used the malicious version
- Which environments those builds deployed to
- Which credentials were accessible in those environments
- How to rotate all potentially exposed secrets
Document this process now. In the Red Hat case, the response window was the time between installation and credential exfiltration—likely minutes.
Verify Before You Trust Namespaces
The Red Hat namespace was trusted. It was compromised anyway. Your verification process can't stop at "Is this from a reputable organization?" You need technical controls that verify package integrity regardless of publisher reputation.
Namespace trust is a starting point, not a security control.
