Shai-Hulud’s GitHub pivot shows why NHI controls lag

At a glance

What this is: Semgrep says the latest Shai-Hulud variant now spreads through GitHub Actions, repo commits, and IDE hooks instead of relying only on npm installs.

Why it matters: That matters because NHI governance now has to cover CI/CD identities, developer tooling, and token lifecycles, not just stored secrets and package hygiene.

By the numbers:

• The latest Shai-Hulud campaign spread to 400+ packages by no longer needing npm installs to spread.
• The campaign published 84 malicious packages in under six minutes.

👉 Read Semgrep's analysis of the TanStack Shai-Hulud campaign and GitHub pivot

Context

Shai-Hulud is no longer just a package-manager worm. The article shows a supply chain threat that now abuses GitHub Actions, repository trust boundaries, and IDE hooks, which means the practical attack surface extends into identity and access pathways that many development programmes still treat as separate from application security. In primary keyword terms, this is NHI governance failure in a CI/CD and developer tooling context.

The important shift is that the malware can move with stolen tokens, workflow permissions, and publishing trust rather than only with a poisoned dependency install. That creates a boundary problem for IAM and PAM teams, because the access that matters is short-lived, delegated, and often created for automation rather than a human user. This starting position is now common across modern software supply chains, not exceptional.

Key questions

Q: What fails when GitHub Actions workflows can be modified to run attacker-controlled code?

A: The failure is trust in the workflow file as a safe automation boundary. Once an attacker can alter the job definition, the build system can execute hidden logic with access to secrets and deployment context. That turns CI/CD into an identity-bearing execution layer and makes repository integrity a credential security issue as well.

Q: Why do short-lived tokens still create major risk in CI/CD environments

A: Short-lived tokens reduce persistence, but they do not prevent theft during execution or over-privileged use inside the session. If the workflow can mint publishing credentials, reach cloud metadata, or access developer tools, the token’s lifetime matters less than its scope. The right control is narrow runtime authority, not duration alone.

Q: What do security teams get wrong about supply chain malware persistence

A: They often focus only on package registry poisoning and miss local execution state. Modern supply chain malware can persist through IDE configuration, repo commits, task definitions, and hook files, so opening a repository can re-trigger compromise. Detection has to include repository artefacts and endpoint configuration, not just dependency scanners.

Q: Who is accountable when CI identities are abused to publish malicious packages

A: Accountability sits with the teams that own workflow design, package release permissions, and identity governance for automation. In practice, that means engineering, platform security, and IAM must share control over who can publish, what can run, and which tokens can be minted. Frameworks such as NIST CSF and OWASP-NHI help structure that ownership.

Technical breakdown

How GitHub Actions cache poisoning turns a workflow into a spreader

The article describes a chain where a pull_request_target workflow executes attacker-controlled code with base repository privileges, then restores poisoned build cache in a later release workflow. That means the attack does not require a fresh package install on the victim side. The malicious payload is effectively staged inside the CI environment, where trusted automation becomes the distribution channel. Once the workflow also has id-token: write permissions, the attacker can reach publishing systems that trust the pipeline rather than the actor.

Practical implication: treat workflow trust boundaries, cache keys, and token scopes as identity controls, not just build settings.

Why short-lived credentials still fail when runtime access is too broad

The malware now targets AWS, Kubernetes, Vault, GitHub, AI tooling, and developer comms, showing that credential lifetime is only one part of the problem. Short-lived tokens can still be harvested during execution, and once the attacker has a valid session, the real issue becomes what that session can reach. In NHI terms, this is not simply secret exposure. It is ephemeral identity with excessive runtime authority, which makes the blast radius depend on permissions, not duration alone.

Practical implication: pair short-lived credentials with tightly scoped runtime permissions and service-level segmentation.

How IDE persistence hooks extend supply chain compromise beyond package installs

The campaign adds persistence through .claude settings, .vscode tasks, and repo commits, so opening a compromised project can re-execute the payload even without npm activity. This is a notable architecture change because it shifts infection from package consumption into developer workflow state. The attacker is no longer waiting for the registry event alone. They are using the repository as a runtime substrate, which means endpoint trust, developer tooling trust, and repository trust are now coupled.

Practical implication: monitor developer tooling configuration files and repo mutations as part of software supply chain detection.

Threat narrative

Attacker objective: The attacker’s objective is to harvest reusable credentials, expand supply chain reach, and maintain persistence across developer and publishing environments.

1. Entry begins when the attacker abuses a pull_request_target workflow and poisoned dependency path to execute code inside a trusted GitHub Actions pipeline.
2. Credential access follows as the payload extracts tokens from runners, cloud environments, AI tooling, and developer systems, then reuses them for publishing and propagation.
3. Impact comes from recursive package compromise, IDE persistence, and delayed detection, which let the worm spread across downstream projects and infrastructure.

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

