How to Use CVE Enrichment for Bug Bounty Triage

On a bug bounty engagement, CVE enrichment is how you spend the next hour of recon where a bug is most likely to be real and impactful, instead of chasing every CVE a scanner spat out. Enrichment attaches known-exploited status, exploitation probability, affected versions and exploit availability to each finding, so you can rank by likelihood, not by CVSS. This workflow uses vulntel's MCP tools; the same logic applies to any vulnerability intelligence API.

How to enrich a CVE for bug bounty triage

1. Catalog the stack. Fingerprint the target's technologies and versions from recon, then call hunt_plan on that stack to get a ranked dig-order plus the recurring weak spots to check first.
2. Pull the version-specific CVEs. For each product, call check_technology with the exact version to get the CVEs that actually affect it, not the vendor's whole history.
3. Enrich each candidate. Call enrich_cve on a finding to fuse KEV status, EPSS score, SSVC decision and the public-exploit signal into one record.
4. Verify the claim before you act. Call verify_cve_claim to confirm the CVE exists, affects the claimed version, and has the severity and exploited-status you think it does, so a hallucinated or misremembered detail never reaches your report.
5. Rank exploitation-first. Sort by KEV and EPSS, not CVSS: a known-exploited or high-EPSS bug on an in-scope asset beats a higher-CVSS one that nothing is exploiting.
6. Read the fix to confirm reachability. Use search_public_code to find how the bug was patched in the wild, then check whether the target's version sits before that fix and whether the vulnerable path is reachable.

Why exploitation-first ranking wins

Most CVEs are never exploited. In a corpus of ~330,000 CVEs, only about 0.5% are in CISA KEV, and EPSS beat CVSS by roughly 10x at predicting real-world exploitation. Triaging by CVSS alone means spending your best hours on bugs nobody attacks. Enrichment moves that hour to the findings that carry an exploitation signal.

FAQ

How do I prioritize CVEs on a bug bounty engagement? Enrich each finding with KEV, EPSS and SSVC, then rank exploitation-first: known-exploited and high-EPSS bugs on in-scope assets come before higher-CVSS bugs with no exploitation signal.

How do I avoid submitting a wrong CVE in a report? Verify it before you write it up. verify_cve_claim returns a per-assertion verdict (exists, affected version, severity, exploited) with evidence, which catches hallucinated CVEs before they cost you credibility.

Which tools do I need for CVE enrichment during triage? A way to map the stack to CVEs (hunt_plan, check_technology), to enrich a finding (enrich_cve), to verify it (verify_cve_claim), and to read the real-world fix (search_public_code). vulntel exposes all of these over MCP.

Is enriching CVEs useful if I only test one target? Yes. Even for one target, enrichment tells you which of its known CVEs carry an exploitation signal, so you start with the findings most likely to be real and reachable.