A vulnerable package is legitimate software with a flaw an attacker could exploit. A malicious package is built to cause harm, such as stealing credentials. You fix the first by upgrading. You handle the second as an incident, because the harm may already have happened when it was installed.
Side by side
| Vulnerable package | Malicious package | |
|---|---|---|
| Intent of the author | Honest, with a bug | Hostile |
| Typical record | CVE or advisory with affected and fixed versions | Malware report, removal, advisory |
| When harm occurs | When the flaw is reachable and exploited | Often at install or import |
| Usual fix | Upgrade, patch or mitigate | Remove, rotate secrets, rebuild |
| Severity score | CVSS style score common | Often no score, treat as critical |
How the records differ
Vulnerabilities are usually tracked with CVE identifiers and ecosystem advisories. Malicious packages have their own databases. The OpenSSF malicious packages repository describes itself as a database of reports of malicious packages, consumable in the OSV format. The OSV schema lists a MAL prefix for the Malicious Packages Repository.
This matters because a scanner that only reads CVE feeds can miss a malicious package that has no CVE. Ask your tools which sources they use, and check that malware advisories are one of them.
Why the response differs
With a vulnerability, you ask whether you are exposed. Is the vulnerable code present, and can an attacker reach it? That is where reachability analysis helps you rank fixes.
With malware, the question is whether it was ever installed and where. A fixed version may not exist, and no upgrade removes the code that already ran. Response means removal, secret rotation and a search across projects. See what to do after installing a malicious package.
Gray areas
Some cases blur the line:
- A trusted package whose maintainer account was taken over and pushed a bad release. The package is normally legitimate, but that version is malicious.
- A legitimate package abandoned and later transferred to a new owner. See abandoned package takeover risks.
- A package that is dual use, such as a security testing tool.
Treat each affected version as the unit, not the package name.
Click through it at your own pace, or open it full screen. Look at how findings are grouped by package and version.
Quick check
Does a clean vulnerability scan mean no malicious packages?
No. A scan against CVE data alone can miss a malicious package with no CVE. Confirm what advisory sources your tools use.
Is a malicious package always removed from the registry?
Not immediately. Registries act after a report is confirmed, so there can be a window where the package is still downloadable.
Safeguard does SBOM and dependency scanning and reachability analysis, with a free scan if you want to try it.
Sources
Last reviewed: 19 October 2026.
