Some threats don’t breach the perimeter. They ride in on your dependencies.

By: Aaron Gilmore — Intergalactic SEM Consultant (humans only so far)

Human-led, Automation-Enhanced. SEM-Artificium

QuickScan

• What this is: A field note on “worm-shaped” software supply-chain attacks tied to Shai‑Hulud / Sha1‑Hulud 2.0 reporting in the npm ecosystem.

• What it means in plain English: If attackers get publisher access (credentials/tokens), they can ship malicious updates through normal package workflows—turning your build/install steps into an execution path.

• Why SEM teams should care: This is a real-world example of third‑party/supply‑chain dependency risk with operational impact (engineering time, incident response, exposure of secrets, and downstream compromise).

• The fastest risk reducer: Lock down publishing and build pipelines: strong auth + least privilege + token hygiene + trusted publishing/OIDC where possible, and rapid secret rotation.

• What you’ll do after reading: Use the checklist-style “first moves” to reduce blast radius for package-manager compromise scenarios.

For Who

Primary audience: DoD/Federal supply chain professionals first; other org security/SEM practitioners second

Best for roles: Security leadership; DevSecOps/AppSec; IR; GRC/C‑SCRM; platform engineering; vendor risk; software program managers

What You’ll Get

You will learn: How package-manager worms propagate (publisher access + automated installs) and where the real choke points are. You will be able to do: Prioritize controls for publisher identity, CI/CD secrets, and install-stage execution risk.

Time & Effort

Read time: ~8–10 minutes

Do time (optional): 30–45 minutes (rapid hardening moves + token/secret hygiene checks)

Difficulty: Intermediate

A worm doesn’t knock. It gets installed.

Executive Snapshot

What happened: A self-replicating malware campaign dubbed Shai‑Hulud abused the npm ecosystem by compromising maintainer identities and publishing trojanized package versions at scale; later variants/waves (often referenced as Sha1‑Hulud / Shai‑Hulud 2.0) expanded scope and accelerated propagation through install‑time execution. (CISA, 2025; Datadog Security Labs, 2025; Microsoft Defender Security Research Team, 2025)

Why it matters: This is a supply‑chain incident class where the attacker doesn’t “break in” the traditional way —they get installed. The downstream risk is credential and secret exposure (cloud keys, CI tokens, registry tokens) that can cascade into customer-impacting compromise. (CISA, 2025; Datadog Security Labs, 2025)

Key lesson: Treat publishing + dependency installs as production-grade control boundaries: identity, secrets, and install-script execution are the choke points.

What to do now:

• Rotate and revoke: hunt for exposed secrets (GitHub repos, CI logs, build artifacts) and rotate immediately. (CISA, 2025; Datadog Security Labs, 2025)

• Lock publishing paths: prefer trusted publishing/OIDC and strong MFA; eliminate long-lived tokens where possible. (GitHub, 2025a; GitHub, 2025b)

• Harden installs: restrict/monitor install lifecycle script execution (especially in CI) and add detections for anomalous publish and repo-creation activity. (Microsoft Defender Security Research Team, 2025)

Opening

In Frank Herbert’s Dune, the Fremen don’t really talk about Shai'‑Hulud, something so large the environment itself has to change before it appears, they just know its there amongst them and acknowledge they must adapt to its' presence or perish.

“Bless the Maker and His water. May His passage cleanse the world.” (Herbert, 1965, as quoted in Wikiquote contributors, n.d.)

That’s the software-supply-chain version of the lesson: a “worm” doesn’t need to smash the gates if your environment makes the gates irrelevant. Long‑lived tokens, permissive publishing rights, and install scripts that run without oversight are the sand that lets the ripple become the worm.

Reader promise: In a few minutes, you’ll understand how Shai‑Hulud‑style package worms propagate and what to harden first in your organization.

What We Know (Verified Facts)

Confirmed facts:

• CISA issued an alert describing a widespread npm ecosystem compromise involving a self‑“‑” affecting 500+ packages and urging immediate defensive actions (credential rotation, GitHub hardening, dependency controls). (CISA, 2025)

• Public reporting and analyses describe worm-like propagation: compromised maintainer identities/tokens enable attackers to publish trojanized versions of legitimate packages, spreading through normal installs. (CISA, 2025; Datadog Security Labs, 2025)

• In the later wave identified around November 24, 2025, researchers reported hundreds of packages being compromised at scale, with secrets exfiltration routed through public GitHub repositories (often created under victim accounts). (Datadog Security Labs, 2025)

• Microsoft’s analysis of Shai‑Hulud 2.0 describes install‑lifecycle execution, including malicious code running during preinstall and use of scripts such as setup_bun.js to stage execution and deploy additional tooling. (Microsoft Defender Security Research Team, 2025)

• GitHub/npm implemented security hardening steps for the ecosystem, including a move away from legacy “classic” npm tokens and reinforcing more secure publishing/authentication approaches. (GitHub, 2025a; GitHub, 2025b)

• Trust Wallet publicly stated high confidence that its Chrome extension v2.68 incident is likely related to the industry‑‑Hulud incident and that exposed developer secrets enabled attacker access to a Chrome Web Store API key. (Trust Wallet, 2025)

