Shai-Hulud 2.0: Inside the Most Sophisticated Supply-Chain Attack

Introduction

The Shai-Hulud campaign stands out as one of the most disruptive software supply-chain attacks ever observed, leveraging trusted npm packages and GitHub automation to infiltrate development ecosystems at an unprecedented scale. Instead of relying on social engineering or isolated vulnerabilities, Shai-Hulud 2.0 infiltrated trusted workflows, leveraged automation frameworks, and manipulated package distribution channels to spread with remarkable efficiency. Its two-stage evolution from a package-level worm to a fully automated CI/CD compromise demonstrated how modern development tools can be weaponized when foundational trust is broken.

What this blog will cover:  

• Breakdown of Shai-Hulud's complete intrusion flow - how the malware entered the npm ecosystem, leveraged preinstall scripts and a custom runtime to execute payloads  
• Deep technical analysis of its core capabilities - includes examination of credential harvesting across cloud and CI/CD environments, use of Trufflehog for secret discovery, persistence via GitHub workflows and runners, and its data-exfiltration mechanisms.
• Comprehensive mapping of campaign progression and defensive guidance- details the full timeline from the first worm outbreak to the 2.0 surge, along with methods to detect impacted packages, indicators left on GitHub, and essential remediation steps to contain exposure.

What is Shai-Hulud

Shai-Hulud is a fast-spreading npm supply chain worm that infects JavaScript and Node.js packages by inserting malicious preinstall scripts. The malware spreads through developer workflows and CI/CD pipelines, enabling large-scale automatic infection. It was first identified in September 2025 following the discovery of widespread malicious npm package updates.

The first attack of Shai-Hulud - September 2025 

In its initial wave, Shai-Hulud compromised more than 500 npm packages, including the widely used @ctrl/tinycolor library, along with others, embedding a payload that harvested secrets such as npm and cloud credentials.  

Once installed, the malicious code created a public GitHub repository named “Shai-Hulud,” where it exfiltrated collected credentials, exposing sensitive data and compromising dependent projects.

That wave marked one of the first large-scale, worm-like supply-chain compromises in the open-source ecosystem - showing how a single compromised package could ripple across countless projects through dependencies.  

The Second Coming - Shai-Hulud 2.0  

Just two months later, in late November 2025, Shai-Hulud re-emerged in an evolved, far more aggressive form known as Shai-Hulud 2.0. Unlike the first wave, 2.0 exhibited rapid self-replication, attacking hundreds of npm packages within hours. Shai-Hulud 2.0 expanded its scope massively: analysis shows it has already compromised around 796 npm packages with a combined weekly download count in the tens of millions.

How Did the Shai-Hulud 2.0 npm Supply Chain Attack Work?

Shai-Hulud emerged as an advanced supply chain worm, rapidly escalating from a simple package install to a multi-stage compromise. Let's breakdown the attack into key phases to understand how it infiltrated, propagated, and persisted.  

Initial infection phase

The initial infection phase of the Shai-Hulud 2.0 attack relied on a stealthy multi-stage loading process triggered during the preinstall phase of a compromised npm package. Threat actors embedded a modified manifest file containing a preinstall script that executed setup_bun.js, which appeared to install the Bun JavaScript runtime but was instead used to prepare the malware execution environment.  

By switching from Node.js to Bun - a runtime that was not commonly monitored by security tools - the attackers effectively bypassed conventional detection mechanisms.  

Once Bun was deployed, it launched a heavily obfuscated 10MB payload named bun_environment.js, enabling execution at an early stage before typical build or runtime protections were engaged. This “bring your own runtime” technique gave attackers an initial foothold inside development or CI/CD environments by operating outside standard inspection pathways.

Credential harvesting - How Shai-Hulud Extracted Secrets

Once executed, the malware immediately activated an automated secret collection routine designed to target high-impact credential sources commonly used by developers and CI/CD systems.  

