Shai-hulud shows how MCP and GitHub become worm channels

At a glance

What this is: OXSecurity reports that the Shai-Hulud supply chain worm is still active, using npm, GitHub, and MCP distribution paths to harvest credentials and propagate through infected repositories.

Why it matters: This matters because developer tooling, package trust, and repository cloning now create identity and secrets exposure risk, so IAM and NHI teams need controls that assume code execution can trigger credential theft.

By the numbers:

• A new evolution of the Shai-Hulud self-propagating worm compromised over 440 unique npm packages, reaching downstream projects with an estimated total of over 2 billion monthly downloads.
• 3,800+ public GitHub repositories containing exfiltrated credential dumps remain publicly accessible and searchable.
• Two malicious npm packages stayed live for 72 hours after initial infection in the npm registry.

👉 Read OXSecurity's analysis of the Shai-Hulud worm, MCP abuse, and active GitHub exposure

Context

Shai-Hulud is a software supply chain worm, meaning compromised code or package metadata can spread automatically into downstream development environments. In this case, the attack chain is especially relevant to identity security because the payload targets developer tokens, cloud credentials, and session keys, turning routine repository trust into a secrets exposure problem.

The article also shows why conventional platform moderation and malware scanning are not enough on their own. When malicious repositories remain live, infected settings files execute inside IDEs and AI coding tools, which means NHI governance has to extend to developer workflows, local tool permissions, and the credentials that agents and humans use to build software.

Key questions

Q: How should security teams prevent AI coding tools from turning cloned repositories into execution paths?

A: Security teams should treat cloned repositories as untrusted execution inputs and gate any workspace settings, post-clone scripts, or agent-triggered actions behind review and allowlisting. The key is to block silent execution from files that look like configuration but behave like code. That approach reduces the chance that developer convenience becomes an infection trigger.

Q: Why do developer secrets make supply chain incidents much harder to contain?

A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.

Q: What do security teams get wrong about MCP plugin risk?

A: Teams often treat plugins as if they were ordinary extensions, when in practice they can become trust-bearing execution components. If a plugin can influence tool output or run commands, it must be validated, scanned, and constrained before use. The mistake is assuming registry presence equals legitimacy.

Q: How should organisations respond when malicious repositories are still live after detection?

A: They should assume the exposure window is still open, rotate any secrets that may have been harvested, and isolate developer accounts that could have been used for propagation. The practical test is whether the organisation can invalidate affected credentials faster than the attacker can reuse them. That is the difference between detection and containment.

Technical breakdown

How Shai-Hulud turns repository trust into execution

The worm uses the normal developer action of cloning or opening a repository as the execution trigger. In this case, malicious instructions were embedded in local workspace settings files such as .vscode/settings.json and .claude/settings.json, which can cause an IDE or coding assistant to run attacker-controlled behavior without a traditional exploit. That matters because the attack does not need a vulnerability in the package itself if the workflow already trusts repository content. The registry component can look clean while the repository payload carries the real infection mechanism.

Practical implication: Treat repository-open events and workspace configuration changes as security-relevant execution paths, not harmless developer convenience.

Why MCP creates a new supply chain exposure surface

Model Context Protocol connects AI tools to external data and services, so a malicious MCP server can become a bridge between trusted developer tooling and hidden payload delivery. Here, the official registry entry pointed to a clean package while the linked GitHub repository held the malicious instructions, which creates a two-step trust problem: registry approval and repository inspection can both miss the real risk. That is a governance issue as much as a malware issue, because the AI toolchain becomes part of the software supply chain.

Practical implication: Add control points for MCP server onboarding, repository provenance, and tool permission review before AI coding assistants can interact with new sources.

How credential harvesting becomes worm propagation

Once the payload runs, it looks for developer tokens, cloud credentials, and session keys. Those secrets let the attacker both exfiltrate data and continue propagation through compromised maintainer accounts, which explains how the worm can automatically spawn new infected repositories. This is a classic identity abuse pattern inside a modern software delivery environment: the stolen secret is not just the prize, it is the next authenticated foothold. The result is self-reinforcing spread across code, cloud, and developer identity domains.

Practical implication: Assume every exposed developer secret can become a propagation mechanism and constrain blast radius with short-lived credentials and scoped tokens.

Threat narrative

Attacker objective: The attacker aims to steal usable developer and cloud credentials, then use them to propagate the worm across more repositories and build a larger authenticated supply chain foothold.

1. Entry begins when a developer clones or opens a repository containing malicious workspace settings that trigger the payload inside an IDE or AI coding tool.
2. Credential harvest follows as the worm searches for developer tokens, cloud credentials, and session keys that can be reused for authenticated access.
3. Escalation occurs when compromised maintainer accounts automatically publish new infected repositories and keep the propagation loop active.
4. Impact is widespread supply chain spread, credential exposure, and downstream compromise across projects that trust the infected packages and repositories.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Developer tooling has become an identity attack surface. The article shows that repository cloning, workspace settings, and AI coding assistants can execute attacker-controlled instructions and expose secrets without a classic vulnerability exploit. That shifts the control problem from code review alone to identity-aware trust in development workflows. Practitioners should treat local developer tooling as part of the NHI and secrets governance boundary.

