Malicious packages and repository malware
Know when a malicious package is installed anywhere you work
Lockhound flags known malicious package versions from the OpenSSF database across npm, PyPI, Composer, RubyGems, Go, Cargo and Maven, and checks your repositories for malware committed into build files and editor tasks.
A malicious package is not a vulnerability waiting for a patch. It is an attack that already ran the moment someone typed npm install. What matters is finding out quickly, everywhere, and knowing what to do next.
What Lockhound catches
Known malicious package versions. The OpenSSF Malicious Packages project catalogues malicious releases reported across registries, and publishes them through OSV. Lockhound checks every exact version in every lockfile you have against that data, on every scan and every pull request. It also re-checks them daily, so a package that was clean when you installed it is flagged when it is later reported.
Malware committed into a repository. Some campaigns, such as PolinRider, never touch a registry. They plant code in files developers run without reading: a VS Code tasks.json that executes on folder open, an appended line in postcss.config.mjs or vite.config.js, a "font" file that is really a script. Lockhound reads the small set of files these attacks are known to hide in, never your whole codebase, and checks them against published indicators. It does this on your main branch and on the files each pull request changes.
What happens when one is found
- It goes to the top of every list, marked Fix now, whatever its severity score.
- Slack or email channels are alerted, even ones set to critical-only.
- The pull request check fails if a pull request introduces it.
- You get the right next step: the command to remove a direct dependency, or the command to find which package pulls in a transitive one (
npm ls,composer why,uv tree --invert). It also reminds you to rotate the secrets every affected machine could reach.
What it doesn't do
Lockhound is advisory-based. It recognises malicious versions once they have been reported, which typically takes hours to days after publication. It does not analyse unpublished or brand-new package code itself, and it doesn't block installs on developer machines. If you need install-time blocking, pair it with a registry firewall. Lockhound gives you the inventory-wide view and the history: which repositories, which versions, since when.
Which ecosystems
Known malicious versions are checked for every ecosystem Lockhound reads: npm, Yarn and pnpm, Composer, PyPI (uv, Poetry, Pipenv, requirements), Go modules, Cargo, RubyGems and Gradle. Coverage depends on what the OpenSSF database holds for each, and npm and PyPI have by far the most reports.
Check a lockfile now, without signing up.
Read next
- Malicious packages, how they work and how to catch themMalicious packages don't have bugs, they are the attack. How they get into projects, why install scripts matter, how to check your lockfile against known malicious versions, and what to do if you find one.
- npm, Yarn and pnpm dependency security that ranks what mattersLockhound reads package-lock.json, yarn.lock (classic and Berry) and pnpm-lock.yaml across your GitHub repositories, flags exploited and malicious packages first, and keeps dev-only noise out of the way.