Affiliate Disclosure: This site contains affiliate links. We earn a commission when you purchase through our links at no additional cost to you.

Most hunters use the NVD the wrong way. They find a version disclosure, look up the CVE after the fact, and paste the CVSS score into their report. Useful, but backwards.

CVE data is a pre-scan intelligence source. Before you send a single request to a target, you can extract its tech stack from headers and JS bundles, query NVD’s free API, filter for publicly exploitable CVEs, and build a ranked hit-list. You’re not fishing anymore. You know what you’re looking for before you start.

SecurityClaw’s CVE Intelligence Module does this automatically. Here’s how it works, and how to replicate it manually if you want to build your own version.

Pull the tech stack from HTTP headers

Targets announce themselves constantly. A simple curl -I target.com tells you a lot:

Server: nginx/1.18.0
X-Powered-By: PHP/8.1.12
Via: 1.1 varnish

JS bundles often leak framework versions in comments:

// webpack 5.75.0 chunk

Login pages fingerprint themselves through field naming conventions (Laravel’s CSRF token format, Drupal’s /sites/default/ paths), cookie names (PHPSESSID vs JSESSIONID), and response body patterns (wp-content, /laravel/).

What to capture:

  • Server: header — web server and version
  • X-Powered-By: — application framework
  • X-Generator: / X-Drupal-Cache: — CMS
  • JS bundle comments and filenames — frontend framework versions
  • Cookie names — backend clue
  • Response body patterns

You don’t need a full version string. nginx/1.18 is enough to run a targeted NVD query.

Query the NVD API v2

The National Vulnerability Database has a free REST API that most hunters never touch directly:

GET https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=nginx&resultsPerPage=20

Useful parameters:

  • keywordSearch — technology name (nginx, apache httpd, openssl)
  • cvssV3Severity — filter to CRITICAL or HIGH
  • pubStartDate / pubEndDate — narrow to recent CVEs

Without an API key you get 5 requests per 30 seconds. With one, it’s 50. Register at https://nvd.nist.gov/developers/request-an-api-key — it’s instant and free.

A simplified response looks like this:

{
  "vulnerabilities": [{
    "cve": {
      "id": "CVE-2024-7347",
      "descriptions": [{"lang":"en","value":"nginx before 1.27.1..."}],
      "metrics": {"cvssMetricV31": [{"cvssData": {"baseScore": 7.1}}]}
    }
  }]
}

Run this for each technology you extracted in step 1. You’ll end up with a list of CVEs that plausibly apply to your target — but “plausibly applies” isn’t the same as “worth pursuing.”

Cross-reference Exploit-DB

A CVSS 9.8 CVE with no public exploit is much harder to work with than a CVSS 7.5 CVE that has a working PoC on Exploit-DB. Theoretical vulnerabilities are hard to demonstrate impact. Most platforms want to see you prove it, not cite it.

Exploit-DB has a search endpoint:

GET https://exploit-db.com/search?cve=2024-7347&type=webapps&format=json

If the response data array is non-empty, the CVE has a public exploit. Flag it. That one flag can rearrange your entire campaign priority order.

Score and rank

Once you have CVE records with exploit status, score them:

score = (cvss_score * 5) + (30 if has_public_exploit else 0) + (tech_matches * 5)
score = min(100, score)

What this weights:

  • CVSS contributes up to 50 points (CVSS 10.0 Ă— 5)
  • Public exploit availability adds a flat 30
  • Tech stack match adds 5 per confirmed match — this is what separates “nginx CVE” from “this server is running nginx 1.18.0, which is confirmed in-scope for this CVE”

Sort descending. Your top 10 are the CVEs to verify first.

The tech match bonus matters more than it looks. SecurityClaw’s module correctly ranked two submittable Apache findings in the top 5 across a recent three-campaign batch, while filtering a false positive to rank 12. The false positive was a CVE that affected nginx < 1.18.0, but the target was running 1.25.x. Without the tech match check, it would have ranked higher than it deserved.

What this looks like in a real campaign

Over that same three-campaign batch:

  • 2 Apache version disclosures cross-referenced with unpatched CVEs, both submitted as MEDIUM
  • 1 false positive filtered (target’s nginx version was outside affected range)
  • 3 “interesting but unconfirmable” CVEs deferred — they needed authenticated access to verify

That’s not a massive hit rate. But you’re spending your campaign time on findings that are likely to land, not investigating every CVE that mentions a technology your target happens to run.

The weekly briefing pattern

SecurityClaw runs a CVE briefing every Monday before the week’s campaigns start:

python scripts/weekly_cve_briefing.py \
  --tech nginx apache openssl php \
  --lookback-days 7 \
  --top-n 10 \
  --output research/weekly-cve-2026-05-13.md

Output is a ranked markdown table: CVE ID, CVSS score, exploit flag, tech match count, and total score. Runs in 30-60 seconds (NVD rate limits). High-scoring CVEs with good narratives (vendor silent for 90 days, widely exploited in the wild) go into the content queue.

You don’t need the full automation to get value from this pattern. Running the query manually before a campaign takes 15 minutes per target.

What actually makes a CVE worth pursuing

Not all CVEs convert to bounties. The signals that matter:

SignalWhy
Confirmed version match on targetYou have evidence the target is affected, not just potentially affected
Exploit-DB entry or public PoCYou can demonstrate impact
CVSS 7.0+Most platforms have a minimum severity floor for bounty payouts
Target hasn’t patchedCheck headers for a version bump after CVE publication
In-scope componentThe vulnerable component is actually covered by the program’s scope

What to skip: theoretical CVEs without PoC, CVEs targeting versions the server isn’t running, informational CVEs below CVSS 4.0. Most programs won’t pay on those, and demonstrating impact on an unconfirmed version is difficult to do cleanly in a report.

Build a minimal version yourself

You don’t need SecurityClaw to run this workflow:

  1. curl -I target.com — parse Server: and X-Powered-By: headers
  2. NVD API query by keyword + cvssV3Severity=HIGH
  3. Exploit-DB search for each CVE
  4. CVSS + exploit flag in a spreadsheet, sorted descending

15 minutes per target, manual. SecurityClaw does it in under 60 seconds per campaign by automating the API calls and parsing.

Resources