Red Hat Employee Account Breach: 32 Packages, 80K Downloads

A compromised Red Hat employee GitHub account led to malicious code being published across at least 32 npm packages under the @redhat-cloud-services namespace. These packages, with roughly 80,000 combined weekly downloads, serve Red Hat's Hybrid Cloud Console. The attack deployed a credential harvesting worm called Miasma, a variant of the Shai-Hulud malware.

This wasn't a vulnerability exploit. This was legitimate publishing access turned against the supply chain.

Timeline

The exact timeline remains unclear, but the attack followed this pattern:

1. Initial compromise: A Red Hat employee's GitHub account was compromised.
2. Malicious publishing: The attacker used legitimate npm publishing credentials to push malicious versions of packages.
3. Propagation: The Miasma worm harvested credentials and attempted to spread to other repositories.
4. Detection: Security researchers and Snyk identified the malicious code.
5. Response: Red Hat began incident response and package remediation.

The attacker didn't need to break any systems. They had valid credentials that passed every authentication check.

Which Controls Failed or Were Missing

Authentication without behavioral monitoring: The compromised account had valid credentials. Your CI/CD pipeline authenticated the user and approved the publish action. But no system flagged that this publish pattern deviated from the account's normal behavior.

Missing package signing verification: While npm supports package provenance through Sigstore, this doesn't prevent a compromised maintainer account from signing malicious code. The signature proves the package came from that account—it doesn't prove the account wasn't compromised.

Insufficient dependency scanning depth: Standard dependency scanners check for known vulnerabilities. They don't analyze behavioral patterns like "this package just started making network requests to exfiltrate credentials."

Lack of publish approval gates: The packages were published directly. No human review. No automated behavioral analysis. No comparison against previous package versions to flag suspicious new capabilities.

Inadequate credential isolation: A single GitHub account compromise gave the attacker npm publishing rights. Your build pipeline likely has similar single-point-of-failure credentials.

What the Standards Require

NIST 800-53 Rev 5 addresses this in several controls:

• AC-2 (Account Management): Requires monitoring account usage and reviewing unusual activity. Publishing 32 package updates in an atypical pattern should trigger review.
• AU-6 (Audit Review, Analysis, and Reporting): Mandates analyzing audit records for indications of inappropriate activity. Your CI/CD audit logs should flag behavioral anomalies.
• CM-3 (Configuration Change Control): Requires reviewing and approving changes before implementation. Package publishing is a configuration change to your supply chain.

NIST CSF v2.0 calls this out under:

• PR.DS-6: "Integrity checking mechanisms are used to verify software, firmware, and information integrity." This means checking not just that the signature is valid, but that the signed content matches expected behavior.
• DE.AE-3: "Event data are collected and correlated from multiple sources and sensors." Your npm publishes, GitHub commits, and package behavior should correlate.

ISO/IEC 27001:2022 requires:

• Control 5.15 (Access Control): Access rights must be reviewed and adjusted. Publishing rights shouldn't be permanent and unrestricted.
• Control 8.15 (Logging): Logs must be produced, stored, and analyzed. Package publishing events are security-relevant logs.

SOC 2 Type II Trust Service Criteria demand:

• CC6.1: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. A compromised external account (GitHub) accessing your publishing pipeline is exactly this threat vector.

Lessons and Action Items for Your Team

Implement behavioral analysis on package publishing. Before any package hits your registry:

• Compare file tree changes against the previous version.
• Flag new network capabilities, filesystem access, or process spawning.
• Require manual approval for packages that add dependencies or change build scripts.

Separate authentication from authorization. Your CI/CD pipeline should:

• Use short-lived tokens, not persistent credentials.
• Require approval from a second maintainer for publishing.
• Implement time-based restrictions (no publishes outside business hours without additional approval).

Add runtime behavior monitoring to your SBOM process. Your Software Bill of Materials tracks what you're using. Now track what it's doing:

• Monitor packages for unexpected network connections.
• Alert on credential file access.
• Flag packages that spawn child processes or modify other dependencies.

Audit your GitHub Actions and publish workflows. Right now:

• List every workflow with npm publish permissions.
• Check if they use GITHUB_TOKEN or long-lived secrets.
• Verify if they require manual approval or run automatically on merge.
• Confirm whether they validate package contents before publishing.

Implement package diff reviews. Before accepting any dependency update:

• Run npm diff between versions.
• Look for new files, especially in build scripts or postinstall hooks.
• Check for added dependencies.
• Verify the diff size matches the changelog claims.

Create a supply chain incident playbook. Document now, before you need it:

• Who has authority to revoke publishing credentials.
• How to identify all systems that pulled the compromised package.
• Your process for emergency package pinning.
• Communication templates for downstream consumers.

Test your provenance verification. If you're using Sigstore or similar:

• Verify you're actually checking signatures (many teams enable it but don't enforce it).
• Confirm your policy requires provenance for all production dependencies.
• Test that a package with valid provenance but suspicious behavior gets flagged.

The Miasma attack succeeded because it used legitimate access in an illegitimate way. Your defenses need to detect not just invalid credentials, but valid credentials doing invalid things. That requires moving from authentication-only security to behavior-based detection.

Start with your most critical internal packages. The ones with the most dependents. The ones that run in production. Add approval gates there first. Then expand outward.

GitHub Security