TL;DR for engineering teams on Sha1-Hulud V3.0
- If @vietmoney/react-big-calendar@0.26.2 ever touched a laptop, CI agent, or build container, treat it as a compromise event: rotate credentials reachable from that environment and audit GitHub and cloud activity.
- This is “code execution on install,” not a typical vulnerability. It runs through npm lifecycle scripts, steals secrets, then tries to turn stolen npm/GitHub tokens into more infected packages and leaked repos.
- The current 3.0 sample appears to have been caught early (hundreds of downloads, no confirmed large-scale spread reported), but the same actor lineage already scaled to hundreds of packages and tens of thousands of GitHub repos in prior waves.
Technical anatomy of Sha1-Hulud V3.0
Sha1-Hulud 3.0 (also tracked as Shai-Hulud 3.0) shows up as a malicious update to an existing npm package. The payload triggers via lifecycle execution, then pivots to secret collection and exfiltration.
Entry point: lifecycle execution launches bun_installer.js (new name in 3.0).
Main payload: the primary payload lives in environment_source.js (also newly renamed in 3.0).
Why install-time matters?
Install-time execution happens where the best secrets live: developer shells, CI/CD runners, build containers, and release automation. That’s why a “small” npm package can still become a big supply chain incident.
Core behaviours of Sha1-Hulud V3.0
1) Secret harvesting with TruffleHog
The malware uses TruffleHog-style scanning to scrape credentials and sensitive material from the environment. Sha1-Hulud V3.0 also improves timeout handling, which is a polite way of saying it fails less often in real CI.
2) Exfiltration to attacker-controlled GitHub repos (Sha1-Hulud V3.0 variation)
This strain continues the same pattern: stolen data gets written into files, then pushed into GitHub repositories the attacker controls or creates using stolen tokens. In Sha1-Hulud V3.0, the repo description changed to “Goldox-T3chs: Only Happy Girl.”
3) Worm-style propagation using npm tokens
The scary part is not the initial package. It’s the “turn one token into many infected packages” loop. Prior waves used compromised maintainer accounts to push malicious versions broadly across that maintainer’s portfolio, compounding impact fast.
4) Operational changes in Sha1-Hulud V3.0
- Dead-man switch removed (a prior variant included destructive behavior when it couldn’t find tokens to abuse).
- Windows publishing logic was fixed (3.0 accounts for bun.exe), improving cross-platform reliability.
- A defender-friendly mistake: it tries to fetch c0nt3nts.json but saves c9nt3nts.json. That mismatch is an IOC gift.
Affected Versions by Sha1-Hulud V3.0
Confirmed malicious (Sha1-Hulud 3.0): @vietmoney/react-big-calendar@0.26.2
Notes on scope and “installation base”
- Public reporting tied the malicious update to December 28, 2025 and recorded hundreds of downloads for this package version. That’s not mass exploitation, yet it’s enough for a real incident if even one CI runner held strong credentials.
- Prior waves hit hundreds of npm packages and 25,000+ GitHub repositories in short order. That history is why 3.0 must be treated as critical even when the first sample looks “small.”
| Discovery | Version | Root | Library | Version | Discovery |
| 29-Dec | @vietmoney/react-big-calendar@0.26.2 | @vietmoney | react-big-calendar | 0.26.2 | NEW FINDING |
| 25-Nov | @nativescript-community/perms@3.0.9 | @nativescript-community | perms | 3.0.9 | NEW FINDING |
Discovery and Disclosure Timeline for Sha1-Hulud
- September 2025: First major Shai-Hulud wave: self-replicating npm supply chain compromise, secret theft, GitHub repo exposure patterns.
- Nov 21–23, 2025: Sha1-Hulud: The Second Coming: preinstall execution using Bun, rapid spread, broad repo exposure.
- Dec 28–29, 2025: (this) Sha1-Hulud 3.0 identified in @vietmoney/react-big-calendar@0.26.2, new filenames and repo branding observed.
- January 2, 2026: (this) Ongoing monitoring and reporting continues across vendors; the current public consensus still frames Sha1-Hulud 3.0 as a limited spread so far.
Determine If You’re Affected by Sha1-Hulud V3.0 – Indicator of compromise
The Shai Hulud campaign is characterised by several distinct Indicators of Compromise (IOCs) that have evolved across its different waves. Primary malicious payloads include files such as bundle.js (frequently identified by the SHA-256 hash 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09), and later iterations like bun_installer.js, environment_source.js, setup_bun.js, and bun_environment.js. Persistence is typically established through the creation of a branch named shai-hulud and the injection of GitHub Actions workflows, specifically at paths like .github/workflows/shai-hulud-workflow.yml or .github/workflows/discussion.yaml.
Data exfiltration often targets webhook.site endpoints or attacker-controlled repositories; in the third wave, these repositories are identified by the description “Goldox-T3chs: Only Happy Girl” and contain leaked secret files named 3nvir0nm3nt.json, cl0vd.json, and pigS3cr3ts.json. Technical signatures of an active infection also include suspicious process behaviours such as npm publish –force, the registration of a self-hosted runner named SHA1HULUD, and the automated invocation of TruffleHog for filesystem scanning. Furthermore, related infrastructure has been linked to domains like metrics-trustwallet[.]com and the typosquatted Maven-related domain m.fasterxml[.]org, sometimes returning the specific string, “He who controls the spice controls the universe”.
How Phoenix Security can help with Sha1-Hulud V3.0
You can set up:
This repo is a lightweight way to scan your project folders and lockfiles for known malicious packages and versions, with optional JSON output and optional upload to Phoenix (if you use it). Repo link.
1- Create the Campaign in Phoenix Security
Install the campaign for:
- Sha1-Hulud V3
- Sha1-Hulud V2
- Sha1-Hulud V1
Verify the results
Step 1: Clone and set up
git clone https://github.com/Security-Phoenix-demo/Shai-Hulud-Sha1-Hulud-V2-npm-compromise-scanner
cd Shai-Hulud-Sha1-Hulud-V2-npm-compromise-scanner
pip install -r requirements.txtStep 2: Scan your project
python -m universal_vulnerability_scanner.main scan /path/to/your/project/
# Examples:
python -m universal_vulnerability_scanner.main scan ~/projects/my-react-app/
python -m universal_vulnerability_scanner.main scan . # Current directoryStep 3: JSON output (handy for pipelines)
python -m universal_vulnerability_scanner.main scan /path/to/your/project/ \
--json-output security-report.jsonWhat good looks like?
What bad looks like
Step 4: Upload to Phoenix Security Platform (optional)
python -m universal_vulnerability_scanner.main scan /path/to/your/project/ \
--upload-phoenixScan this repository (self-scan)
cd /Users/francescocipollone/Documents/GitHub/Shai-Halud-tinycolour-compromise-verifier
python -m universal_vulnerability_scanner.main scan .
python -m universal_vulnerability_scanner.main scan . \
--json-output scan-results.json
python -m universal_vulnerability_scanner.main scan . \
--upload-phoenixExpected output: clean scan (no vulnerabilities in this repo).
What “clean” vs “found something bad” looks like
Clean scan
✅ Scan complete: 15 findings
SUMMARY:
VULNERABLE: 0 ✅
SAFE: 15 ✅
All packages are safe!Malicious packages found
🚨 VULNERABLE: 1 package detected
CRITICAL: @vietmoney/react-big-calendar@0.26.2
File: package.json
CVE: CVE-2025-VIETMONEY-SUPPLY-CHAIN
Attacker: NPM user "hoquocdat"
Payload: 16.2 MB environment_source.js
Published: Dec 28-29, 2025
⚠️ IMMEDIATE ACTION REQUIRED
Remove immediately and audit for data breach!If you found @vietmoney packages, do this now
1) Remove malicious packages
npm uninstall @vietmoney/react-big-calendar
npm uninstall @vietmoney/react-native-smart-page
npm uninstall @vietmoney/react-native-smart-gallery
npm uninstall @vietmoney/react-native-true-id
npm uninstall @vietmoney/react-native-tags-input
npm uninstall @vietmoney/react-native-vnpay-merchant
npm uninstall @vietmoney/react-native-image-transformer
npm uninstall @vietmoney/react-native-htmlview
npm uninstall @vietmoney/react-native-action-button
npm uninstall @vietmoney/vietmoneywork2) Clean install
npm cache clean --force
yarn cache clean
rm -rf node_modules
rm package-lock.json yarn.lock
npm install3) Verify removal
npm list | grep @vietmoney
# Should return nothing
python -m universal_vulnerability_scanner.main scan .
# Should show: ✅ No vulnerabilities detected4) Rotate credentials like you mean it
Assume anything reachable from the infected environment is burned:
- npm tokens (npm token list then revoke)
- GitHub or GitLab tokens
- AWS, GCP, Azure keys
- database credentials
- API keys
- SSH keys
- payment gateway secrets
Temporary Protections
These steps reduce blast radius while you hunt and patch process gaps.
Block install-time script execution in CI
- Enforce – ignore-scripts for installs in build pipelines where feasible.
- Pin dependencies and require lockfile-only installs to stop surprise updates.
- Gate new or changed dependencies through review, not autopilot.
Cut off easy exfil paths
- Restrict CI runner egress to known-good domains; flag or block outbound pushes to new GitHub repos during builds.
- Alert on repo-creation API usage from automation identities.
Credential hygiene that actually matters here
- Rotate:
- npm tokens
- GitHub or GitLab tokens
- cloud keys and CI secrets reachable from affected machines
- npm tokens
- Move to short-lived, scoped credentials where possible so theft expires fast.
How could a threat actor use this vulnerability?
I’ll spell out the abuse path without handing over a step-by-step playbook.
Phase 1: Trigger execution
A developer or CI agent installs the affected package version. The lifecycle script runs automatically. That single event is enough to start credential exfiltration.
Phase 2: Steal what unlocks your estate
The payload scrapes environment variables, local config, CI secrets, and cloud credentials. It also targets GitHub and npm tokens because those two are force multipliers.
Phase 3: Exfiltrate and expand
Stolen secrets get pushed into attacker-controlled GitHub repos, then the actor uses captured npm tokens to publish additional trojanized packages under the compromised maintainer’s scope. That’s how a “small” infection becomes a widespread supply chain incident.
Phase 4: Turn stolen dev secrets into real money
This is not theoretical. In late 2025, Trust Wallet tied a breach path to Sha1-Hulud-era exposed developer secrets that enabled malicious extension builds and significant theft. Different target, same lesson: dev secrets are production access wearing a hoodie.
Bonus: Chaining with server-side RCE (React2Shell)
Once an actor holds CI credentials or cloud keys, they often pivot into exploiting internet-facing app weaknesses. A clean example is React2Shell (check blog here)
- CVE-2025-55182 (React) and CVE-2025-66478 (Next.js, later treated as duplicate/covered) are critical pre-auth RCE issues in the React Server Components “Flight” protocol handling.
- Affected product ranges called out publicly include react-server-dom* 19.0.x–19.2.x and Next.js App Router canary/stable lines with patched releases available.
That chain is why modern defense against Sha1-Hulud is not “dependency hygiene” in isolation. It’s DevSecOps discipline plus ASPM-grade visibility plus ruthless vulnerability management that treats build systems as Tier 0.
How Phoenix Security Can Help with Container Vulnerability Sprawl
Application Security and Vulnerability Management teams are tired of alert fatigue. Engineers are buried in vulnerability lists that say everything is critical. And leadership? They want to know what actually matters.
Phoenix Security changes the game.
With our AI Second Application Security Posture Management (ASPM), powered by container lineage, contextual deduplication, and container throttling, we help organizations reduce container false positives up to 98% and remove up to 78% of false positives in container open source libraries, pointing the team to the right remediation
Why Container Lineage Matters:
Most platforms tell you there’s a problem. Phoenix Security tells you:
- Where it lives (code, build, container, cloud)
- Who owns it
- If it’s running
- If it’s exploitable
- How to fix it
All of this is delivered in one dynamic, prioritized list, mapped to the real attack paths and business impact of your applications.
Here’s What You Get:
- Contextual Intelligence from Code to Runtime: Understand which vulnerable components are actually deployed and reachable in production, not just listed in a manifest.
- Noise Reduction with Automated Throttling: Disable inactive container alerts and slash duplicate findings by over 90%, letting your team focus on the vulnerabilities that matter.
- 4D Risk Scoring That Maps to Real-World Threats: Built-in exploit intelligence, Probability of exploitation, EPSS, exposure level, and business impact baked into a customizable formula. No more CVSS-only pipelines.
Vulnerability overload isn’t a badge of diligence—it’s a liability.
Container lineage in Phoenix Security helps you shut down false positives, stop chasing ghosts, and start solving the right problems.
Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.
