Known-CVE triage

Known-CVE triage

TL;DR: Mapping a fingerprinted version to a real exploitable CVE without burning time on PoC tarpits, fake exploits, or version-string spoofs.

What it is

Known-CVE triage is the disciplined step between “I have a banner” and “I have a working primitive.” Scanners spit out CPE→CVE matches; most are noise — wrong build, patched downstream by the distro, missing prerequisite config, or already mitigated by a workaround. Triage filters that list to a small set of CVEs that (a) match the exact build, (b) have a public exploit that actually works, (c) hit the configuration in front of you, and (d) carry an impact worth chasing (pre-auth RCE > auth RCE > info-disclosure).

Preconditions / where it applies

  • A precise version string — patch level, build, distro backport — not a major.minor guess.
  • Knowledge of which features/components are enabled (modules, plugins, auth providers).
  • Time budget: triage is cheap, blind PoC roulette burns hours and tips off defenders.
  • Related: exposed-services, port-scanning, http-enum.

Technique

Pin the version. Banner alone lies — Debian/RHEL backport patches into old version strings, vendors strip identifiers, appliances rebrand. Cross-check with:

  • Changelog hash / build date in /version, /_admin/about, Server header, package metadata.
  • searchsploit -t <product> <version> for Exploit-DB locals.
  • nuclei -t http/cves/ with a tag filter (-tags cve,rce,year-2024) for templated checks that respect prerequisites.

Filter the CVE list:

1
2
3
4
5
6
7
8

# 1. Pull NVD entries for the product
curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:vendor:product:1.2.3:*:*:*:*:*:*:*" | jq '.vulnerabilities[].cve.id'

# 2. Cross-reference with exploit availability
searchsploit product 1.2.3
# 3. Check distro security tracker for backport status
# https://security-tracker.debian.org/tracker/<CVE>
# https://access.redhat.com/security/cve/<CVE>

Score each candidate against four axes: auth required, network reachable, default config, public PoC quality. Pre-auth + network + default + working PoC → drop everything else and try it. Auth-required + non-default → keep as fallback after creds.

Validate the PoC in a throwaway lab matching the target build before firing at production. Many GitHub “exploits” are info-stealers, broken, or only work against the author’s specific commit. Read the code. Check it against the original advisory.

For appliances (firewalls, MFTs, ADCs) prioritise CVEs from the last 24 months that appear on CISA KEV — these are the ones with reliable exploitation in the wild and are also the ones defenders most often forget to patch on internal segments.

Detection and defence

  • Blue team sees scanner-shaped traffic (nuclei UA, sequential CVE-template requests) and PoC-specific URI patterns; rate-limited WAFs catch the spray.
  • Defenders should subscribe to CISA KEV and vendor advisories, run authenticated vuln scans (Nessus, Qualys) that read installed package versions instead of guessing from banners, and patch on a KEV-prioritised SLA.
  • Compensating controls: WAF virtual patches for known CVE signatures, network segmentation so a CVE in one appliance does not pivot, and version-string suppression to slow opportunistic attackers (defence in depth, not a fix).

References