GitHub workflow trust has become an NHI governance problem. This campaign shows that CI/CD identities are not just implementation details. They are privileged non-human identities with publishing authority, repository write access, and token minting power. OWASP-NHI and NIST CSF both become relevant because the control failure is not a single secret leak, but an over-trusted automation boundary that can be turned into a distribution system. Practitioners should treat workflow identity as a first-class governance object.

Ephemeral credentials do not solve runtime abuse when the session boundary is too wide. The article makes clear that short-lived credentials can still be stolen while active and then reused for cloud, AI, and developer tooling access. The governance assumption that “short-lived equals safe” breaks when runtime scope is broader than the task. That is where least privilege, scope reduction, and privilege segregation matter more than token duration alone. The practical conclusion is that session lifespan is secondary to session authority.

Developer tooling persistence is now part of supply chain resilience. The campaign’s move into Claude Code and VS Code hooks shows a named concept we should track as tooling persistence drift: security state leaking from repositories into local developer execution environments. Once repo configuration can re-trigger malware, endpoint trust and source control trust are no longer separable concerns. That has implications for software assurance, SOC triage, and change control. Practitioners should include developer environment artefacts in supply chain threat models.

AI tooling expands the value of stolen NHIs. The malware’s upgrade path includes AI-related credentials and MCP configuration, which means identity sprawl now crosses from classic cloud automation into AI development environments. That intersection matters because AI systems increasingly rely on tokens, connectors, and delegated tool access rather than standalone user authentication. The governance conclusion is that AI security teams and IAM teams now share responsibility for the same credential surface.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 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.
• For a broader NHI lens: Explore Ultimate Guide to NHIs , Key Research and Survey Results for the survey context behind NHI sprawl and governance gaps.

What this signals

Tooling persistence drift: the next control gap is not only secret exposure, but the ability for repository state to re-seed malware into local developer environments. That means security teams need telemetry that spans source control, endpoint configuration, and identity events, not isolated scanning silos.

The programme signal is clear. If CI identities can mint publishing tokens and developer tools can re-run payloads, then NHI governance must extend into build systems, IDE policy, and secret handling workflows. Teams that still separate AppSec from IAM will keep missing the part of the attack that actually persists.

For teams using GitHub, the priority is to align workflow identity controls with least privilege and lifecycle offboarding. If you are already using NIST SP 800-53 Rev 5 Security and Privacy Controls, map the release pipeline to access, audit, and integrity requirements before the next compromise reaches production.

For practitioners

• Audit GitHub Actions trust boundaries Review workflows that use pull_request_target, cache restore, or id-token: write permissions. Remove fork-controlled execution paths, constrain cache keys, and separate untrusted PR processing from release workflows.
• Inventory and rotate exposed NHIs immediately Search for AWS, Kubernetes, Vault, npm, GitHub, and AI tooling tokens referenced in runner logs, developer home directories, and repo history. Rotate the credential families that were active during the infection window and revoke publishing access before re-enabling affected pipelines.
• Treat developer tooling files as detection signals Add monitoring for .claude settings, .vscode tasks, repo hooks, and unexpected commits to package manifests or setup scripts. These artefacts can indicate persistence even when package installs are not occurring.
• Reduce runtime authority for publishing identities Limit CI identities to the narrowest repository, package namespace, and environment scope needed for release work. Where possible, separate build, attest, and publish functions so one compromised workflow cannot inherit all three.

Key takeaways

• Shai-Hulud now behaves like a cross-environment NHI worm, not just a package infection.
• The evidence points to rapid credential abuse, broad package spread, and persistence through developer tooling and GitHub workflows.
• The limiting control is not secret rotation alone, but tighter runtime authority across CI, publishing, and local developer execution.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• GitHub Actions cache poisoning: GitHub Actions cache poisoning is a supply chain attack in which an attacker seeds or manipulates cached build artefacts so a later trusted workflow restores and executes malicious content. It exploits trust across workflow stages, especially when cache keys, permissions, and provenance checks are too broad.
• Trusted publisher abuse: Trusted publisher abuse occurs when an attacker hijacks a legitimate publishing workflow that a registry already trusts to release packages. The resulting malicious package can look valid from the registry’s point of view because the compromise happens inside the authenticated delivery path, not only in the package content.
• Tooling persistence drift: Tooling persistence drift describes malware or attacker state moving from a repository or build pipeline into developer tooling such as IDE tasks, hooks, or local configuration files. It matters because opening a project can become a re-infection event even when package installs are blocked.

What's in the full report

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of the TanStack compromise chain across pull_request_target, cache poisoning, and release workflow abuse
• File-by-file indicators showing how the malware persists in .claude and .vscode configuration paths
• Package namespace and versioning patterns that help teams identify downstream compromise faster
• Detection and response notes for runner memory extraction, token theft, and trusted publisher abuse

👉 Semgrep's full post covers the attack chain, persistence mechanisms, and affected package patterns in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build controls that scale across automation, pipelines, and delegated access.