Key actors / organizations involved (public): CISA; GitHub/npm; multiple security research teams; organizations whose packages were reported as affected (varies by dataset and time). (CISA, 2025; Datadog Security Labs, 2025; Microsoft Defender Security Research Team, 2025)

What We Don’t Know Yet (Unverified / Evolving)

• Attribution: No widely agreed, high‑confidence public attribution to a specific actor group.

• True scope: Counts vary by time window, dataset, and cleanup actions; “packages compromised” vs “versions published” vs “repos created” can be different denominators.

• Second-order compromise: Secret exposure enables downstream breaches that may never be publicly linked back to Shai‑Hulud.

• Copycats and variants: The playbook is now public; future “worm-shaped” campaigns may reuse techniques with different names.

Timeline

• September 2025: Public disclosures and response activity around the Shai‑Hulud npm worm begin; CISA later publishes an alert covering widespread impact. (CISA, 2025)

• September 23, 2025: CISA releases “Widespread Supply Chain Compromise Impacting npm Ecosystem.” (CISA, 2025)

• November 24, 2025: A major renewed wave/variant (often referenced as Sha1‑‑Hulud 2.0) is identified by multiple security teams. (Datadog Security Labs, 2025)

• December 9, 2025: Microsoft publishes defensive guidance and technical findings for Shai‑Hulud 2.0. (Microsoft Defender Security Research Team, 2025)

• December 9, 2025: GitHub completes the npm classic-token deprecation milestone and announces session-based auth and CLI token management changes. (GitHub, 2025b)

• December 2025: Trust Wallet reports its browser extension incident and links likely relation to Sha1‑Hulud exposure of developer secrets. (Trust Wallet, 2025)

Why This Matters (So What?)

Shai‑Hulud matters because it shows how software supply chain risk becomes operational risk in one hop.

• Dependencies are execution paths. Installing packages is not “downloading data,” it is often running code (install/preinstall/postinstall). This makes the build pipeline a frontline security boundary, not a back-office detail. (Microsoft Defender Security Research Team, 2025)

• Identity + secrets are the real target. Worms like this monetize by stealing credentials and tokens that unlock registries, CI/CD, cloud resources, and distribution channels. (CISA, 2025; Datadog Security Labs, 2025)

• Exposure turns into a race condition. When secrets land in public places (e.g., public repos), containment becomes a sprint—other automated scanners and adversaries can harvest faster than humans can respond. (Datadog Security Labs, 2025)

• This is supply chain governance in action. C‑’s ensuring your acquisition, build, publishing, and monitoring controls reduce blast radius when the ecosystem gets hit. (NIST, 2022)

Figure 1 - “How a Package-Manager Worm Propagates (Shai‑Hulud Pattern)” [Aaron Gilmore] {Flow diagram showing install-time execution stealing secrets, creating public repos, and using compromised publisher access to republish trojanized packages.}

SEM Doctrine Translation

This incident maps cleanly to durable doctrine. The names will change; the controls won’t.

Doctrine concept 1:

Cybersecurity Supply Chain Risk Management (C‑SCRM) - Plain English: You’re exposed to the security posture of upstream ecosystems and suppliers—even when you didn’t “choose” them deliberately (transitive dependencies). Your job is to build governed pathways for acquisition, build, and release so upstream compromise doesn’t become your outage. (NIST, 2022) - Practices that reduce blast radius: - Maintain dependency inventory and criticality tiers (what matters most) - Require provenance/secure build expectations for high‑“” scenarios

Doctrine concept 2:

Secure Software Development Framework (SSDF) - Plain English: Security isn’t a one-time scan; it’s repeatable practices across the SDLC. SSDF emphasizes protecting software components, the build environment, and release/publishing processes. (NIST, 2022a) - Practices that map directly to Shai‑Hulud: - Protect build pipelines (ephemeral runners, least privilege, controlled secrets) - Protect releases (trusted publishing/OIDC, MFA, auditable approvals) - Respond fast (detect anomalous publishing, rotate credentials, coordinate comms)

Scope boundaries (what this incident does not prove): - This does not prove npm is uniquely unsafe—any package ecosystem with broad reuse and weak publisher/secret hygiene can be abused. - This does not mean “never use open source.” It means govern how you consume and publish it.

Figure 2 - “Controls Map: Prevent / Detect / Respond for Package Supply Chains” [Aaron Gilmore] {Three-column control map linking publishing identity controls, CI secrets controls, and install-script governance to prevent/detect/respond actions.}

Lessons Learned (What this incident teaches)

• MFA helps, but token hygiene is where worms cash out. Kill long-lived tokens; scope and rotate what must exist.

• “We don’t publish packages” isn’t immunity. Consumers still execute dependency code in builds.

• CI/CD runners are attack concentrators. One compromised runner can touch many repos and cloud accounts.

• Secrets exposure is a second incident track. Treat it as a separate workstream with its own “done” criteria.

• Hardening the registry helps, but internal controls still matter. You can’t outsource governance to npm/GitHub.

