What Happened
Between April and May 2026, attackers compromised Red Hat's GitHub credentials and injected malicious code into npm packages maintained by the company. The malware, dubbed "Miasma: The Spreading Blight," harvests credentials from developer environments, spreads through CI/CD systems, and establishes persistence across infected infrastructure.
Whiteintel detected a Red Hat GitHub credential and session cookie in infostealer logs on April 13 and May 15, 2026. The first commit containing the Miasma identifier appeared on May 29, 2026. The malware uses Sigstore to sign malicious artifacts, making them appear legitimate to automated security checks.
The attack targets developer workstations, CI/CD runners, and cloud service credentials. It avoids execution on Russian-language systems, suggesting geopolitical targeting.
Timeline
- April 13, 2026: Red Hat GitHub credential appears in infostealer logs
- May 15, 2026: Red Hat session cookie detected in second infostealer dump
- May 29, 2026: First commit containing "Miasma: The Spreading Blight" string pushed to Red Hat npm repository
- Date unknown: Malicious packages distributed through npm registry
- Date unknown: Worm begins propagating through downstream environments
The gap between credential theft and malicious commit suggests reconnaissance. The attackers spent at least two weeks with valid credentials before using their access.
Which Controls Failed or Were Missing
Credential monitoring: Red Hat did not detect that valid GitHub credentials appeared in public infostealer logs. Organizations need to monitor infostealer logs, not just paste sites and dark web markets.
Session management: The session cookie remained valid long enough for attackers to use it weeks after theft. No automated revocation occurred when the credential appeared in breach data.
Code signing verification: While the malware used Sigstore to sign artifacts, downstream consumers did not verify that the signing identity matched expected maintainers. Signing proves the authenticity of the signer, not the authorization of the content.
Build provenance: The compromised packages lacked SLSA provenance attestations that would have shown the build occurred outside Red Hat's controlled infrastructure.
Dependency pinning: Organizations consuming the packages used loose version ranges (^1.2.0) rather than exact pins with hash verification, allowing automatic updates to malicious versions.
Runtime monitoring: The malware established persistence through shell profiles and scheduled tasks, but standard endpoint detection focused on known malware signatures rather than behavioral anomalies in developer tools.
What the Relevant Standard Requires
NIST 800-53 Rev 5 addresses supply chain risk through several controls:
SR-3 (Supply Chain Controls and Processes) requires organizations to employ provenance controls and integrity verification for acquired software. This includes verifying that software components originate from legitimate sources and have not been tampered with during distribution.
SR-4 (Provenance) mandates documenting and monitoring the provenance of system components. SLSA provenance attestations directly satisfy this requirement by creating a verifiable chain from source repository to built artifact.
SA-10 (Developer Configuration Management) requires configuration management during system development, including integrity verification of software and firmware components. Exact dependency pinning with cryptographic hash verification implements this control.
IA-4 (Identifier Management) and IA-5 (Authenticator Management) require organizations to manage identifiers and authenticators to uniquely identify and authenticate users. This includes monitoring for compromised credentials and revoking access when credentials are exposed.
PCI DSS Requirement 6.3.2 requires an inventory of bespoke and custom software and third-party software components. Without this inventory, you cannot detect when a legitimate component is replaced with a malicious version.
ISO/IEC 27001 Annex A.8.30 (Outsourcing) requires organizations to address information security within supplier agreements, including verification of software integrity and monitoring for supply chain compromises.
Lessons and Action Items for Your Team
Implement credential leak monitoring: Subscribe to services that monitor infostealer logs. Recorded Future, Intel 471, and KELA provide infostealer log access. Configure alerts for your organization's domains and code repository hostnames.
Enforce short session lifetimes: GitHub session cookies should expire within hours. Configure your identity provider to require re-authentication for sensitive operations like pushing code or modifying package registry settings.
Require SLSA provenance: Generate SLSA Build Level 2 provenance for internal packages using GitHub Actions or your CI/CD platform. Verify provenance on consumed packages using slsa-verifier before installation. Reject packages without provenance from critical dependencies.
Pin dependencies with hash verification: Replace version ranges in package.json with exact versions. Generate and commit package-lock.json or yarn.lock files. Configure your package manager to verify cryptographic hashes before installation:
npm config set package-lock true
npm config set package-lock-only true
Monitor shell profile modifications: Alert when .bashrc, .zshrc, or scheduled tasks change on developer workstations and CI/CD runners. These are common persistence mechanisms. Tools like osquery or Wazuh can detect unauthorized modifications.
Verify signing identities: Don't just check that an artifact is signed -- verify the signing identity matches your allowlist. Sigstore's transparency log lets you query who signed an artifact. A valid signature from an unknown identity should fail your checks.
Audit your npm dependency tree: Run npm audit and npm ls to identify packages from compromised maintainers. Check the last publish date -- packages that haven't been updated in years suddenly releasing new versions warrant investigation.
Segment CI/CD credentials: Your CI/CD runners should not have credentials that can push to production registries. Use separate credentials for build (read-only registry access) and publish (write access) stages. Require human approval between stages.
The Miasma attack succeeded because multiple defensive layers failed simultaneously. Stolen credentials went undetected, malicious code bypassed signing verification, and persistence mechanisms evaded monitoring. Your supply chain security is only as strong as your weakest verification point.
