Vulnerability matching

1. Detecting products and versions

During the fingerprint step the scanner records what each host announces about itself, and normalises it to one of 45 products in a curated catalog: web servers, SSH, mail and FTP servers, content management systems, application servers, VPN and edge appliances, DevOps tools and front-end JavaScript libraries. Evidence comes from:

• the Server and X-Powered-By response headers;
• the page's <meta name="generator"> tag;
• versioned script and stylesheet URLs the page references (the URL string is read; third-party assets are never fetched);
• the greeting services such as SSH, FTP, SMTP, POP3, IMAP, MySQL and VNC send on connect (we send nothing);
• up to 6 ordinary GET / requests to open admin web ports.

2. Matching to CVEs

Products are matched using the affected-version ranges, CVSS scores and CWE identifiers in the NVD CVE API 2.0, plus the retire.js vulnerability repository for JavaScript libraries. A match produces one finding per CVE per host, vulns.cve-<id> (lowercase, for example vulns.cve-2023-44487). Library advisories that have no CVE number use their GitHub advisory ID instead: vulns.advisory-<ghsa id>.

All vulnerability data is downloaded nightly into our own store. Scans match against that copy and never query these services live. If the data is not available yet (for example on a brand-new deployment), the module reports that CVE matching was skipped rather than reporting the host as clean.

3. Prioritising by exploitation

Base severity comes from the CVSS score:

Severity is then raised one step (to a maximum of critical) when either:

• the CVE is in the CISA Known Exploited Vulnerabilities (KEV) catalog, meaning exploitation in the wild has been observed, or
• its EPSS score (FIRST's probability of exploitation in the next 30 days) is 0.5 or higher.

Every vulnerability finding carries tags you can filter and export on: CISA-KEV, EPSS:<score>, CWE-<n> and, where relevant, potential. KEV and EPSS are refreshed nightly, so a CVE that joins KEV tonight surfaces on the next scan of any host already running the affected version. The resulting vuln.new change is critical whenever any new CVE is on KEV, so it is sent to your alert channels immediately.

At most 25 CVE findings are raised per product, highest risk first (exploited, then severity, then EPSS); the rest are counted in the evidence so nothing is silently dropped.

Potential matches

When a product is detected without a version (a Server header with the version hidden, for example), a CVE cannot be confirmed. Potential findings are deliberately narrow: they are raised only for internet-edge products where exploitation is common (GitLab, Confluence, FortiOS, NetScaler, Ivanti, GlobalProtect and Exchange), only for CVEs on the KEV catalog, at most 10 per product, and capped at medium. Each is tagged potential and explains how to check the real version.

Distribution builds and backported fixes

Linux distributions often patch a CVE without changing the upstream version string. When the version looks like a distribution package (for example an Ubuntu build), the finding carries a backport warning. Severity is not lowered: confirm against the distribution's security tracker, then accept the risk with a review date and a note if the fix is already in place. For Exchange and ASP.NET, only presence is reported, because their public version strings do not identify the patch level.

End-of-life software

When a detected version belongs to a release line past its vendor end-of-life date, the host gets vulns.eol-<product> medium. EOL software may have no CVE today; it will not get fixes for the next one. EOL dates come from the endoflife.date project and are refreshed nightly.

Limits