It first identified GitHub access tokens by scanning environment variables and CLI configurations, specifically targeting formats such as ghp_(personal access tokens) and gho_(OAuth tokens). In addition, it retrieved npm publishing tokens from .npmrc files and CI/CD environment variables.  

To expand beyond local credentials, the malware leveraged cloud provider SDKs to enumerate secrets associated with AWS, GCP, and Azure, investigating paths such as configuration folders and metadata endpoints.  

It enhanced its discovery capabilities by downloading and executing Trufflehog to perform recursive filesystem scanning, identifying secrets within configuration files, source repositories, .env files, and git history using:

• High-entropy detection mechanisms
• Pattern matching, including formats like AKIA[0-9A-Z]{16} for AWS keys

Finally, it captured the full runtime environment (process.env), allowing theft of transient tokens, for example:

• GITHUB_TOKEN ‍
• AWS_ACCESS_KEY_ID

This unified approach enabled the malware to collect a broad range of credentials in a single execution phase, granting potential access to cloud environments, package distribution systems, and developer accounts for further exploitation.

Persistence Mechanism

Following credential extraction, the malware established long-term persistence through multiple GitHub-centric techniques designed to survive cleanup and package removal.  

• It injected a malicious GitHub Actions workflow .github/workflows/shai-hulud-workflow.yml, delivered via a base64-encoded Bash script.  
• The workflow was configured to run on push events and used the following expression to collect and transmit credentials allowing for full repository secret exposure to a command-and-control endpoint.  
• To preserve presence within the repository the malware force-created branches using the GitHub API:
  • refs/heads/shai-hulud, via the /git/refs endpoint, bypassing standard version control protections.

• In addition to modifying repository workflows, it registered compromised machines as self-hosted GitHub runners, enabling attackers to trigger arbitrary workflows remotely even if the malicious package was removed later.

Data Exfiltration

For exfiltration, the malware leveraged stolen GitHub tokens to create public repositories marked with the description "Shai-Hulud: The Second Coming" using them as dropboxes for stolen credentials and system metadata. Harvested secrets were consolidated into a prettified JSON payload often saved as actionsSecrets.json and uploaded via the GitHub /user/repos API.

If the initial token had insufficient permissions, the malware searched for other repositories sharing the same signature to retrieve alternate tokens, effectively forming a resilient token-sharing network across compromised systems.  This process occurred exclusively on macOS and Linux environments, as the malware explicitly bypassed Windows systems.  

By abusing GitHub's legitimate infrastructure for data transmission, the attackers bypassed conventional network security controls, ensuring reliable external access to high-value secrets.  

Post-Exfiltration actions:  

After data exfiltration, the Shai-Hulud attack transitions into a post-compromise control and expansion phase, where the adversary operationalizes stolen credentials to maintain persistence and enable broader compromise.

• Token-Based Remote Control: Using harvested GitHub tokens, the attacker interacts with GitHub APIs to create or modify repositories and workflows, enabling remote task execution without the need for system-level access.
• Distributed Credential Sharing: If an initial token lacks privileges, the malware queries other compromised repositories marked with “Sha1-Hulud: The Second Coming” to retrieve alternate tokens, effectively creating a decentralized credential pool.  
• Workflow Reinfection Capability: Attackers use valid GitHub credentials to insert or re-enable malicious workflow files (.yml) across multiple repositories. This allows repeated execution of payloads in CI/CD pipelines.
• Lateral Movement Through Cloud & DevOps: Stolen cloud credentials (AWS, GCP, Azure) and CI/CD tokens enable pivoting into associated infrastructure, potentially allowing manipulation of build environments, pipeline triggers, or deployment stages.
• Supply Chain Reinsertion: With valid publishing tokens (e.g., npm), the attacker can republish malicious package updates, enabling recursive compromise through downstream dependency chains.
• Failsafe Destruction Trigger: The malware includes functionality to wipe local files or terminate execution if sandboxing or containment is detected, hindering incident response and forensic recovery.  

