In September 2025, a self-replicating worm called Shai-Hulud spread through npm by stealing developer credentials from one compromised package and using them to automatically publish trojanized versions of the next, ultimately touching more than 500 packages in a matter of days. It is one data point in a much bigger trend: Sonatype's research has tracked over 245,000 malicious packages published to open source registries in a single year, and the pace keeps accelerating. These aren't vulnerable libraries waiting to be exploited — they are packages built from the start to steal credentials, exfiltrate secrets, or open a backdoor the moment npm install finishes. Traditional software composition analysis, the category Mend.io built its business on, was designed to catch known CVEs in code you already trust. It was never built to catch code that was malicious on day one. This post breaks down how the malicious package problem actually works, why it evades legacy tooling, and what effective malicious open source packages detection looks like in 2026.
What actually counts as a "malicious package," and how is it different from a vulnerable one?
A malicious package is software written with harmful intent from the moment it's published — there is no patch to apply because there was never a legitimate version. A vulnerable package, by contrast, is legitimate code that happens to contain a flaw, typically tracked with a CVE number, a CVSS score, and a fix released by maintainers. The distinction matters enormously for detection. When researchers disclosed CVE-2024-3094, the xz utils backdoor, it was because a Microsoft engineer named Andres Freund noticed SSH logins were taking 500 milliseconds longer than expected — not because a scanner flagged it. Malicious packages typically show up under names like discordjs-selfbot-v13, node-hex, or typosquats such as reqeusts and crossenv that are one keystroke away from the real thing. Security researchers at Socket and Phylum have reported that npm alone sees dozens of newly published malicious packages every single week, most designed to look boring enough that nobody double-checks them before install.
How often are malicious packages actually showing up in npm and PyPI?
Far more often than most engineering teams assume — Sonatype's 2023 State of the Software Supply Chain report documented a 200%+ year-over-year jump in malicious packages, building on a cumulative total that crossed 400,000 packages removed from public registries since tracking began. ReversingLabs separately reported more than a 1,300% increase in threat actors abusing open source repositories since 2020. These aren't fringe experiments. In 2022, the PyPI ecosystem saw a wave of "W4SP Stealer" packages distributed under dozens of typosquatted names, each designed to scrape browser-saved passwords and Discord tokens. In March 2022, the popular node-ipc package was deliberately sabotaged by its own maintainer to wipe files on machines with Russian or Belarusian IP addresses — a protestware incident that briefly took down builds across thousands of downstream projects, including some inside popular frameworks like Vue CLI. The registries themselves are trying to keep pace: npm has run multiple mass-takedown operations, but publication is instant and free, while removal depends on someone noticing first.
What made the Shai-Hulud npm worm different from earlier supply chain attacks?
Shai-Hulud automated the attack chain that previously required a human at every step. Earlier incidents like the 2018 event-stream compromise, where an attacker gained maintainer access and quietly added a Bitcoin-wallet-draining dependency called flatmap-stream, or the October 2021 hijacking of ua-parser-js (downloaded roughly 8 million times a week at the time), still relied on a person manually publishing each malicious version. Shai-Hulud instead used stolen npm tokens to publish worm code that harvested more credentials from the compromised developer's machine and automatically re-published itself into any other package that developer maintained, spreading through the dependency graph with no additional human action. Within days it had reached hundreds of packages, some with substantial download counts, illustrating how a single leaked token can cascade into an ecosystem-wide incident far faster than any manual review process — including a CVE database update — can react.
Why did the xz utils backdoor almost make it into every major Linux distribution?
Because it was planted by a trusted, years-long contributor rather than an anonymous typosquatter, which is exactly why signature- and reputation-based scanning missed it. "Jia Tan" spent roughly two years building credibility as a co-maintainer of xz utils before quietly introducing obfuscated backdoor code into release tarballs in February and March 2024, targeting OpenSSH authentication on Linux systems. It was on the verge of shipping in Debian and Fedora's next stable releases when Freund's manual investigation into SSH latency caught it on March 29, 2024 — weeks, not minutes, after the malicious code had already been distributed. No CVE existed yet, no vulnerability database had an entry, and the package's publish history looked completely normal to any tool checking metadata or known-bad hashes. That is the scenario legacy SCA is structurally unable to catch: a trusted maintainer, a clean version history, and code that only reveals its intent through behavior, not through matching a signature.
Why do traditional SCA tools like Mend.io miss these attacks?
Because SCA platforms like Mend.io were architected around a database-lookup model: match the packages in your manifest against a known-vulnerability feed and flag the ones with a CVE. That model is genuinely useful for patch management, but it depends on someone else having already discovered, disclosed, and cataloged the bad behavior first — a process that regularly takes weeks after a malicious package has already been downloaded thousands of times. Malicious packages are typically live for a median of just a few days before takedown, according to Socket's registry monitoring data, which means a detection approach anchored to disclosure lag will almost always find out after the damage is done. Mend.io and comparable SCA tools also generally scan what's declared in your lockfile at commit or build time, not what a package actually does when it installs — and most credential-stealing payloads in recent campaigns, including Shai-Hulud and the W4SP packages, executed through npm's postinstall scripts, a mechanism vulnerability databases don't model at all.
How Safeguard Helps
Safeguard is built for the malicious open source packages detection problem specifically, not just known-CVE matching. Instead of waiting for a vulnerability database entry, Safeguard analyzes package behavior directly — install scripts, network calls, obfuscation patterns, and metadata anomalies like a brand-new maintainer account suddenly publishing to a package with millions of weekly downloads — so it can flag packages that look like Shai-Hulud, node-ipc, or a fresh typosquat before a CVE ever gets assigned. It continuously monitors your dependency graph for newly published or newly hijacked versions in near real time, rather than only at the next scheduled scan, closing the detection-lag window that let xz utils sit undiscovered for weeks. Safeguard also correlates open source risk with the rest of your software supply chain posture — SBOM accuracy, provenance verification, and build pipeline integrity — so security teams get one system of record instead of stitching together an SCA tool's CVE feed with separate threat intel on the same packages. For teams that already run Mend.io or another SCA platform for license compliance and patch tracking, Safeguard is designed to sit alongside it and cover the gap those tools were never built to close: the packages that were malicious from the moment they were published.