Shai-hulud shows how MCP and GitHub become worm channels

At a glance

What this is: NHI Mgmt Group's analysis, drawing on OXSecurity's research: A new Shai-Hulud wave used npm, GitHub, and MCP-linked delivery paths to spread infected developer workflows, with over 440 packages compromised and thousands of credential dumps still exposed days later.

Why it matters: It matters because developer tooling, repository cloning, and local agent settings are now part of the attack surface, so IAM and NHI teams need to govern tokens, session keys, and repository trust as live controls.

By the numbers:

• Over 440 unique npm packages were compromised in the latest Shai-Hulud wave.
• More than 3,800 public GitHub repositories containing exfiltrated credential dumps remained publicly accessible and searchable.

Context

Shai-Hulud is a self-propagating software supply chain worm that turns trusted developer workflows into delivery paths for malicious code and stolen credentials. In this case, the attack chain moved through npm packages, GitHub repositories, and MCP-related tooling, which means the practical problem is not just malware detection but governance over developer trust, local execution settings, and non-human credentials.

The article shows a control gap that many teams still underestimate: repository access and agent-style tool integration are often treated as low-risk convenience layers, even though they can execute code, read secrets, and propagate compromise. For IAM, PAM, and NHI programmes, the intersection is clear, because tokens, session keys, and service credentials are the objects being harvested and reused.

The starting position described here is increasingly typical for modern supply chain attacks, not an outlier. Adversaries are abusing the routine act of cloning code and the routine presence of machine credentials inside developer environments, which makes governance at issuance and execution time more important than after-the-fact cleanup.

Key questions

Q: What breaks when repository task files are allowed to auto-execute in developer tools?

A: The main failure is that code review and execution become the same event. A malicious task file can run a downloader or shell command as soon as the project opens, which gives attackers a path into the developer session before any human approval, package inspection, or malware review can intervene.

Q: Why do stolen developer tokens and standing access make software supply-chain attacks so hard to contain?

A: Stolen maintainer tokens turn a single compromise into a distribution problem. Attackers can publish malicious package versions, republish through trusted ecosystems, and move laterally into cloud, CI, and secrets stores. Standing access increases the blast radius because the attacker can act quickly before defenders detect the abuse and revoke credentials.

Q: What are the signs that a repository-based worm is still active?

A: Repeated payload markers, new repositories created from compromised accounts, and searchable credential-dump artefacts are the clearest signs. If infected settings files, linked repos, or exfiltrated JSON dumps remain publicly accessible after takedown, the campaign is still propagating through residual trust paths.

Q: How should teams respond when an MCP-linked repository is implicated in malware delivery?

A: They should isolate any environment that opened the repository, revoke related tokens and session keys, and inspect every linked tool or workspace file for hidden execution logic. The immediate priority is to cut off identity reuse and prevent the same trust path from spawning new compromise.

Technical breakdown

How Shai-Hulud turns repositories into execution paths

The worm works by placing malicious instructions inside repository settings files that developer tools will process automatically or with minimal prompting. In this case, Claude Code and VS Code settings became the execution surface, so opening or cloning a repository was enough to trigger the malicious workflow. That matters because the attack does not need a traditional exploit chain against a server. It abuses the trust boundary between source code, local workspace configuration, and developer tooling. Once the repository is trusted, the payload can harvest secrets, create new infected repos, and keep spreading through ordinary collaboration habits.

Practical implication: Treat repository cloning and workspace configuration as code execution events, not benign developer activity.

Why MCP registry exposure changes the supply chain model

Model Context Protocol registries create a new distribution layer for tools and integrations that can sit between developers and their working environments. If a public MCP entry links to a clean package but a malicious repository or workspace file sits behind it, static package scanning alone will miss the real threat. The important shift is that the trust decision moves from the package artifact to the connected toolchain and its linked resources. That creates a governance problem for AI coding assistants and agentic tooling, because the surrounding configuration can carry the malicious intent even when the published package itself looks safe.

Practical implication: Extend trust validation beyond package contents to linked repositories, registry metadata, and workspace configuration.

Why stolen tokens and session keys make the worm self-propagating

Shai-Hulud is not just an infection event, it is a credential harvesting and re-use event. The payload targets developer tokens, cloud credentials, and session keys, then uses those secrets to spawn new infected repositories under compromised accounts. That is classic non-human identity abuse: the machine credentials become the propagation mechanism, not merely the prize. Once those secrets are available, the worm can continue operating even after the original package is removed, because the compromised identity can create new publishing or repository activity without needing fresh human interaction.

Practical implication: Assume every exposed token or session key can become both access and distribution infrastructure.

Threat narrative

Attacker objective: The objective is persistent, self-propagating access to developer environments and downstream software distribution channels through stolen machine and cloud credentials.

