Shai-Hulud 2.0 shows why static secrets still fail at scale

At a glance

What this is: This is a technical postmortem of Shai-Hulud 2.0 and its supply-chain theft of developer and CI credentials, with the central finding that static secrets remain the exploitable weak point.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern the identities hidden inside developer tooling, CI runners, and package ecosystems, not just user logins.

By the numbers:

• Shai-Hulud 2.0 infected 600+ npm packages and created 20,000+ GitHub repos for exfiltration.

👉 Read Riptides' technical breakdown of Shai-Hulud 2.0 and secrets abuse

Context

Shai-Hulud 2.0 is a supply-chain attack that weaponised package installation, developer tooling, and CI infrastructure to steal credentials at scale. The primary identity security issue is not the malware family itself, but the long-lived secrets and overprivileged machine identities it was able to reach inside everyday software delivery.

For IAM and NHI programmes, the attack is a reminder that the weakest identity in the chain is often not a human user but a token, runner, or package-publishing credential. Once those identities are stored broadly, reused automatically, and left without strong expiry discipline, compromise becomes a matter of discovery rather than exploitation.

The article's starting position is typical for a mature supply-chain intrusion: attackers did not need an exotic exploit chain, only access to the identities already embedded in developer workflows.

Key questions

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. In developer and CI environments that means package credentials, cloud keys, and tokens can be harvested from files, variables, or history, then reused for publishing, persistence, or exfiltration.

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. If a token can publish packages, access source control, or query cloud systems, compromise of one identity can cascade into distribution, data theft, and persistence across trusted tooling.

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. If secret scanners still find high-value tokens in routine developer paths, the control is not operating as designed, regardless of policy statements or vault adoption.

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.

Technical breakdown

Malicious package lifecycle hooks as an entry vector

The first stage of the attack used compromised npm packages with a malicious preinstall hook in package.json. Lifecycle hooks run before installation completes, which makes them attractive for malware because they trigger in trusted developer and CI environments without requiring an interactive user action. The payload executed across npm, pnpm, and yarn environments that honor those scripts. This is a packaging-layer trust problem, not just a malware delivery problem, because the install process itself becomes execution authority.

Practical implication: restrict lifecycle-script execution where possible and treat package installation as a controlled execution boundary, not a harmless build step.

Secret harvesting from developer machines and CI runners

Once inside, the malware bootstrapped Bun and executed an obfuscated second-stage payload that launched TruffleHog to scrape secrets from repositories, local files, environment variables, and shell history. It also collected AWS, GCP, and Azure credentials, plus npm and GitHub tokens. That matters because CI runners and developer endpoints often hold the very identities used to publish code, sign releases, and access cloud services. In effect, the attack turned the software delivery plane into a secrets inventory.

Practical implication: reduce the secrets surface in build environments and separate publish credentials from routine developer and runner contexts.

Worm-like propagation through stolen publishing credentials

The third stage used stolen npm tokens from .npmrc to enumerate maintainer scope, download packages, inject fresh backdoors, and publish new versions under the victim's identity. That creates recursive spread because each compromised maintainer becomes a new supply-chain distributor. The malware also used GitHub for exfiltration and persistence by creating public repos and registering self-hosted runners. This is a classic identity abuse pattern: legitimate publishing authority is repurposed into automated propagation.

Practical implication: constrain package-publishing rights tightly and monitor for identity misuse that turns maintainer credentials into distribution channels.

Threat narrative

Attacker objective: The attacker objective was to steal reusable developer and cloud credentials, then use them to spread malware through trusted software delivery channels and exfiltrate data at scale.

1. Entry occurred through compromised npm packages that executed malicious preinstall hooks during installation.
2. Credential access followed when the payload used TruffleHog to harvest secrets from local files, environment variables, shell history, and cloud credentials.
3. Impact came from stolen npm and GitHub tokens being reused to publish malicious packages, create exfiltration repos, and persist in GitHub Actions runners.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret sprawl turns every trusted tool into a credential collection point. Shai-Hulud 2.0 did not need to break cloud controls first because package installation and CI execution already had access to them. That is a governance issue for NHI programmes as much as for AppSec teams, because package tokens, GitHub tokens, and cloud keys are machine identities with privilege and lifecycle requirements. Practitioners should read this as evidence that identity scope is leaking across tool boundaries.