Shai-Hulud is a credential propagation worm, not just a package compromise. The real risk is not only malware execution but the reuse of stolen developer tokens, cloud credentials, and session keys to keep the campaign moving. This is a named failure mode worth tracking because it shows how one compromised identity can become a distribution engine for more compromise. Practitioners should design for short-lived, scoped credentials that lose value quickly.

MCP registry trust needs provenance controls, not just publication controls. A clean package reference can hide a malicious repository payload, which means registry metadata alone is insufficient for risk decisions. The named concept here is MCP trust gap, where a trusted discovery layer masks an untrusted execution layer. Practitioners should require tool provenance checks before MCP servers are allowed into developer or agent workflows.

Platform latency becomes an operational security variable. If malicious repositories remain live for hours or days, attacker dwell time expands even after detection. That makes automated removal, takedown speed, and incident response cadence part of the control environment, not just platform hygiene. Practitioners should measure how quickly their own controls can isolate exposed secrets when public repositories are discovered.

Software supply chain defense now has to include NHI lifecycle discipline. Developer tokens, cloud access keys, and session credentials behave like non-human identities when they can authenticate, propagate, and persist across environments. The governance question is whether those identities are discoverable, short-lived, and revocable fast enough to matter. Practitioners should align supply chain monitoring with NHI inventory and rotation policies.

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: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• For a deeper governance angle: Review The 52 NHI breaches Report for breach patterns that show how stolen secrets, overprivilege, and weak rotation turn one compromise into many.

What this signals

MCP trust gap: development teams should now assume that registry approval, package cleanliness, and repository trust are separate control questions. The practical programme shift is to combine provenance review, tool permissioning, and secret scoping, because AI coding environments can execute content that ordinary package scanning will not catch.

The operational signal for security teams is faster secret invalidation, not better retrospective cleanup. Once developer credentials appear in public artefacts, the compromise window can close in minutes, so containment playbooks need to prioritise token revocation, account review, and repository triage before propagation continues.

This pattern also strengthens the case for treating developer access artefacts as NHI inventory. Secrets attached to build systems, assistants, and maintainer workflows need the same lifecycle discipline as any other machine identity, including discovery, rotation, and offboarding.

For practitioners

• Harden repository-open trust decisions Block automatic execution from cloned repositories unless workspace settings, post-clone hooks, and agent actions are explicitly reviewed. Treat .vscode/settings.json and .claude/settings.json as executable risk inputs, not benign configuration files.
• Inventory and rotate developer secrets aggressively Find developer tokens, cloud credentials, and session keys that can authenticate into build and cloud systems, then move them to short-lived, scoped credentials with rapid revocation paths.
• Add MCP onboarding controls Require provenance checks for MCP servers, inspect linked repositories for malicious settings files, and gate new tool access behind an allowlist process before coding assistants can consume them.
• Monitor for credential dump exposure Search for leaked secrets in public code, issue trackers, and repository artefacts, and treat results-*.json style dumps as an active incident signal that requires containment and rotation.
• Measure removal latency across platforms Track how long malicious packages and repositories remain reachable after detection, because platform delay directly extends the window in which stolen credentials can be reused.

Key takeaways

• Shai-Hulud demonstrates that software supply chain worms now exploit identity and secrets, not just code dependencies.
• The scale is material: more than 440 npm packages were compromised, with downstream reach estimated at 2 billion monthly downloads.
• Practitioners should harden repository trust, shorten secret lifetime, and treat MCP and IDE settings as governance-controlled execution paths.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Developer Secret: A developer secret is a credential used to access code, services, or infrastructure, such as an API key, SSH key, token, or certificate. In practice, it becomes an identity artifact when it can authorize action, not just authenticate a person. Its risk lies in spread, reuse, and weak revocation.
• Authorization Propagation: Authorization propagation is the time it takes for a membership or role change to become effective across the systems that enforce access. In practice, it determines whether the policy state and the runtime state agree. Slow propagation creates stale access windows that identity teams must treat as a governance risk, not a convenience issue.

What's in the full report

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• Repository-level evidence showing which infected GitHub projects remained active days after infection
• The exact malicious settings-file pattern used to trigger Claude Code and VS Code execution
• The live MCP server path that linked a clean package to a malicious repository payload
• The authors' detection and takedown observations across npm and GitHub

👉 The full OXSecurity post covers the infected repository patterns, MCP delivery path, and remaining live artefacts.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management with a focus on practical controls for modern identity risk. It helps practitioners build the baseline needed to manage machine credentials, service access, and emerging agentic AI identity concerns across the programme.