On June 1, 2026, attackers published over 30 compromised npm packages under Red Hat's Cloud Services namespace. These packages contained Mini Shai-Hulud malware designed to exfiltrate credentials from developer build environments. Red Hat removed most infected packages within two hours, but the incident highlights critical gaps in software supply chain protection.
What Happened
Attackers gained control of a GitHub account with write access to Red Hat's Cloud Services repositories. They pushed malicious code to two repositories and published the compromised packages to npm. The malware targeted environment variables and configuration files in CI/CD pipelines, seeking cloud credentials, API keys, and authentication tokens.
The attack exploited npm's bypass_2fa publish parameter, allowing automation workflows to publish packages without interactive two-factor authentication. This parameter enabled the attackers to push packages even though the compromised account had 2FA enabled.
Timeline
June 1, 2026, morning: Attackers publish malicious packages to npm registry from a compromised GitHub account.
June 1, 2026, ~2 hours later: Red Hat detects anomalous publishing activity and removes most infected packages from npm.
Post-incident: Wiz Security analyzes the malware and publishes technical details about the bypass_2fa exploitation.
The two-hour window represents Red Hat's detection and response time. The duration of the GitHub account compromise before the attack and the number of developers who downloaded the packages during that window remain unknown.
Which Controls Failed
Account compromise went undetected. The attackers had time to understand Red Hat's repository structure and publishing workflow before executing the attack, indicating missing or ineffective monitoring of account access patterns.
Publish automation lacked additional verification. The bypass_2fa parameter exists because automated publishing can't complete interactive 2FA challenges. However, there was no compensating control—no secondary approval, behavioral analysis, or anomaly detection on the automation token itself.
Package signing wasn't enforced. If Red Hat required cryptographic signatures on packages, using keys stored separately from GitHub credentials, the compromised account alone wouldn't have been sufficient.
No pre-publish scanning. The malicious code entered the registry without automated detection. The packages should have triggered alerts for suspicious network calls or credential-harvesting patterns.
What Standards Require
NIST 800-53 Rev 5 Requirement AC-2(12) requires organizations to monitor accounts for atypical usage. Publishing 30+ packages in a short window from an account that normally publishes sporadically should trigger automated review.
ISO/IEC 27001:2022 Annex A.8.3 addresses media handling and includes requirements for protecting software distribution channels. Your package publishing workflow is a critical distribution channel and needs the same protection as production deployment pipelines.
NIST Cybersecurity Framework v2.0 function PR.DS-6 calls for integrity checking mechanisms. For software packages, this means cryptographic signatures verified independently of the publishing credential.
SOC 2 Type II Common Criteria CC6.1 requires logical and physical access controls with monitoring and review. Your npm publishing tokens are access controls. They need monitoring for unusual activity patterns, not just authentication success/failure logs.
OWASP ASVS v4.0.3 Requirement 14.2.3 states that build and deployment processes must use dependency verification. If your build system auto-updates dependencies, it must verify package integrity before installation.
Lessons and Action Items
Separate your signing keys from your publishing credentials. Store package signing keys in a hardware security module or separate key management system. Require signatures on all published packages. Verify signatures in your build pipeline before installing any dependency. The compromised GitHub token shouldn't be sufficient to publish a trusted package.
Treat automation tokens as privileged credentials. Your NPM_TOKEN environment variable in GitHub Actions has more power than most production service accounts. Rotate it monthly. Monitor every use. Alert on publications outside your normal package list or publishing schedule. Consider requiring human approval for new package names.
Build behavioral profiles for publishing accounts. Track: time of day, number of packages per session, time between publications, package name patterns. Alert when current behavior deviates from the profile. Red Hat's normal pattern probably isn't "30 packages in 20 minutes."
Scan packages before they reach the registry. Run your own malware scanner in the CI/CD pipeline before npm publish executes. Check for: outbound network calls, file system access patterns, environment variable enumeration, obfuscated code. Block publication if the scan fails. Don't rely on the registry's post-publication scanning.
Implement publish approval workflows for production packages. For packages that other teams depend on, require a second reviewer to approve the publication. This can be automated: the CI pipeline prepares the package, but a separate approval step with different credentials actually publishes it.
Audit your use of bypass_2fa. If you're using this parameter, document why interactive 2FA isn't feasible and what compensating controls you've implemented. Consider whether you could use time-limited, scope-restricted tokens instead of a permanent bypass.
Monitor your dependencies' publication patterns. When you install a package, record its publication timestamp and the account that published it. Alert your security team when a dependency updates outside its normal pattern—especially if it's a mature package that rarely changes.
Test your detection speed. Red Hat's two-hour response was faster than most organizations would manage. Run a tabletop exercise: if a compromised account published a malicious package right now, how would you find out? Who would see the alert? How long until you could remove the package?
The attackers understood npm's automation features better than the defenders did. Your publishing workflow needs the same rigor as your production deployment pipeline—because for your users, your packages are production.
