On December 29th, 2025 a malicious NPM package was published: @vietmoney/react-big-calendar version 0.26.2 by the NPM user “hoquocdat”.
This package represents a new, third iteration of the shai-hulud/sha1-hulud worm.
The Evolution of a Supply Chain Threat (September 2025 - Present)
Shai-hulud first appeared in September 2025, compromising maintainer Scott Cooper/@scttcper and affecting 187 npm packages. It disguised itself as a color library, deployed Trufflehog for credential harvesting, and targeted cloud environments (AWS, GCP, ECS/EKS). The malware created public "shai-hulud" repositories in victims GitHub accounts, and then pushed any secrets it had stolen to these public repos. It also injected GitHub Actions workflows, and converted 528 private repositories to public with "Shai-Hulud Migration" descriptions. It exfiltrated GitHub tokens, AWS credentials, GCP keys, and database passwords to webhook.site, eventually exceeding the service's usage quotas. And worst of all, it had a built in worm function so that once it compromised a NPM author’s account it would then push the malware into all their NPM packages and publish them, thereby infecting anyone else that used those compromised packages. You can read my technical analysis of the attack in this blog article.
In November 2025, "The Second Coming" compromised 492 packages with 132 million combined monthly downloads, targeting Zapier, ENS Domains, AsyncAPI, PostHog, and Postman. Launched before NPM’s December 9 token deadline, this version used randomly-generated repository names, expanded targeting from 20 to 100 packages, deployed via setup_bun.js/bun_environment.js, and added a “kill-switch” feature that would wipe victims home directories on authentication failure. It exposed 26,300 repositories and published credentials to GitHub with "Sha1-Hulud: The Second Coming."
The current third iteration—analyzed in this report—represents the most recent version of this attack.
The Latest Iteration: Version 3.0
Our research began when we became aware of a new suspicious npm package: @vietmoney/react-big-calendar. We initially assumed this to be a typosquatted version of the legitimate react-big-calendar package. What caught our attention was the 16.2 MB file size of environment_source.js, far larger than typical npm package files.
There were several other red flags other than its large size. The NPM user had published the original version of the package (0.26.0) five years ago, and the latest version of the package 0.26.2 was 100% different than the original version 0.26.0. Also, the new version of the package used a post install script to call the initial payload file.
What’s Different In This Version?
The third iteration of the Shai-Hulud software supply chain campaign was detected on December 28, 2025, when a new version of the npm package @vietmoney/react-big-calendar was published. Charlie Erikson has done a great job as usual writing it up on the Aikido blog.
The most notable structural change in version 3.0 is the renaming of core components. The entry point is now called bun_installer.js and the main payload has become environment_source.js, replacing the naming conventions used in earlier campaigns. The attacker also adopted a new repository identifier: "Goldox-T3chs: Only Happy Girl."
A significant operational change is the removal of the "dead man switch" that was present in earlier versions. This failsafe mechanism has been eliminated entirely from 3.0. Additionally, researchers discovered a telling bug where the code attempts to fetch c0nt3nts.json but saves it as c9nt3nts.json. This filename mismatch suggests the threat actor is manually obfuscating the source code rather than using automated transformation tools, indicating they have direct access to the original codebase.
The malware continues to exfiltrate sensitive data including environment variables, cloud credentials, repository contents, and secrets from various sources. However, the collection sequence has been reordered so that contents files are now saved last rather than first. The campaign also shows technical improvements: better Windows compatibility through proper handling of the bun package manager executable path (fixing a limitation from version 2.0), and enhanced timeout management for TruffleHog secret scanning operations.
Follow The Bread Crumbs…
The author of the first package identified in this version,@vietmoney/react-big-calendar, is a Vietnamese developer named Dat Ho Quoc. He is the author of two public packages as of this writing:
I reached out to Dat on LinkedIn and he said he would remove the package, but it remained live for another day until NPM replaced it with the typical “Security holding package”.
The Plot Thickens
On December 31, 2025, another ten packages were identified as part of the campaign. NPM had already removed all ten of these packages:
- @vietmoney/react-native-smart-page
- @vietmoney/react-native-smart-gallery
- @vietmoney/react-native-true-id
- @vietmoney/react-native-tags-input
- @vietmoney/react-native-vnpay-merchant
- @vietmoney/react-native-image-transformer
- @vietmoney/react-native-htmlview
- @vietmoney/react-native-action-button
- @vietmoney/vietmoneywork
This One Doesn’t Look Like The Others
Here's what's important to understand: all the other packages affected by shai-hulud were compromised by the worm. In other words, these were legitimate NPM packages with legitimate authors and maintainers—until a bad actor gained access to them. In all earlier shai-hulud cases, the threat actors released new malicious versions after compromising the packages. NPM simply removed the malicious versions and left all the other versions intact.
For some reason, that’s not what happened here. All eleven of the @vietmoney packages have all been removed by NPM, even though several of them appear to be legitimate packages.
The Timeline
The @vietmoney/react-big-calendar package was originally published back in March 2021:
While the latest version, 0.26.2 is definitely malicious; I’ve analyzed the 0.26.0 version of that package and it has no malicious payload. It’s a genuine JavaScript calendar library and appears to be a vendored version of https://www.npmjs.com/package/react-big-calendar. So at this point it looks like all the other shai-hulud attack victims that had one malicious version published when an NPM authors account was compromised.
Removed Package @vietmoney/react-native-smart-page
The same pattern can be observed with the @vietmoney/react-native-smart-page package:
Version 1.1.2 was published in 2022 and appears to be a vendored version of https://www.npmjs.com/package/react-native-smart-page.
How can I tell its vendored? Well, all you have to do is look at the metadata for the package:
First, the metadata fields for the homepage and bugs both point to the original package by Lue Hang (NPM user luehang). Second, all the author metadata has been copied from the original package. This is often malicious—threat actors use the legitimacy of the original package to hide their intent. However, it doesn't always mean that. In the case of the vietmoney team, they were using their vendored versions in their own projects which you can see here in a snapshot from the package manifest for the @vietmoney/react-native-smart-page package:
Sometimes engineers bring an open source library "in-house" by copying it and locking it at a specific point in time. This practice is called "vendoring."
Is this a good practice? Probably not. But its common.
Removed Package @vietmoney/react-native-action-button
Similarly, the @vietmoney/react-native-action-button package had a previous version published back in January 2023.
I have not been able to confirm that version 2.9.0 of the @vietmoney/react-native-action-button was legitimate, but there’s also no evidence it was malicious. It’s been removed from the NPM registry, but that’s not proof that it was malicious.
Removed Package @vietmoney/react-native-smart-gallery
Another example is the @vietmoney/react-native-smart-gallery package. There are a total of four historical versions, all from 2022:
Again, I have not been able verify whether any of those versions are malicious, but they’ve been removed from the NPM registry as well. @vietmoney/react-native-smart-gallery also appears to be a vendored version of https://www.npmjs.com/package/react-native-smart-gallery .
The NPM Author Has Been Removed From NPM
The author of these packages "hoquocdat" has been removed from NPM. His account was deleted earlier today.
This is an unusual step—NPM typically doesn't remove author accounts when they've been compromised, reserving that drastic measure for malicious threat actors. I reached out to the package author to get his perspective, but he hasn't reponded yet.
Who is VietMoney?
VietMoney appears to be a legitimate pawn shop style business with 35 physical shops across southern Vietnam. VietMoney also has a mobile application that provides cross border money transfer and mobile device payments for sending money from Taiwan to Vietnam.
VietMoney has a small engineering team, but also appears to be outsourcing some of its development work. There are 4 developers mentioned in the NPM packages.
@vietmoney NPM Scope
There is a VietMoney GitHub organization, and they also have a dedicated NPM scope, which you can see here:
One of the benefits of setting up a scoped organization in NPM is that you can publish private packages to that scope. In fact, scoped NPM packages are private, by design. This might explain why the @vietmoney scope appears empty.
Private Packages Nuked By NPM?
This got me thinking: Were these ten latest packages that have been removed by NPM as malicious, in fact, private NPM packages in the @vietmoney scope?
This would make a lot of sense and explain what I’m seeing as NPM reports back on many versions and updates to these packages that you don’t see anywhere. However, its also possible that the threat actor changed the visibility settings on the packages at some point.
Why Does This Matter
This case differs significantly from the thousand-plus packages affected by Shai-hulud versions 1 and 2. Here, NPM deleted both the author account and all the company's scoped packages—not just the malicious versions, but every single version.
If hoquocdat is a victim, why did NPM delete their account? I'm genuinely confused by this decision.
Is hoquocdat a victim or the threat actor? The evidence points to victim, but NPM's response suggests threat actor.
We must ask the same question about the company: Was the VietMoney NPM organization a victim, or part of the Shai-hulud threat actor's collateral? Again, the evidence says victim, but NPM's response indicates otherwise.
Conclusions
Shai-hulud 3.0 represents a troubling evolution in supply chain attacks. This thing is morphing right in front of our faces. Last week it was observed the the Trust Wallet attack was caused by a Shai-hulud compromise. The Shai-hulud threat actors are using credentials stolen in rounds 1 and 2 to target specific organizations and teams.
But here's what keeps me up at night: We still don't have clear answers about VietMoney and hoquocdat. The evidence strongly suggests they're victims—legitimate developers whose packages were compromised. Yet NPM's decision to nuke the entire @vietmoney scope and delete hoquocdat's account tells a different story. Either NPM knows something we don't, or they're being overly cautious in ways that hurt legitimate developers.
This ambiguity is dangerous. If we can't distinguish between victims and attackers, how do we know who to help and who to block? How many other small development teams are one compromised token away from having their entire NPM presence erased?
The supply chain security community needs better incident response protocols. We need clearer communication from NPM about why they take the actions they do. And most importantly, we need better tools for developers to detect when their accounts have been compromised—before the malware spreads, before the secrets are stolen, before their entire body of work gets deleted.
Shai-hulud isn't going away. Version 4.0 is probably already in development. The question is: Will we be ready for it?
How can Safety help protect you from these attacks?
Traditional vulnerability scanning happens too late - after potentially malicious code is already in your system. Which means that ASPM and EDR solutions don't protect you from this type of threat.
But all is not lost, as the Safety Firewall protects develoeprs and CI pipelines proactively. Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.Every package installation request is analyzed before reaching public repositories. Malicious, vulnerable, and policy-violating packages are automatically blocked before they can enter your systems, preventing rather than just detecting threats.
You can sign up for a free Safety account and try the Safety Firewall HERE. Feel free to reach out to me with any questions!
Let us know if this blog post helped you
I hope this blog post has helped you. Feel free to hit me up directly if you have any questions about this campaign.
Paul McCarty - Head of Research, Safety
You can find me on LinkedIn and BlueSky.
