Newest indicator first seen 2026-10-06.
Sources
abuse.ch URLhausCC0-1.0 (public domain)
Malware distribution URLs and domains. Used to match indicators embedded INSIDE a scanned artifact.
Freshness: Refreshed daily.
What it cannot tell you: Covers where malware is served from, not what a package contains. It essentially never holds an npm package hash, which is why npm identity is answered from OSV instead.
abuse.ch ThreatFoxCC0-1.0 (public domain)
Command-and-control indicators: IPs, domains, and file hashes tied to active malware families.
Freshness: Refreshed daily.
What it cannot tell you: Indicator-based. A brand-new C2 that nobody has reported yet is not in it, and neither are we.
OSV / OpenSSF malicious-packagesCC-BY-4.0 (advisory data)
Published malicious-package advisories (MAL- records and equivalent GHSA malware advisories). This is what makes a `malicious` verdict reachable for npm at all.
Freshness: Queried live per request, never a stale local copy.
What it cannot tell you: Advisories land AFTER a compromise is discovered, sometimes days after. A package published as malware an hour ago is not in it yet. Coverage is also version-scoped, so an unpinned name may be unanswerable.
Lazaretto rule engineProprietary
Deterministic behavioral rules over the artifact itself: credential access, exfiltration, obfuscation, dynamic execution, persistence, install-time droppers, prompt injection aimed at an agent.
Freshness: Versioned; every change bumps `rules_version` and invalidates cached verdicts.
What it cannot tell you: Heuristics, so they cap at `flagged` and never produce `malicious` on their own. They read source text: a minified or packed bundle is reported as partially analyzed rather than silently skipped.
Licences we hold indicators under
CC0-1.0: 78,502 indicatorsinternal-corpus: 16 indicators
The abuse.ch feeds are public domain, so crediting them is not a licence obligation. We do it because you deserve to know whose data is behind a verdict, and a source we would be reluctant to name would be a source we should not be using.
What we do not cover
Stated as plainly as the coverage above, because a clear verdict being read as a
clean bill of health is the one misunderstanding this product cannot afford:
- We do not execute anything. Behavior that only appears at run time, against a live C2, or on a specific OS, is outside what static analysis can see.
- We do not detect novel malware by reputation or machine learning. If no indicator matches and no rule fires, we say exactly that, and it is not a clean bill of health.
- Very large packages can exceed our size budget. When that happens the report is marked partial rather than returned as a confident `clear`.
- A minified or bundled artifact is only partly readable by source-level rules, and every report says so when it happens.
- Advisory feeds are retrospective. The window between a malicious release and its advisory is real, and nothing here closes it.
How these sources behave in practice
Naming an upstream says where the data came from, not how much of it lands as noise on a package you meant to install. That is measured separately and published with the corpus attached, including the packages we flagged out of a list people install on purpose, and every attack sample of ours that goes undetected: how often we flag a package people install on purpose.
Check us
Live counts and freshness: /v1/health · rule catalog: /v1/rules · our own noise numbers: /benchmark · mistakes we have corrected: /corrections