Operational phase:

Following successful credential harvesting and persistence, Shai-Hulud entered its operational phase, executing actions explicitly designed to manipulate software supply-chain workflows. Using stolen GitHub PATs, OAuth tokens, and npm publish tokens, the malware programmatically interacted with GitHub’s REST API to modify repository metadata, create new repositories, and alter branch references via the /git/refs endpoint. These modifications enabled unauthorized push events and automatic execution of attacker-controlled workflow files.

Shai-Hulud leveraged organization-level or high-scope GitHub tokens to enumerate repositories, extract their CI/CD configurations, and inject rogue workflow definitions into .github/workflows/, allowing arbitrary command execution within build environments. Tokens associated with npm publishing rights allowed the malware to republish package versions containing tampered manifests, modified lifecycle scripts, or embedded payloads creating downstream compromise vectors for developers installing updated dependencies.

Additionally, the malware used harvested cloud-provider secrets to query AWS Secrets Manager, Google Secret Manager, and Azure credential stores. This access enabled environment takeover of CI/CD runners, credential re-use, and privilege escalation across cloud tenants. By coordinating repository tampering with automated workflow execution, Shai-Hulud established a self-reinforcing infection cycle where compromised pipelines continued distributing malicious artifacts even after initial removal.

This combination of API-level manipulation, build-pipeline hijacking, and unauthorized package publication reflects a deliberate supply-chain compromise strategy, one aimed at systemic contamination rather than single-environment persistence.

Impact and Strategic outcome

After achieving supply-chain manipulation, Shai-Hulud transitions into its endgame: leveraging stolen secrets, poisoned repositories, and compromised CI/CD pipelines to enable high-impact operational outcomes. The malware’s access to GitHub PATs, organization tokens, and cloud service credentials gives attackers the ability to:

• Escalate privileges within GitHub organizations and cloud tenants ‍
• Modify or backdoor software packages intended for public or internal distribution ‍
• Disrupt CI/CD workflows, halting deployments or injecting malicious code into builds ‍
• Perform lateral movement across developer environments and infrastructure ‍
• Establish long-term supply-chain persistence, even after initial indicators are removed

By poisoning dependencies and pipelines, Shai-Hulud creates a mesh-style infection network where compromised builds lead to more compromised developers, enabling repeated reinfections and downstream propagation. The strategic impact extends beyond individual victims; threat actors gain leverage over entire ecosystems relying on the contaminated packages.

Cleanup, Evasion & Anti-Forensics

After completing credential harvesting and supply-chain manipulation, Shai-Hulud executed several cleanup and evasion routines designed to suppress forensic visibility and complicate incident response. The malware first validated its execution environment, avoiding Windows hosts entirely and terminating when sandbox indicators such as abnormal system clocks, reduced CPU cores, or virtualized hardware profiles were detected. If containment or debugging attempts were identified, the malware triggered a destructive failsafe capable of wiping selected local files to hinder reverse engineering.

To minimize artifacts, the loader removed transient files created during execution, including staged runtime components and temporary Bun-related directories. Injected GitHub Actions workflow files were obfuscated by encoding workflow logic in base64 and writing it through shell scripts, making detection in code reviews less straightforward. The malware also deleted intermediate payloads, cleaned npm lifecycle traces, and suppressed console output during execution to reduce observable behavioral indicators.

Shai-Hulud further blended into legitimate developer activity by routing exfiltration through GitHub’s API, relying on encrypted HTTPS traffic indistinguishable from standard repository operations. Token reuse across compromised repositories added another layer of operational confusion, making it difficult for responders to isolate a single compromised endpoint. In effect, the malware combined stealthy runtime behavior with deliberate anti-forensic techniques, enabling prolonged dwell time and complicating post-incident reconstruction.

How to Identify Impacted Libraries and Projects in Shai-Hulud 2.0

