Hash Validation Packages Targeted by Malicious NPM Packages
By Paul McCarty
Last week while researching another related campaign the Safety research team uncovered a bigger, and more sinister, threat campaign targeting some of the most popular NPM hash validation libraries with functioning copycat packages. You can read last weeks blog post about the "polymarket-clob" NPM package here.
TL;DR
This cluster is a coordinated ongoing software supply chain attack involving 12 malicious "hash validator" packages. These packages are simple, but effective infostealers that target .env files on developers laptops, or in CI/CD pipelines.
The scope of the attack
The package that we found last week, “polymarket-clob”, was a malicious package that targeted crypto traders. This older group of malicious packages are targeting a wider range of developers and application targets. These additional packages are:
Blockchain-helper-lib
This package uses a blockchain related name, but bills itself as a hash validation library.
The package author, "jamesedward" has only published one package:
This package has had 28 versions over the last six months:
The Safety team has alerted NPM about this package, but it is still available as of this writing. NPM's time to removal is increasing again after having come down dramatically from weeks to hours after the shai-hulud attacks.
The Infostealer: index.js
The package.json file does not include an install script, so that means these packages rely on the victim importing the library into their applications. The only way that the victim will do this is if the library actually performs its function, and most of these packages do in fact validate hashing.
The index.js file
The index.js file looks for .env files in the current directory and its parent directory. All module names are Base64-encoded to evade static analysis and grep-based detection. We've decoded them below and added comments.
The Exfiltration Module: utils.js
Researching the origins of this attack
Remember how the polymarket-clob package used the source code from another malicious package, “sha256-validator-pro”? The Safety research team analyzed that package which was published in August 2025.
The similarities between sha256-validator-pro (August 2025) and polymarket-clob (December 2025) are strong. Both files have the same 5 files, and the files themselves are architecturally very similar as well. For example, the index.js files use the same obfuscated class and variable names. It's obvious to our team that polymarket-clob is based on sha256-validator-pro.
The sha256-validator-pro package was published by the NPM author "johndoe1090" who published 7 other packages in 2025:
While the author of the polymarket-clob package made some operational mistakes early on, their updated payload is better and harvests more credentials than its predecessor. Those earlier malicious package notably only looked for and exfiltrated .env files on the compromised hosts. The latest package, polymarket-clob, looks for .env files, but also looks for six additional files including wallet.json, wallet_list.json and similar files.
While searching for other packages that had some of the same characteristics as polymarket-clob, we identified older packages using the same payload: It turns out that the “sha256-validator-pro” package was based on an earlier package “sha256-validator-pack” which the Safety team has also analyzed.
Our team has analyzed all the packages involved and while we can't say that the same threat actor published all of these packages, we can absolutely say that polymarket-clob was based on sha256-validator-pro which in turn was based on sha256-validateor-pack.
So, it went like this: sha256-validator-package --> sha256-validator-pro --> polymarket-clob
How many times were these packages downloaded?
If You've Installed Any of These Packages
npm uninstall blockchain-helper-lib
.env files178.17.62.101safety scan
package-lock.json) and verify integrity.env files in project directoriesBased on our research this threat campaign has several IOCs you can look for:
NPM Packages - all versions:
dotenv-lib esb-core-helpers polymarket-clob secure-string-crypto sha256-cbc 1.0.3 sha256-validation sha256-validator-pack sha256-validator-pro solana-utils-sdk synced-plus-agent
blockchain-helper-lib
IP Addresses:
178.17[.]62[.]101
170.205[.]31[.]22
146.19[.]215[.]54
C2 address:
hxxp://178.17[.]62[.]101:5018/dev-sha-es6
hxxp://146[.]19[.]215[.]54:9001/"}/deep-es6
hxxp://170[.]205[.]31[.]22:5580/core-helper
Files:
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.
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.