Known Vulnerable Package Installation
This rule flags when someone installs a software package via pip (Python) or npm (Node.js) that has a publicly known vulnerability. It relies on a fixed, built-in list of high-severity vulnerable packages rather than checking a live vulnerability database, so it only catches vulnerabilities that were known at the time the list was built.
How the attack works
An agent or user runs a pip or npm install command for a specific package and version. The rule checks the package name and version against a static list of packages with known CVEs. If it matches, an alert fires. This does not require any live lookup against OSV.dev or similar services, so it works offline but can miss anything disclosed after the list was created.
Netzilo detection
Netzilo can block this behaviour when it is observed.
- Signature ID
- b1e2f3a4-b5c6-4d78-9012-e3f4a5b6c7d8
- Severity
- High
Why it matters
An organization can end up running software with a publicly documented, exploitable weakness, which increases the chance of compromise through that specific vulnerability. Because the list is static, newly disclosed vulnerabilities in packages not on the list will not be caught.
What you can do
- →Run installed dependencies through an up-to-date vulnerability scanner (e.g. OSV.dev, npm audit, pip-audit) regularly, not just at install time.
- →Pin dependency versions deliberately and review changes before upgrading or downgrading.
- →If a flagged install is intentional (e.g. security research or a legacy compatibility requirement), isolate it in a sandboxed or non-production environment.
- →Maintain an internal process to refresh vulnerable-package lists frequently, since static snapshots go stale quickly.
Known benign look-alikes
- Security researchers intentionally installing vulnerable packages for testing
- Legacy projects pinned to these versions for compatibility