Notifications
Clear all
Topic starter
11/06/2026 11:00 pm
TL;DR: Shai-Hulud 2.0 infected 600+ npm packages, created 20,000+ GitHub repos for exfiltration, and leaked 15,000 secrets by abusing long-lived tokens and CI environments, according to Riptides. The incident shows that static secrets, not just supply-chain trust, remain the core governance failure in modern software delivery.
NHIMG editorial — based on content published by Riptides: Shai-Hulud 2.0: A Technical Breakdown and Why Secrets Need to Die
By the numbers:
- Shai-Hulud 2.0 infected 600+ npm packages and created 20,000+ GitHub repos for exfiltration.
Questions worth separating out
Q: What breaks when static secrets are embedded in developer and CI workflows?
A: Static secrets break the trust boundary because they can be copied, reused, and replayed long after the original workflow step is complete.
Q: Why do service account and maintainer tokens increase supply-chain risk?
A: Service account and maintainer tokens increase supply-chain risk because they often have both reach and reuse.
Q: How do organisations know if secrets management is actually working?
A: Secrets management is working only when credentials are absent from endpoints, build logs, environment variables, and source-controlled configuration.
Practitioner guidance
- Inventory every publish-capable machine identity Map npm, GitHub, CI, cloud, and runner credentials that can publish, sign, or deploy code.
- Remove static secrets from build and developer paths Eliminate long-lived tokens from .npmrc files, shell profiles, CI variables, and local workspace configs where possible.
- Separate publishing authority from routine CI execution Use distinct identities for build, test, and release operations so that compromise of a runner does not automatically confer package-maintainer rights.
What's in the full article
Riptides' full blog post covers the operational detail this post intentionally leaves for the source:
- The exact malware flow from malicious package hook to Bun bootstrap, which helps security teams build more accurate detection logic.
- The GitHub-based exfiltration pattern, including how public repos and Actions runners were used for persistence and data movement.
- The demo path showing how a running pod can lose API keys and what changes when static credentials are replaced with just-in-time access.
- The specific controls Riptides highlights for eliminating permanent power from supply-chain and workload environments.
👉 Read Riptides' technical breakdown of Shai-Hulud 2.0 and secrets abuse →
Shai-Hulud 2.0 and the secrets problem teams keep underestimating?
Explore further
12/06/2026 7:28 am
Static secret exposure is the identity failure mode this campaign exploits. The attack succeeded because credentials were stored in places that build and developer tooling could reach automatically. Long-lived tokens, shell history, environment variables, and CI runner state all became attack surface. The implication is not merely that secrets need better hygiene. It is that any programme depending on reusable static secrets is already accepting a breach path inside the delivery pipeline.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which explains why secret exposure keeps recurring in developer tooling and CI.
A question worth separating out:
Q: Who is accountable when a package token is abused in a supply-chain attack?
A: Accountability sits with the teams that defined the token's scope, storage, rotation, and revocation model, not just with the final victim of the malware. Security, platform, and release engineering all share responsibility when a machine identity is allowed to carry permanent publishing power.
👉 Read our full editorial: Shai-Hulud 2.0 shows why static secrets still fail at scale