• Pre-approved kill switches matter. Freezing publishing, blocking installs, and forcing rotation should be executable decisions—not debates.

Role-Based Implications (Who should do what)

• Executive Leadership (SES/Flag, CEO/COO/CFO): Treat software supply-chain incidents as business continuity events; require evidence that software release and publishing paths are controlled.

• CISO / Security Leader: Own policy and evidence: developer identity, secrets management, incident response playbooks, and monitoring coverage for developer endpoints/CI.

• Engineering Leadership / Program Managers: Make dependency governance non-optional: version pinning/lockfiles, review gates for dependency changes, and controlled publishing workflows.

• DevOps / Platform: Reduce token sprawl with short-lived/scoped credentials and trusted publishing; harden runners (ephemeral agents, restricted egress where feasible, least privilege identities).

• SOC / Detection & Response: Add detections for anomalous publish events, unexpected public repo creation, and install‑“”

• GRC / C‑SCRM / Vendor Risk: Translate SSDF/C‑SCRM expectations into contractual and internal control requirements; ensure audits include build/release evidence.

• Legal / Compliance / Public Affairs: Pre-stage decision points for exposure reporting and customer notification if distribution channels or secrets are impacted.

What To Do Now (Field Application)

Immediate Actions (24–72 hours)

Action 1: Establish scope — “Are we exposed through installs, builds, or publishing?” - Inventory critical Node/JavaScript projects and CI pipelines. - Identify where npm/GitHub credentials live (developer machines, CI secrets, shared runners). - Confirm whether you publish packages, browser extensions, internal registries, or other artifacts that could become “distribution channels.”

Action 2: Hunt for exposure indicators and rotate secrets - Search for unexpected public repositories created under org/user accounts. - Enable/verify GitHub Secret Scanning alerts and review recent alerts. - Rotate anything potentially exposed: registry tokens, CI tokens, cloud keys, marketplace keys.

Action 3: Freeze high-risk paths until validated (if warranted) - Temporarily pause publishing to public registries/marketplaces for critical scopes. - Restrict CI runners to known-good images; consider isolating builds that touch critical release credentials.

Evidence to capture (what to document/log): - Package publish logs (who/when/version), CI runner logs, secrets-rotation records, list of impacted repos/pipelines, incident timeline, and remediation approvals.

“Done” criteria: - You can answer: which repos/pipelines were exposed, which credentials were rotated/revoked, and which publishing paths are now controlled and auditable.

Short-Term Actions (This week)

• Move publishing to auditable mechanisms: trusted publishing/OIDC where available; strong MFA; least privilege publishing roles. (GitHub, 2025a)

• Replace long‑lived tokens: use scoped/short‑lived tokens; remove tokens from shared runners and dev machine dotfiles where possible.

• Reduce install-time execution risk: constrain where install scripts can run (especially CI); monitor for unexpected lifecycle-script behavior. (Microsoft Defender Security Research Team, 2025)

• Practice the response: run a tabletop: “What if a top dependency is compromised today?” Include engineering, security, legal, and comms.

Note from the Author

I like the Shai‑Hulud metaphor the cyber world chose to name it because it’s honest: you don’t win by arguing with the worm. You win by changing conditions—identity controls, secrets hygiene, and governed release paths—so it can’t turn your normal workflow into its highway. As you can see, this god of a worm is still ravaging the world of package mangers and opensource code bases. It takes a real concerted effort to remove and prevent the god worm from affecting all who use the code it harvests. But when software engineers and organizations choose to ignore and address these very dramatic real world implications, we come to a situation like we are now.....with Shai Hulud freely roaming the land of github..... looking for the patterns its trained to detect and consume, for easy prey.....

References

CISA. (2025, September 23). Widespread supply chain compromise impacting npm ecosystem (Alert). Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem

Datadog Security Labs. (2025). The Shai‑Hulud 2.0 npm worm: Analysis, and what you need to know. https://securitylabs.datadoghq.com/articles/shai-hulud-2.0-npm-worm/

GitHub. (2025a, September 25). Our plan for a more secure npm supply chain. The GitHub Blog. https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/

GitHub. (2025b, December 9). npm classic tokens revoked, session-based auth and CLI token management now available (Changelog). https://github.blog/changelog/2025-12-09-npm-classic-tokens-revoked-session-based-auth-and-cli-token-management-now-available/

Herbert, F. (1965). Dune. Chilton Books.

Microsoft Defender Security Research Team. (2025, December 9). Shai‑Hulud 2.0: Guidance for detecting, investigating, and defending against the supply chain attack. Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending-against-the-supply-chain-attack/

NIST. (2022). Cybersecurity supply chain risk management practices for systems and organizations (NIST SP 800‑1). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/161/r1/final

NIST. (2022a). Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities (NIST SP 800‑218). National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

Trust Wallet. (2025, December 31). Trust Wallet Browser Extension v2.68 incident: An update to our community. https://trustwallet.com/blog/announcements/trust-wallet-browser-extension-v268-incident-community-update

Wikiquote contributors. (n.d.). Dune (Wikiquote page). Retrieved January 18, 2026, from https://en.wikiquote.org/wiki/Dune