Skip to content

External vulnerability assessment

Advertised software versions matched against known-exploited and published vulnerabilities.

Last reviewed

Weight in the score

15%

One of six modules, scoring policy v2.1.0

Sources

  • Retire.js, NVD, CISA KEV, EPSS, OSV

Public web services often say which software and versions they run. That is enough to know whether they carry published vulnerabilities, without scanning or probing anything.

We match advertised versions of server software and JavaScript libraries against published vulnerabilities. Each one is then ranked by how likely it is to be exploited, not by its technical score alone: vulnerabilities known to be exploited in the wild come first, then those with a high predicted chance of exploitation.

This is passive and version-based, so it cannot see a fix that was backported without changing the version number. Matches on version alone are reported with lower confidence, and lower still on software known to backport fixes.

Findings this module can raise

Every finding in a report says what was tested, why it matters, the impact and how to fix it. These are the findings this module can raise, most serious first. Terms are explained in the glossary.

Criticalseverity 90 to 100

  • 95

    Known-Exploited vulnerability in a public component

    KEV lists vulnerabilities that have been OBSERVED being exploited in real attacks, not merely rated as severe. CISA sets binding remediation deadlines for federal agencies on exactly this list.

    How to fix it: Patch or upgrade the named component now: this is the highest-priority item in this report. If an immediate upgrade is impossible, put a virtual patch or WAF rule in front of it today and schedule the real fix. Check the CISA KEV entry for the required action and due date.

    What was tested and the impact
    What was tested
    Publicly fingerprinted components and JavaScript libraries, matched against the CISA Known Exploited Vulnerabilities catalogue
    Impact
    Working exploit code is public and in active use. Automated scanners find these within hours of a host appearing online, so the window between exposure and attempt is very short.

Highseverity 70 to 89

  • 85

    Vulnerability likely to be exploited

    EPSS estimates the probability that a vulnerability will be exploited within 30 days. It is a far better prioritisation signal than CVSS, which rates theoretical severity and ignores whether anyone is actually attacking it.

    How to fix it: Treat as urgent, just below a KEV listing. Upgrade the component; where you cannot, reduce exposure by restricting access to the affected path or feature. The default threshold is 0.5 and can be tuned with VULN_EPSS_THRESHOLD.

    What was tested and the impact
    What was tested
    Fingerprinted components, scored against EPSS (the FIRST.org exploit-prediction model)
    Impact
    A high EPSS score means attackers are showing real interest. These frequently become KEV entries within weeks.

Mediumseverity 40 to 69

  • 65

    Outdated component with known vulnerabilities

    The library version served publicly has published vulnerabilities. Nothing here is currently in KEV or scoring highly on EPSS, so exploitation is not yet widespread: but the fixes already exist and the version is visible to anyone.

    How to fix it: Upgrade the library to a version at or above the fixed release. If your distribution backports security fixes without changing the advertised version, confirm that and treat this as a false positive; otherwise plan the upgrade in your normal maintenance cycle.

    What was tested and the impact
    What was tested
    JavaScript library versions detected in page markup, matched against the Retire.js advisory dataset
    Impact
    Moderate today, and it can change quickly: a proof-of-concept release moves an issue from this category into the high-EPSS one in days. Version-only detection also cannot see a backported fix, so verify before treating it as certain.

  • 55

    JavaScript library with published advisories

    Many library security advisories are never assigned a CVE. The absence of one says something about the disclosure process, not about whether the issue is real or exploitable.

    How to fix it: Read the linked advisory for the component, then upgrade to a release that includes the fix. Where the library is loaded from a CDN, pin a current version rather than a floating one.

    What was tested and the impact
    What was tested
    JavaScript library versions matched against advisories that carry no CVE identifier
    Impact
    Depends on the specific advisory and how the library is used. These are commonly cross-site scripting or prototype-pollution issues in front-end code.

Lowseverity 0 to 39

  • 30

    Software versions disclosed in responses

    Exact version numbers are advertised in responses. This is not a vulnerability in itself, but it removes the reconnaissance step: an attacker can match your stack against a vulnerability database without probing the site again.

    How to fix it: Suppress version detail: ServerTokens Prod on Apache, server_tokens off on nginx, expose_php = Off for PHP, and remove the generator meta tag from your CMS theme. Treat this as hardening, not as an emergency.

    What was tested and the impact
    What was tested
    Server headers, X-Powered-By, and generator meta tags
    Impact
    Low on its own. It matters most when a new vulnerability is published for a component you run, because it lets attackers build a target list immediately.

The other modules

How the modules combine into the score⁠

Sources