Website Vulnerability Scanner API: CVE + CPE Detection (2026)

Most vulnerability scanners are built for internal networks: they probe ports, test authentication, and run exploitation checks. But if you need to assess the external attack surface of a website — what technologies it runs, what versions are exposed, and which of those versions have known CVEs — you need a different approach.

The DetectZeStack GET /vulnerability endpoint combines technology fingerprinting with NVD lookups to answer a simple question: does this website run any software with known vulnerabilities?

How It Works: Detection to CVE in One Request

The /vulnerability endpoint performs three steps in a single API call:

1. Technology fingerprinting — Scans the target URL using HTTP response analysis, HTML content parsing, JavaScript library detection, DNS CNAME resolution, and TLS certificate inspection to identify technologies and their versions
2. CPE mapping — Maps each detected technology that has a version to its CPE (Common Platform Enumeration) identifier. Technologies without a detected version are excluded from vulnerability scanning.
3. NVD lookup — Queries the National Vulnerability Database for CVEs matching each CPE + version combination using strict version matching

What Is Strict Version Matching?

This is the most important design decision in the endpoint. DetectZeStack uses strict version matching: it only reports CVEs that affect the exact version detected on the website.

If the scanner detects jQuery 3.3.1, it queries the NVD for CVEs that affect cpe:2.3:a:jquery:jquery:3.3.1. It does not guess version ranges, infer patch levels, or assume the website has not applied backport patches.

Why this matters:

• Fewer false positives — Many vulnerability scanners report CVEs based on version ranges (e.g., "jQuery < 3.5.0 is vulnerable"). This leads to reports with dozens of CVEs that may not actually apply if the version has been patched. Strict matching only reports what is definitively affected.
• Honest limitations — If a technology is detected but its version cannot be determined from external signals, it is excluded from the scan entirely. The response tells you how many technologies were scanned vs. how many had CPE identifiers, so you know the coverage.
• No version is required for detection, but it is required for CVE matching — The technologies_scanned field shows total detected technologies. The technologies_with_cpe field shows how many had both a CPE and a version — these are the ones checked against the NVD.

API Request and Response

curl -s "https://detectzestack.p.rapidapi.com/vulnerability?url=example.com" \
  -H "x-rapidapi-key: YOUR_API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" | python3 -m json.tool

Example response:

{
  "domain": "example.com",
  "scan_date": "2026-04-11T14:23:07Z",
  "technologies_scanned": 18,
  "technologies_with_cpe": 4,
  "vulnerabilities_found": 3,
  "severity_summary": {
    "critical": 0,
    "high": 1,
    "medium": 2,
    "low": 0
  },
  "vulnerabilities": [
    {
      "cve_id": "CVE-2020-11023",
      "technology": "jQuery",
      "version_detected": "3.3.1",
      "severity": "MEDIUM",
      "cvss_score": 6.1,
      "summary": "In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing  elements from untrusted sources to one of jQuery's DOM manipulation methods may execute untrusted code.",
      "published_date": "2020-04-29",
      "references": [
        "https://nvd.nist.gov/vuln/detail/CVE-2020-11023",
        "https://github.com/jquery/jquery/security/advisories/GHSA-jpcq-cgw6-v4j6"
      ]
    },
    {
      "cve_id": "CVE-2020-11022",
      "technology": "jQuery",
      "version_detected": "3.3.1",
      "severity": "MEDIUM",
      "cvss_score": 6.1,
      "summary": "In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources to one of jQuery's DOM manipulation methods may execute untrusted code.",
      "published_date": "2020-04-29",
      "references": [
        "https://nvd.nist.gov/vuln/detail/CVE-2020-11022"
      ]
    },
    {
      "cve_id": "CVE-2023-44487",
      "technology": "nginx",
      "version_detected": "1.18.0",
      "severity": "HIGH",
      "cvss_score": 7.5,
      "summary": "The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023.",
      "published_date": "2023-10-10",
      "references": [
        "https://nvd.nist.gov/vuln/detail/CVE-2023-44487"
      ]
    }
  ],
  "disclaimer": "This product uses the NVD API but is not endorsed or certified by the NVD.",
  "response_ms": 1847,
  "cached": false
}

Response Field Reference

Filtering by Severity

Use the severity query parameter to filter results. This is useful for alerting workflows where you only care about critical or high-severity CVEs:

# Only return HIGH and above
curl -s "https://detectzestack.p.rapidapi.com/vulnerability?url=example.com&severity=HIGH" \
  -H "x-rapidapi-key: YOUR_API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com"

Valid severity values: CRITICAL, HIGH, MEDIUM, LOW.

Understanding CPE Identifiers

CPE (Common Platform Enumeration) is the glue between technology detection and vulnerability data. A CPE identifier follows this structure:

cpe:2.3:a:vendor:product:version:update:edition:language:sw_edition:target_sw:target_hw:other

Example: cpe:2.3:a:jquery:jquery:3.3.1:*:*:*:*:*:*:*
         cpe:2.3:a:apache:http_server:2.4.41:*:*:*:*:*:*:*
         cpe:2.3:a:nginx:nginx:1.18.0:*:*:*:*:*:*:*