Ephemeral identity is now the practical boundary for supply-chain resilience. The more a workflow depends on credentials that can be copied, cached, or replayed, the more attractive it becomes to attackers who can mine endpoints at scale. SPIFFE-style workload identity, short-lived access, and least-privilege publishing rights reduce the blast radius, but the real lesson is that permanent power has no safe place in modern build systems. The implication is that secretless delivery is no longer a future architecture, it is the governance baseline.

Identity blast radius is now the right lens for developer tooling. Once a package maintainer token can publish code, exfiltrate data, and register persistence, the question is no longer whether the token is stolen but how far it can move. That makes the hidden identities in CI and package ecosystems a board-level control issue, not a niche engineering concern. Practitioners should measure how much authority each machine identity can transfer if compromised.

Package ecosystems are becoming identity ecosystems. The post shows that software distribution platforms now contain their own maintainer, runner, and publishing identities, each with distinct risk and revocation needs. NHI governance has to extend into these environments because compromise is often a function of access design, not just detection speed. The practical conclusion is that identity controls must be designed for the delivery chain, not only for production workloads.

From our research:

• 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.
• That gap makes the case for the Guide to the Secret Sprawl Challenge stronger for teams trying to reduce hidden credential exposure across build and release pipelines.

What this signals

Secret sprawl is now an operational identity problem, not just an AppSec problem. When CI, package managers, and developer endpoints all carry reusable credentials, your governance model has already expanded beyond human IAM. The next maturity step is to treat build-time identities, maintainer tokens, and release credentials as first-class governed assets, with the same lifecycle discipline you apply to privileged human access.

With 27 days as the average remediation time for a leaked secret, the attack window often remains open long enough for reuse, propagation, and persistence to succeed. That lag matters because attackers do not need perfect secrecy, only a short period of exposure before revocation catches up.

Identity blast radius is the concept teams should sharpen here: the real question is how far a stolen token can move before it is detected and revoked. For practitioners, that means prioritising low-latency discovery, narrower publishing scopes, and less reusable access patterns in CI and package ecosystems.

For practitioners

• Inventory every publish-capable machine identity Map npm, GitHub, CI, cloud, and runner credentials that can publish, sign, or deploy code. Prioritise identities that can both write artifacts and reach secrets stores, because those are the highest-value compromise paths.
• 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. Replace them with short-lived, audience-bound credentials and scoped workload identity for each pipeline stage.
• 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. Tighten role scope and monitor for unexpected publication or repo-creation behaviour.
• Watch for exfiltration through legitimate platforms Alert on public repo creation, unusual GitHub Actions runner registration, and bursts of encoded secret files in places that are normally part of developer workflow. Attackers increasingly hide inside trusted services instead of calling external infrastructure.

Key takeaways

• Shai-Hulud 2.0 shows that supply-chain compromise becomes far more damaging when developer tools can reach long-lived secrets and publishing credentials.
• The scale mattered: hundreds of infected packages, tens of thousands of GitHub repos for exfiltration, and thousands of leaked secrets demonstrate how quickly identity abuse can spread.
• The control that changes the outcome is not just better scanning, but removing static secrets from build and release paths in favour of short-lived, tightly scoped identity.

Key terms

• Static Secret: A static secret is a reusable credential such as an API key, token, or password that persists beyond a single transaction. In identity governance terms, it creates replay risk because anyone who copies it can act as the original identity until the secret is rotated or revoked.
• Workload Identity: Workload identity is the identity assigned to software, pipelines, or services so they can authenticate without embedding reusable secrets. It gives machines a governed way to prove who they are, while letting security teams enforce scope, expiry, and telemetry on access.
• Secret Sprawl: Secret sprawl is the uncontrolled distribution of credentials across code, files, build systems, logs, and endpoints. It weakens governance because revocation becomes slow and incomplete, and one stolen secret can expose multiple systems if the same value is reused elsewhere.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is compromised. For non-human identities, it is shaped by privilege scope, publishing rights, token lifetime, and whether the credential can be reused across environments or automation paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Shai-Hulud 2.0: A Technical Breakdown and Why Secrets Need to Die. Read the original.