Open source malware is code deliberately planted inside a package, library, or repository to harm the systems that install it — not a bug that slips in by accident, but a payload an attacker put there on purpose. It hides in the same npm, PyPI, RubyGems, and Maven registries that power modern software, waiting for a pip install or npm install to run it. Sonatype, which publishes an annual State of the Software Supply Chain report, has tracked this category for years and popularized much of the vocabulary security teams now use: typosquatting, dependency confusion, protestware. In 2023 alone, Sonatype identified more than 245,000 malicious open source packages — nearly double every prior year combined. This glossary entry breaks down what open source malware actually is, how it gets distributed, which real incidents defined the category, and how it differs from the CVEs most vulnerability scanners are built to catch.
What Is Open Source Malware?
Open source malware is malicious code intentionally published inside an open source package to compromise the systems, developers, or CI/CD pipelines that consume it. Unlike a traditional vulnerability — a flaw an attacker later discovers and exploits — malware is built in from the start, so the exploit and the software ship together. It can be as simple as a postinstall script in a package.json that exfiltrates environment variables, or as elaborate as a multi-stage loader that only activates after detecting a production environment. Sonatype categorizes these packages separately from CVE-tracked vulnerabilities in its data feeds precisely because they require different detection logic: you're not scanning for a known-bad version string, you're scanning for behavior — network calls to unfamiliar domains, obfuscated code, scripts that fire on install rather than at runtime, and metadata that doesn't match the package's stated purpose.
How Do Attackers Sneak Malware Into Open Source Packages?
Attackers rely on four repeatable techniques: typosquatting, dependency confusion, maintainer account takeover, and protestware. Typosquatting means publishing a malicious package with a name close to a popular one — electorn instead of electron, crossenv instead of cross-env — betting on a developer's typo or a copy-paste error. Dependency confusion, publicly demonstrated by researcher Alex Birsan in February 2021, exploits the fact that many companies run private internal packages with the same names as public ones; if the public registry version has a higher version number, package managers will often pull the attacker's public copy instead of the internal one, and Birsan collected bug bounties from Apple, Microsoft, PayPal, and dozens of other companies proving the technique worked. Account takeover means compromising a legitimate maintainer's credentials or npm token and pushing a malicious version to a package millions of developers already trust. Protestware is different again: a maintainer intentionally sabotages their own widely used package to make a political statement, as happened with node-ipc in March 2022, when its maintainer added code that wiped files on machines with Russian or Belarusian IP addresses.
How Big Is the Open Source Malware Problem?
The problem has grown from a few hundred incidents a year to hundreds of thousands. Sonatype's research reported 245,032 malicious packages discovered in 2023, pushing the cumulative total identified since 2019 past 415,000, and its team has separately described year-over-year increases exceeding 200% for several consecutive reporting periods. Socket's threat research team reported similar volume, flagging tens of thousands of malicious npm and PyPI packages annually by 2024. The scale is a direct function of registry design: npm and PyPI are open-publish by default, meaning anyone can upload a package in minutes with no vetting, and automated tooling lets attackers generate thousands of near-duplicate malicious packages targeting slightly different misspellings or namespaces in a single campaign. Registries do remove packages once reported — npm and PyPI both run active takedown programs — but the median time between publication and detection has historically run from days to weeks, which is more than enough time for a malicious package to get pulled into a CI pipeline or a developer's laptop.
What Are Some Real-World Examples of Open Source Malware?
Some of the most cited cases span nearly a decade and show the technique evolving. In November 2018, the event-stream npm package — with roughly 2 million weekly downloads at the time — was compromised when its original maintainer handed control to an unknown contributor who added a dependency, flatmap-stream, containing code that targeted a specific Bitcoin wallet application. In October 2021, ua-parser-js, used in millions of projects, was hijacked via a stolen npm account and republished with a cryptominer and password-stealing script embedded in a postinstall hook. Weeks later, in November 2021, the coa and rc packages — both dependencies of the massively popular react-scripts — were similarly compromised, breaking builds worldwide within hours and installing a password stealer along the way. In March 2025, the GitHub Action tj-actions/changed-files, used in tens of thousands of repositories, was compromised to dump CI/CD secrets into build logs, prompting GitHub's own security advisory and a scramble across the industry to audit workflow files. Each incident followed a different entry technique, but all shared the same outcome: legitimate, trusted code became the delivery mechanism for an attack.
How Is Open Source Malware Different From a Vulnerable Dependency?
A vulnerable dependency contains an unintentional flaw that an attacker can exploit; open source malware is intentionally malicious from the moment it's published. This distinction matters because it changes the entire detection strategy. A CVE-based scanner works by matching a package's version number against a database of known-bad versions — that's effective for something like Log4Shell (CVE-2021-44228), where the flaw exists in specific released versions of Log4j and gets fixed in later ones. But there is no "fixed version" of a malware package, because the malicious version was never meant to be fixed — it's usually pulled entirely, and a new typosquat or account-takeover package simply appears somewhere else. Sonatype and similar vendors address this by maintaining a separate malicious-package intelligence feed alongside their standard vulnerability database, and increasingly by adding behavioral analysis — sandboxing package install scripts and inspecting network calls — because a static version check will never catch a package that was malicious on day one.
How Safeguard Helps
Safeguard is built around the assumption that not every threat in your software supply chain shows up as a CVE, which is exactly where traditional SCA tooling falls short against open source malware. Safeguard continuously screens new and updated packages across npm, PyPI, and other major registries for the same signals that defined the incidents above: suspicious install scripts, obfuscated payloads, network calls to unexpected destinations, sudden maintainer or ownership changes, and version jumps that look like dependency-confusion bait. Rather than waiting for a public disclosure or a Sonatype-style intelligence feed update, Safeguard's detection runs against packages as they land, so a compromised postinstall script or a freshly typosquatted package can be flagged before it reaches a build pipeline. That intelligence feeds directly into policy enforcement — teams can block malicious packages at the point of installation, get alerted the moment a dependency's maintainer or publishing pattern changes unexpectedly, and get an audit trail showing exactly which packages were screened and why one was blocked, which matters as much for incident response as it does for SOC 2 and compliance reporting. For teams that have relied on CVE-based scanning alone, adding this layer closes the exact gap that incidents like event-stream, ua-parser-js, and tj-actions/changed-files exposed: the malware was never going to show up in a vulnerability database, because it was never a bug — it was the plan.