Shai-Hulud 2.0 introduced multiple indicators that can be used to determine whether a project or dependency has been compromised. Because the malware contaminates npm packages, GitHub repositories, and CI/CD pipelines, defenders need to check across the entire development lifecycle. The following technical methods help reliably identify affected libraries and environments:  

1. Check modified package.json files: Look for unexpected preinstall scripts (e.g., setup_bun.js) or lifecycle hooks that do not present in prior versions.
2. Look for Bun runtime artifacts: The presence of large, obfuscated files like bun_environment.js or unexpected Bun binaries indicates tampering.
3. Audit GitHub Actions workflows: Identify newly added or altered workflows, especially base64-encoded YAML files under .github/workflows/.
4. Detect unauthorized self-hosted runners: Unexpected GitHub runners registered in an organization signal compromised developer machines.
5. Search for malware-created repositories: Public repos with descriptions like “Sha1-Hulud: The Second Coming” confirm active exfiltration.
6. Scan for malware-generated JSON files: Files such as cloud.json, contents.json, and truffleSecrets.json on developer systems indicate successful credential harvesting.
7. Review npm publish logs: Unauthorized publishes, unexpected version increments, or publishing from unusual IPs suggest a poisoned package.
8. Check CI/CD logs for TruffleHog execution: TruffleHog running outside approved workflows indicates automated secrets extraction by the malware.
9. Inspect repositories for forced branch updates: Sudden creation or rewriting of branches via the /git/refs API (e.g., branches named shai-hulud) signals manipulation.
10. Analyze dependency trees for suspicious payloads: Large binary blobs inside node_modules, unexpected new dependencies, or unusual SBOM diffs indicate compromise.

Shai-Hulud Attack Timeline

Final Takeaway: The True Impact of Shai-Hulud

Shai-Hulud demonstrates that modern supply-chain attacks no longer unfold as isolated incidents; they evolve, adapt, and scale with alarming precision. What began as a worm-style infection has matured into an automated ecosystem attack capable of rewriting pipelines, republishing poisoned packages, and silently compromising developer trust boundaries. Its progression illustrates a fundamental truth: the security of the software ecosystem is only as strong as its weakest maintainer, its most outdated dependency, or its least-monitored CI system. As attackers increasingly target the connective tissue of development workflows, organizations must treat dependency oversight, credential hygiene, and supply-chain telemetry as first-class security requirements. The Shai-Hulud incident serves not just as a warning, but as a blueprint for how quickly a single compromise can cascade across an entire ecosystem making resilience, visibility, and continuous verification essential pillars of modern software defense.

FAQs:

Q) What are npm packages?

A) npm packages are modular pieces of JavaScript code distributed through the Node Package Manager ecosystem. Developers use them to add functionality without rewriting common features. Because they are widely reused, compromising one package can impact thousands of downstream projects.

Q) Why were cloud provider credentials specifically targeted?

A) Cloud credentials often grant high-privilege access to compute, storage, secrets managers, and CI systems. By harvesting AWS, Azure, and GCP keys, the malware enabled lateral movement into cloud infrastructures and expanded control beyond the developer environment.

Q) Can Shai-Hulud spread without user interaction?

A) Yes, once a developer installs an infected package, the malware executes automatically through lifecycle hooks. From there, it propagates by publishing modified packages or manipulating repositories connected to compromised tokens.

Q) Why are public developer tokens so valuable in this attack?

A) Developer tokens grant access to repositories, CI environments, and package registries. Once stolen, they allow attackers to publish trojanized packages, alter source code, and pivot across entire organizations, amplifying damage far beyond the initial infection.  

Q) Why did the attackers use the Bun runtime instead of Node.js?

A) Bun allows the malware to execute outside the usual Node.js monitoring paths, bypassing many static analysis and runtime security tools. This “bring-your-own-runtime” technique increases stealth and makes detection significantly harder.