This content originally appeared on Level Up Coding – Medium and was authored by Samrat Dutta
Supply chain attacks are getting crazier!
I know what you’re thinking. “Another security article telling me the sky is falling.” Well, grab your favorite caffeinated beverage (try not to get addicted to it) and buckle up, the sky actually did fall. And it landed squarely on the JavaScript ecosystem (sorry, my humour is broken).
When “Trusted” Packages Turn Into Worms
Just two weeks ago, on what seemed like an ordinary Monday morning (September 8th, 2025), the JavaScript world experienced what security researchers are calling one of the most devastating supply chain attacks in npm history. The attack compromised 18 widely used packages with over 2.6 billion weekly downloads combined.
Josh Junon, better known as “qix” to the npm community, fell victim to what he described as looking “legitimate at first glance.” The email came from “support@npmjs.help” — a domain registered just three days before the attack. Having a “panicky morning” and a “stressful week,” he clicked the phishing link and entered his credentials.
As Junon later admitted on Bluesky: “Sorry everyone, I should have paid more attention. Not like me; have had a stressful week.”
And just like that, with one tired click, attackers gained access to some of the most fundamental building blocks of the modern web.
Junon is the developer of multiple NPM packages. Multiple very important NPM packages, I should mention. And his packages are also used by multiple very important NPM packages, such as lint, carbon, and many more.
The Domino Effect
The compromised packages read like a who’s who of JavaScript utilities: chalk, debug, ansi-styles, strip-ansi, and 15 others. These aren’t flashy libraries with fancy marketing pages. They’re the invisible infrastructure that holds the JavaScript ecosystem together.
The malware was surgically precise. It didn’t crash applications or display ransom notes. Instead, it quietly sat in browser environments, intercepting cryptocurrency transactions. Using Levenshtein distance algorithms, it would replace wallet addresses with visually similar ones controlled by the attackers.
The sophistication was remarkable: the malware targeted Ethereum, Bitcoin, Solana, Tron, Litecoin, and Bitcoin Cash, maintained over 280 hardcoded attacker addresses for redundancy, and used hexadecimal encoding to avoid detection. According to Socket’s analysis, the attackers netted about $600 from this campaign — not a fortune, but proof of concept for much larger potential damage.
The Worm That Ate the JavaScript Ecosystem
But the September 8th attack was just the beginning. On September 15th, a new threat emerged: the “Shai-Hulud” attack, exhibiting something never seen before in the npm ecosystem. A self-replicating, worm-like behavior.
As a Dune fanboy, I was so excited when I discovered this. But let’s learn more about it first.
When this malware finds npm tokens in a compromised environment, it doesn’t just steal them. It automatically uses them to publish malicious versions of any packages that those tokens can access. ReversingLabs characterised it as a “first of its kind self-replicating worm” that has infected over 180 packages and counting.
The worm creates public GitHub repositories named “Shai-Hulud” under compromised accounts, essentially turning victims’ own accounts into data storage for stolen credentials. CrowdStrike even had some of their npm packages compromised in this ongoing campaign.
The Hacker News Reality Check
The discussion on Hacker News was revealing. Josh Bressers from Anchore made an excellent point: “This all lasted for only a few hours. It’s amazing how fast open source can respond to things like this.”
The community did respond rapidly — Aikido Security detected the attack within 5 minutes, npm started removing malicious versions within hours, and platforms like Vercel proactively purged build caches.
Melissa Bischoping from Tanium tried to calm the panic: “There’s a virtually 0 chance you’re impacted by this… The chances of them being downloaded and shipped into your software in that window of time are very, very small.”
But this reasoning feels dangerously optimistic when you consider that the next attack might not be discovered in 5 minutes, might not be limited to cryptocurrency theft, and might not be deployed when security researchers are alert.
The Uncomfortable Truths
Let’s address some uncomfortable realities this incident has forced us to confront:
Popular packages are prime targets. The most affected packages had massive download numbers — chalk with 40+ million weekly downloads, debug with 350+ million. Popularity creates false security while making packages incredibly attractive to attackers.
Supply chain attacks are evolving rapidly. We’ve seen progression from simple malicious packages to sophisticated phishing campaigns to self-replicating worms in just months. According to ReversingLabs’ 2025 report, 14 of the 23 crypto-related malicious campaigns in 2024 targeted npm.
The blast radius is exponential. When researchers say “2.6 billion weekly downloads,” each download potentially becomes part of build artifacts deployed to production, cached in CI/CD systems, and bundled into applications serving real users.
Why Current Security Measures Fall Short
Most developers’ npm security strategy amounts to “npm audit and hope for the best.” This isn’t adequate because:
npm audit only catches known vulnerabilities. The September 2025 attacks used zero-day malware with no CVE numbers or vulnerability database entries. Even dependency pinning isn’t bulletproof — your CI/CD pipeline, colleagues’ environments, and production builds are all potential entry points.
Sometimes, NPM might take hours to add vulnerable packages to their list (doesn’t happen generally, but might happen in future). Meaning, for that time being, you are vulnerable with no way to check if you are compromised. Also, your own team/organisation might find a vulnerable package, and all the Node.js products in your ecosystem must be checked immediately.
Well, of course, you can run npm list and check all of your dependencies one by one manually, but that’s a long task.
The Solution: Proactive Vulnerability Scanning
This brings me to why I built the NPM Vulnerability Checker. I am just trying to make your job a little bit easier with this.
What Makes This Different
Traditional security tools are reactive — they protect against known threats. My vulnerability checker works differently:
Custom vulnerability databases: Load CSV files with vulnerability information specific to your organisation or threat intelligence sources. When new attacks like Shai-Hulud emerge, update your vulnerability database immediately without waiting for official CVE assignments.
Comprehensive dependency analysis: Uses npm list to analyze your complete dependency tree, including indirect dependencies. It examines everything that actually gets installed, not just package.json.
Dual interface: GUI mode for manual investigation, CLI mode for CI/CD automation. Same executable, different modes.
Real-World Example: Catching the September Attacks
If you had created a CSV file when the September 8th attack was discovered:
Package,Vulnerable_Versions,Severity
chalk,5.6.1,Critical
debug,4.4.2,Critical
ansi-styles,6.2.2,Critical
The scanner would immediately identify any projects using those versions:
npm-vuln-checker --cli --csv attack-indicators.csv --project . --output report.txt
Output shows exactly what’s affected:
STATUS: VULNERABLE
Package: chalk
Used Version: 5.6.1
Dependency Type: Direct
Path: chalk@5.6.1
CI/CD Integration That Actually Works
The CLI mode integrates seamlessly into development workflows:
# GitHub Actions
- name: Security Scan
run: |
curl -O https://your-security-team.com/npm-threats.csv
./npm-vuln-checker --cli --csv npm-threats.csv --project . --output report.txt
if [ $? -ne 0 ]; then
cat report.txt && exit 1
fi
This catches compromised packages before they reach production.
Building Your Threat Intelligence Arsenal
One powerful feature is creating custom vulnerability databases. You can:
- Monitor security feeds: When companies like Socket or ReversingLabs publish npm threat research, add those indicators immediately
- Track industry threats: Fintech companies can maintain databases focused on cryptocurrency-targeting malware
- Share intelligence: Maintain central databases across teams for consistent scanning
Oh, and it’s written in C. So you can have your own compiled executable and it will run blazing fast!
What’s Coming Next: AI-Powered Vulnerability Detection
We’re working on some exciting enhancements that will fundamentally change how vulnerability scanning works:
AI-powered web scanning: Instead of relying solely on CSV databases, the next version will automatically scan security research feeds, GitHub security advisories, and threat intelligence platforms to build vulnerability databases in real-time.
Natural language threat intelligence: Just dump raw text from security reports, blog posts, or threat intelligence feeds. Our AI system will extract package names, version ranges, and threat indicators automatically — no more manual CSV creation.
Intelligent pattern recognition: The AI will identify suspicious package patterns and behaviours that might indicate compromise, even without specific vulnerability signatures.
This means you won’t need to manually maintain CSV files or constantly update threat databases. The system will continuously learn about new threats and automatically protect your projects.
Lessons from September 2025
Speed of detection matters. Aikido’s 5-minute detection time was crucial in limiting damage. Automated scanning can achieve similar detection speeds.
Community response is powerful. The npm ecosystem’s rapid mobilization — package removal, platform notifications, security analysis — showed that collective defense works.
Attackers are investing heavily. The progression from simple malware to self-replicating worms shows sophisticated threat actors are targeting supply chains with significant resources.
Building Resilient Security
Using the NPM Vulnerability Checker is one piece of comprehensive security:
- Diversify tools: Use npm audit for CVEs, dependency scanners for compliance, vulnerability checkers for custom intelligence
- Implement layered defense: Lock versions in production, use npm ci in CI/CD, implement package overrides, monitor network traffic
- Stay informed: Follow @socketdev, security mailing lists, and npm security advisories
- Practice response: Have plans for quick dependency updates, cache purging, and redeployment
Getting Started Today
The NPM Vulnerability Checker is available now. Download pre-built binaries from the releases page, or build from source. It works on Windows, Linux, and macOS with no installation required.
Start by scanning your current projects:
# Quick scan with basic threat database
npm-vuln-checker --cli --csv threats.csv --project . --output security-report.txt
Build this into your CI/CD pipeline, create custom threat intelligence databases, and establish regular scanning schedules.
Before You Go
Your npm projects face sophisticated, well-funded attackers who understand both social engineering and advanced malware development.
But you’re not defenseless. The key is moving from reactive security (responding to known vulnerabilities) to proactive defense (detecting emerging threats).
The NPM Vulnerability Checker gives you the tools to build that proactive defense today. With AI-powered enhancements coming soon, it will become even more powerful at protecting your supply chain.
And did I mention it is written in C?
Because in cybersecurity, the side that adapts fastest usually wins. And right now, the attackers are adapting very quickly indeed.
Download the NPM Vulnerability Checker at github.com/SamratDuttaOfficial/npm-packages-checker. Open source, free to use, and designed to keep you ahead of evolving threats.
Please feel free to contribute to this open-source project. Thanks.
Your Node.js Project is Not Safe (Trust Me, It’s Not) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding – Medium and was authored by Samrat Dutta