When DetectZeStack detects jQuery version 3.3.1 on a website, it constructs the CPE cpe:2.3:a:jquery:jquery:3.3.1 and queries the NVD for all CVEs that reference this CPE. The NVD returns matched CVEs with their CVSS scores, summaries, and reference links.

For a deeper dive into CPE naming conventions, see CPE Identifiers Explained for Security Teams.

Use Cases for Security Teams and MSSPs

1. External Attack Surface Assessment

Before an engagement, scan the target domain to get a quick inventory of externally-visible technologies and their known CVEs. This gives the assessment team a starting point for prioritization without requiring credentialed access.

# Quick triage: how many CVEs are exposed?
curl -s "https://detectzestack.p.rapidapi.com/vulnerability?url=target.com" \
  -H "x-rapidapi-key: YOUR_API_KEY" \
  -H "x-rapidapi-host: detectzestack.p.rapidapi.com" \
  | python3 -c "
import sys, json
d = json.load(sys.stdin)
print(f'Technologies scanned: {d[\"technologies_scanned\"]}')
print(f'Technologies with CPE: {d[\"technologies_with_cpe\"]}')
print(f'CVEs found: {d[\"vulnerabilities_found\"]}')
for sev, count in d['severity_summary'].items():
    if count > 0:
        print(f'  {sev.upper()}: {count}')
"

2. Vendor Risk Assessment

MSSPs managing multiple clients need to monitor third-party vendor risk continuously. A weekly scan of vendor domains reveals if they are running software with known CVEs — without needing to ask the vendor to fill out a questionnaire.

#!/bin/bash
# vendor-risk-scan.sh
# Scan a list of vendor domains and flag any with HIGH/CRITICAL CVEs

VENDORS=("vendor1.com" "vendor2.com" "vendor3.com" "vendor4.com")

for vendor in "${VENDORS[@]}"; do
  RESULT=$(curl -s "https://detectzestack.p.rapidapi.com/vulnerability?url=$vendor" \
    -H "x-rapidapi-key: $RAPIDAPI_KEY" \
    -H "x-rapidapi-host: detectzestack.p.rapidapi.com")

  CRITICAL=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin)['severity_summary']['critical'])")
  HIGH=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin)['severity_summary']['high'])")
  TOTAL=$(echo "$RESULT" | python3 -c "import sys,json; print(json.load(sys.stdin)['vulnerabilities_found'])")

  if [ "$CRITICAL" -gt 0 ] || [ "$HIGH" -gt 0 ]; then
    echo "ALERT: $vendor has $CRITICAL critical, $HIGH high CVEs ($TOTAL total)"
  else
    echo "OK: $vendor ($TOTAL CVEs, none high/critical)"
  fi
  sleep 1
done

3. Client Reporting

For MSSPs producing monthly security reports, the /vulnerability endpoint provides structured data that can be fed directly into reporting templates. The severity_summary gives the executive overview, and the vulnerabilities array provides the technical detail.

4. Continuous Monitoring

Set up a cron job to scan client-facing domains daily. When a new CVE is published that affects a detected technology version, the next scan will include it in the results. Alert on any increase in the vulnerabilities_found count.

What This Is Not

It is important to be clear about the scope of this endpoint:

• Not a penetration testing tool — This endpoint does not exploit vulnerabilities, send malicious payloads, or test authentication. It detects technologies and checks versions against the NVD.
• Not a network scanner — It does not probe ports, test SSL/TLS configurations, or discover hidden services. For SSL analysis, use the separate GET /certificate/check endpoint.
• Not a replacement for authenticated scanning — Internal applications, APIs behind authentication, and server-side components that do not expose version information through HTTP responses are not detected. The scanner only sees what is visible externally.
• Not guaranteed to catch everything — If a technology is detected without a version number, it cannot be checked against the NVD. The technologies_scanned vs. technologies_with_cpe fields tell you exactly what the coverage is.

Pricing vs. Enterprise Vulnerability Scanners

DetectZeStack is not a replacement for Qualys or Tenable in a full vulnerability management program. It fills a different niche: fast, external, technology-focused CVE exposure assessment at a price point accessible to freelance security consultants, small MSSPs, and startups that cannot justify $15,000+/year for an enterprise scanner.

Combining with Other Endpoints

The /vulnerability endpoint is one part of a broader security assessment workflow. With the same API key, you can also run:

• Security headers grading (GET /security) — Grade any website A+ to F on HTTP security headers (HSTS, CSP, X-Frame-Options, etc.)
• SSL/TLS certificate analysis (GET /certificate/check) — Check certificate validity, expiration, issuer, and configuration issues
• Full technology detection (GET /analyze) — Get the complete tech stack with versions, categories, and confidence scores
• DNS intelligence (GET /dns) — Reveal hosting, CDN, and email infrastructure

Together, these endpoints give you an external security posture snapshot: what technologies a website runs, whether those technologies have known vulnerabilities, whether security headers are properly configured, and whether the SSL certificate is valid.

For an interactive security assessment, try the Security Audit page — no API key needed.