CVE Triage

Turn version/banner evidence from recon into a prioritized, exploitability-aware list of CVEs worth verifying. Use this after fingerprinting a service, when a banner or Server: header reveals a product and version, or whenever the target exposes software with a known version.

The cve_lookup tool

VulnClaw ships a read-only cve_lookup tool backed by NVD:

• Keyword search — cve_lookup(query="Apache httpd 2.4.49", limit=5) returns the top CVEs sorted by CVSS, highest first.
• CVE-ID detail — cve_lookup(query="CVE-2021-44228") returns the full record plus best-effort exploit / PoC repositories discovered on GitHub.

It performs no egress to the target and is safe during recon. Without an NVD_API_KEY it still works (lower rate limit); set one for heavier use.

Workflow

1. Extract product + version from recon — service banners, Server headers, JS bundles, login footers, package manifests. A precise version string (OpenSSH 8.2p1, nginx 1.18.0) yields far better matches than a bare name.
2. Query cve_lookup with "<product> <version>". Pull the detail record for any high/critical hit by re-querying its CVE-ID.
3. Score & prioritize — see references/cve-triage-workflow.md. Rank by CVSS, then by exploit availability, then by exposure (is the vulnerable surface actually reachable on this target?).
4. Confirm version applicability — match the target's version against the CVE's affected cpe range before claiming it. Banner ≠ proof of vulnerability.
5. Record findings with the CVE-ID, CVSS, and the evidence that maps this target to it. Mark unconfirmed version-only matches as needs-manual-review, not verified.

Pitfalls

• A keyword match is a hypothesis, not a finding — version ranges and backported patches mean a banner version can be patched in place.
• GitHub "PoC" repos are unverified third-party code; treat as leads, never run blindly against a target.
• Prefer the CVSS base score for triage, but let exploit availability and real exposure override raw score when prioritizing verification effort.