1. Entry occurred when developers cloned or opened repositories carrying malicious Claude Code or VS Code settings files linked through npm, GitHub, or an MCP server entry.
2. Credential harvesting followed as the payload collected developer tokens, cloud credentials, and session keys from the local environment.
3. Propagation and escalation occurred when compromised maintainer accounts automatically spawned new infected repositories and redistributed the malware under the same signature pattern.
4. Impact was the continued spread of a supply chain worm that left thousands of credential dumps publicly exposed and extended the blast radius across downstream projects.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Developer trust has become a live attack surface. Cloning repositories, opening workspace settings, and accepting tool prompts now carry security weight comparable to executing unvetted code. The old assumption that source code is passive is no longer valid when repository metadata and local IDE settings can trigger secret theft and propagation. Practitioners should treat developer workflow controls as part of the identity and execution boundary, not as convenience features.

The named concept here is repository-to-runtime propagation: a trust failure where a source repository influences local execution and then uses harvested credentials to spread further. That pattern is broader than npm and GitHub, because any developer platform that links code, local settings, and authentication material can become a worm channel. The governance lesson is that inspection must include the link between artifact, tool, and credential, not just the artifact itself. Practitioners should map that propagation path explicitly and narrow every trust hinge.

MCP increases the need for identity-aware tool governance. When a registry entry can point into repositories, local settings, or agent-adjacent tooling, the security model extends beyond package hygiene. The question is no longer only whether the package is malicious, but whether the connected toolchain can execute hidden behaviour using non-human credentials. That makes OWASP-NHI-style thinking relevant to developer tooling: inventory the machine identities in play, know who can mint or reuse them, and assume those secrets are part of the attack surface. Practitioners should govern tool-to-tool delegation as seriously as human access.

Platform cleanup lag changes the acceptable risk threshold. The article’s live-repository findings show that automatic takedown and signature detection are not keeping pace with worm propagation. That means response expectations cannot rely on the platform removing infected material before it is consumed. In governance terms, the control objective shifts from after-the-fact removal to preventing trusted execution paths from accepting unverified repositories or credentials in the first place. Practitioners should design for delayed platform response rather than assume near-real-time containment.

The supply chain problem is now identity-led as much as code-led. The attackers are not only shipping malware, they are abusing stolen maintainer identities and session material to keep the malware alive. That creates a direct overlap between software supply chain security and non-human identity governance, because the same tokens that publish, access, and automate workflows are also the tokens that propagate compromise. Practitioners should align build and publishing controls with credential lifecycle governance, or the worm will keep finding fresh identities to abuse.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: OWASP Agentic Applications Top 10

What this signals

Repository cloning is now an execution decision. The attack shows that developer convenience features can trigger credential theft and propagation without a traditional exploit against production systems. IAM and NHI teams should treat workspace settings, session keys, and maintainer identities as part of the same control plane.

Repository-to-runtime propagation: when a source repository influences local execution and then uses stolen credentials to spread further, the control failure is at trust assignment, not just malware detection. That means the security boundary needs to move to issuance time, not after code has already been opened or cloned.

The blast radius grows when compromised identities can spawn new repositories faster than platform takedown can remove them. According to the State of Secrets Sprawl 2026, 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, which is a reminder that non-human systems are often the propagation layer.

For practitioners

• Harden developer workspace execution paths Block automatic execution from repository settings files, and require explicit approval before Claude Code, VS Code, or similar tools can load untrusted workspace configuration.
• Inventory and rotate exposed machine credentials Assume developer tokens, cloud credentials, and session keys in infected environments are compromised, then revoke and re-issue them through controlled identity lifecycle processes.
• Separate package trust from repository trust Validate linked repositories, registry entries, and workspace files independently so a clean package cannot hide malicious behaviour in adjacent configuration.
• Monitor for worm signature reuse Search for repeated payload markers such as the Shai-Hulud signature string and the results-.json credential-dump pattern across public and internal repositories.
• Contain maintainer-account propagation Review any account that can publish, fork, or auto-spawn repositories, because compromised maintainer identities turn cleanup delays into additional spread.

Key takeaways

• Shai-Hulud now operates as a software supply chain worm that uses developer workflows, repository settings, and stolen machine credentials to keep spreading.
• The article’s evidence shows that cleanup lag matters because malicious repositories and credential dumps can remain live after infection has begun.
• The practical control point is trust assignment at execution time, which means governing workspace loading, token reuse, and maintainer identities as one problem.

Key terms

• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
• Repository-To-Runtime Propagation: Repository-to-runtime propagation occurs when code stored in a repository influences local execution on a developer machine or build system. The danger is that configuration, settings, and linked tools can execute malicious behaviour before security controls see the payload as active malware.
• Workspace Configuration Poisoning: Workspace configuration poisoning is the insertion of malicious instructions into files that developer tools read automatically, such as IDE or agent settings. It weaponises normal project setup files so that opening a repository can trigger secret theft, code execution, or further spread.
• Non-Human Credential: A non-human credential is a secret used by software, automation, or an AI agent to authenticate or act on a system’s behalf. Examples include API keys, tokens, certificates, and service account secrets. These credentials need lifecycle governance because they often persist beyond the human task that created them.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect machine identity controls, access governance, and operational risk across modern environments.