CVE Research

Two knowledge sources, always use in this order: (1) the bundled knowledge base (vuln-db/entries/) for curated detection guidance, (2) live lookups for freshness.

Step 1 — Know the exact stack

From manifests/config (or a previous audit's Stack section): framework name + version, language runtime version, key infrastructure (nginx, postgres, redis...) + versions. No versions → find them first (package.json, go.mod, Pipfile, Dockerfile base images).

Step 2 — Bundled knowledge base

Read vuln-db/README.md for the entry format, then scan vuln-db/entries/*.md frontmatter (ecosystem, affected) for matches with the stack. Each matching entry has a Detection section: what to grep, what config value to check. Run those checks and report matches with the entry's fix guidance.

For severity narratives and prioritization, load references/notable-incidents.md — it maps real breaches and mass-exploitation waves (Equifax, Capital One, SolarWinds, Log4Shell, MOVEit, Jenkins/Confluence takeovers, npm token heists) to the exact checks in these skills. When a finding's class has KEV + public exploit modules + a named incident behind it, the fix stops being advisory.

Step 3 — Live lookups (network required)

Dependencies → OSV.dev

python3 ../dependency-vulns/scripts/osv_scan.py <project_root>

CISA KEV (actively exploited — priority zero)

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "
import json,sys
d=json.load(sys.stdin)
for v in d['vulnerabilities']:
    p=v['vendorProject'].lower()+' '+v['product'].lower()
    print(v['cveID'], '|', v['vendorProject'], v['product'], '|', v.get('dateAdded'), '| due:', v.get('dueDate'))
" | grep -iE "<product1|<product2|<framework>"

Replace the grep with the stack's product names (e.g. struts|log4j|confluence|nginx|tomcat). Any hit on an in-use product/version → CRITICAL, fix by KEV dueDate.

One-off CVE lookup

curl -s "https://api.osv.dev/v1/query" -d '{"package":{"ecosystem":"npm","name":"express"},"version":"4.17.0"}'

Backport verification (stable/distro pins — Trail of Bits 2026-11-02 lesson)

Upstream "fixed: X" does NOT mean a stable-branch/distro package is fixed: thousands of CVEs never get backported to the LTS trees most installs actually run (ToB measured 95%+ of installs on stable trees; their Codex backport project delivered only 149 kernel CVEs by 2026-10-29). For system packages and old-but-pinned deps, the check is "does MY distro's package carry the fix", not "is my version ≥ upstream fixed":

• Look up the DISTRO advisory, not upstream: Ubuntu USN/OVAL, Debian security tracker (https://security-tracker.debian.org/tracker/<CVE>), RHEL/Alma errata — their fixed-package versions (with vendor suffixes) are the truth.
• No distro advisory for the CVE + pinned old tree = ASSUME VULNERABLE (the backport may simply not exist) — flag it, don't clear it on version math.
• The inverse false positive stays: a vendor-suffixed old version listed in the distro advisory IS fixed — never flag it because upstream says so (see vuln-db README false-positive discipline).

In-the-wild 0-day tracker (Project Zero)

Each tracked 0-day is a markdown file (0day-RCAs/<year>/CVE-*.md) in the googleprojectzero/0days-in-the-wild repo. Check a specific CVE via the GitHub API, or browse by year:

curl -s "https://api.github.com/repos/googleprojectzero/0days-in-the-wild/contents/0day-RCAs/$(date +%Y)" | grep -o '"CVE-[0-9-]*"' | tr -d '"'

A hit means the CVE was exploited in the wild as a 0-day — severity ceiling for any affected finding. A weekly digest workflow (watch-0days.yml) triages new entries automatically.

Public exploit availability (Metasploit / exploit-db)

If a local metasploit checkout exists: rg -l "<CVE>" modules/exploit/. Otherwise check the module listing at rapid7/metasploit-framework modules/exploit/** (advisory text usually states it). A public module turns 'theoretical' into drop-in weaponized — record it in the finding and in the vuln-db entry Summary.

If web search is available

Search "<framework> <version>" CVE site:nvd.nist.gov and the project's GitHub Security Advisories. Prefer NVD/GHSA/OSV over blogs for severity; blogs for exploitation details. High-signal sources in order: vendor PSIRT/advisory pages, Project Zero blog + the 0days-in-the-wild tracker, GitHub Security Lab (code-level writeups), PortSwigger research (new web classes), Snyk/Tenable writeups (ecosystem reach), exploit-db/Metasploit for weaponization status.

Step 4 — Report & watchlist

• Match confirmed (version in affected range): severity, entry/CVE, detection evidence, fix version or mitigation.
• Match possible (can't pin version): what to check, exact command to run.
• Produce a watchlist: top 5 products in this stack to monitor, so future CVE triage is instant.

Maintainer mode: adding an entry

When a new relevant vulnerability goes public, create vuln-db/entries/YYYY-MM-DD-<cve-or-id>.md using the template at vuln-db/entry-template.md — then PR it per CONTRIBUTING.md. The weekly automation (.github/workflows/update-kev.yml) flags new KEV additions as issues to remind maintainers.