Documentation
Book a demo

Risk detection

Malicious package detection

Malicious packages are artifacts intentionally crafted by an attacker to cause harm. When developers unknowingly include these packages in their applications, they open the door to data theft, ransomware, and other damaging attacks for anyone using the affected artifacts. Malicious packages are a subset of and a delivery vehicle for malware (malicious software).

An example of a malicious package is the npm package axios, which was compromised in March 2026. The npm account of one of the axios maintainers was compromised and the malicious actor published new versions of the package, adding malicious dependencies to the payload. This attack appeared to be designed to facilitate crypto-related fraud. The threat of malicious packages has grown in recent years, even as public registries introduce stronger security controls.

For more details about the axios compromise, see OSV Vulnerability Database: MAL-2026-2307.

Software Vulnerabilities (CVE) vs. Malicious Packages

A software vulnerability, often identified by a Common Vulnerabilities and Exposures (CVE) ID, is an unintentional flaw in the code. It's a bug that, if exploited by an attacker, could lead to a security breach. These vulnerabilities are typically the result of design or implementation errors.

For example, the Log4Shell vulnerability (CVE-2021-44228) was a flaw in the popular Log4j logging library for Java that enabled attackers to execute arbitrary code remotely on compromised systems. The library itself was not created with malicious intent.

How malicious packages are introduced in dependencies

Malicious actors attempt to breach the software supply chain by disguising harmful packages as legitimate, tricking developers into including them in their projects. Common techniques include:

  • Typosquatting: A new package is published with a name that is a common misspelling of a popular one. For example, publishing reqeusts to trick developers who meant to install the legitimate requests library in Python. This type of attack has recently reached a completely new level: Registry typosquatting.
  • Dependency confusion: This technique targets corporate build systems. An attacker discovers the name of a private, internal package (for example, acme-auth) and publishes a malicious package with the same name to a public registry, often with a higher version number, tricking automated tools into downloading it.
  • Account takeover: Attackers compromise the account of a legitimate package maintainer, then publish a new, malicious version of the trusted package. For instance, if the maintainer of super-utils gets their account stolen, an attacker could release version 1.2.4 containing code to steal credit card information.
  • Protestware/Malicious maintainers: Sometimes, the threat comes from the package maintainers themselves. As an act of protest or malice, they might add harmful code to their own popular library. For example, the maintainer of node-ipc added code that would delete files on systems with specific IP addresses as a form of protest.

OSV and OpenSSF Malicious Packages

Cloudsmith uses the OpenSSF Malicious Packages project, distributed through OSV.dev, as a trusted source for detecting malicious packages in open-source software. The OpenSSF Malicious Packages project is a community-driven effort to collect and document confirmed malicious packages found in the wild across multiple package registries.

OSV.dev, initiated by Google, provides a unified, open, and distributed database for vulnerability information, making it easy for developers and automated security tools to consume. By cataloging malicious packages within OSV.dev, the OpenSSF project centralizes intelligence that helps developers and organizations quickly identify threats and strengthen their software supply chains.

How it works

Malicious package detection runs automatically for all supported package formats in your workspace, with no configuration required. Every supported package in your workspace is checked against trusted threat intelligence both at upload and every 5 minutes thereafter, so newly identified malicious packages are matched against artifacts you already have in near real time.

Detection results feed into observability via the Cloudsmith web app and the Cloudsmith API, and into control via Cloudsmith’s policy management. Packages are matched to malicious package advisories on a shared package URL (PURL). Cloudsmith extracts the PURL at sync (for Docker, component PURLs come from the SBOM), and OSV.dev advisories carry the PURLs of affected packages and versions. The match happens wherever the two share a PURL.

Supported formats

Package formats supported by the OSSF Malicious Packages project:

  • Cargo
  • Docker (supported language formats only)
  • Go
  • Maven
  • npm
  • NuGet
  • PyPI
  • RubyGems

Note

While these formats are supported, some ecosystems have more reported detections than others. npm, PyPI, RubyGems, and NuGet have the most reports. To learn more, visit: OSSF Malicious Package Report Statistics.

Reviewing malicious package detections

You can view malicious package detections via the Cloudsmith web app and API.

Via the Cloudsmith web app

If a package is detected as malicious, it is flagged as malware on the package Overview tab. To see more information about the malicious package record, click the Vulnerabilities found card or the Compliance tab for the package. You can also manually quarantine the package from this view.

Any packages detected as malicious are also clearly flagged as malware on the workspace and repository Compliance tabs.

You can filter and search for packages detected as malicious by using the package search syntax with the search term malware:true. You can also search for packages impacted by a specific malware record by using the vulnerability_id search term and the specific ID for the malware record (for example, MAL-2025-3529).

Via the Cloudsmith API

You can use the Cloudsmith vulnerabilities API endpoints to return the details of any package detected as malicious for an entire workspace, a specific repository, or an individual package. For details, see: