Known vulnerabilities on your website

1 Introduction

Many web servers announce what they run. A response header such as Server: nginx/1.9.0 or X-Powered-By: PHP/7.2.24 tells every visitor the product and its exact version. Attackers read it too, and they have databases that list which versions are affected by which public flaw.

The "Known vulnerabilities" block of a domain scan does the same lookup on your behalf: it takes each product and version your site discloses and lists the published vulnerabilities (CVEs) that version cannot be ruled out of. This page explains how to read that list, which entries deserve action today, and why some of them may not apply to you at all.

KEV

CISA's catalogue of vulnerabilities confirmed as exploited in the wild, published since 2021

0 to 10

The CVSS severity scale. 9.0 and above is rated critical

30 days

The window an EPSS score covers: the estimated chance of exploitation attempts in the next 30 days

2 How It Works

The scan never attacks your site and never tries an exploit. It only compares a version string with public advisories, in three steps.

Detect

Read the product and version from the HTTP response. A header counts for more than a guess from the page markup, and the report says which source was used.

Look up

Fetch the CVEs recorded for that product, then drop those attributed to another product and those whose affected range excludes your version.

Enrich

Add the CVSS score, the EPSS probability and whether the CVE is on the CISA KEV list, so you can sort by real risk.

No version disclosed means no lookup

If the block says "No software version was disclosed in the response", the scan had nothing to match: an advisory says "versions 1.4 to 1.9 are affected", and a bare Server: nginx cannot be placed in that range. This is not a clean bill of health. It means the question could not be asked from outside, and the answer lives in your own patch records. The same goes for "Lookup: incomplete": the vulnerability database did not answer for every product, so treat the list as unfinished.

3 Detailed Analysis

How a version is matched to CVEs

A CVE (Common Vulnerabilities and Exposures) is a public identifier for one flaw, such as CVE-2016-0746. Its advisory names the affected product and usually a version range. Under each product, the report shows a line like this:

nginx 1.9.0  (from header; 23 not attributed to this product, 17 ruled out by version)

What was filtered out

"Not attributed to this product" are CVEs that mention the name but concern something else (a plugin, a distribution package, another vendor). "Ruled out by version" are real CVEs for the product that your version is outside of. Both counts are shown so a short list reads as filtered, not as "nothing exists".

in range versus undetermined

in range: the advisory gives a range and your version falls inside it. undetermined: the advisory has no range the scanner could read, so the CVE could not be ruled out either. Start with the in-range entries.

Candidates, not confirmed findings

Many CVEs only apply when a specific module or feature is enabled (an HTTP/2 option, a resolver, an MP4 module). The list says this version may be affected. Read each summary and check whether that part is in use on your server. Each identifier links to its full record on vuln.mlab.sh.

CVSS, EPSS and KEV: three different questions

CVSS: how bad would it be?

A score from 0 to 10 describing the flaw itself: reachable over the network or not, needs a login or not, impact on data and availability. It says nothing about whether anyone is actually using it. The "Highest CVSS" chip gives the worst score in the list.

EPSS: how likely is it to be used?

The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability of exploitation activity in the next 30 days, shown as a percentage. Most CVEs score very low. A high EPSS on an in-range CVE is a strong signal even when CVSS is only medium.

KEV: is it already being used?

The Known Exploited Vulnerabilities catalogue, maintained by the US agency CISA, lists CVEs with evidence of real attacks. It is not a prediction: someone is exploiting it now. A KEV tag, or the red "Known exploited" chip at the top, outranks any score.

KEV entries come first

US federal agencies must patch KEV entries within a fixed deadline, and that rule is a good model for everyone. Exploitation tools for these CVEs already exist, and internet-wide scans look for them continuously. An exposed server running an affected version is likely to be found.

Patch, then check for compromise

If a KEV entry is in range and the vulnerable feature is in use, update first. Then look at the server's logs and accounts for signs of a past intrusion: updating closes the door, but does not remove someone who already came in.

Cannot update today?

Disable the affected module, restrict access to the service (VPN, IP allow-list), or apply the vendor's documented workaround until the update is done.

How to prioritise the list

KEV and in range: act today.

High EPSS, or CVSS 9.0 and above, reachable without login: plan the update this week.

Everything else in range: fold it into the next regular update. One upgrade to a supported version usually clears dozens of entries at once.

Undetermined: read the summary, check whether it concerns a feature you use, and move on if not.

A version old enough to collect many CVEs is often out of vendor support altogether. In that case the real fix is the upgrade, not a CVE-by-CVE review.

False positives: backported patches

Linux distributions such as Debian, Ubuntu and Red Hat Enterprise Linux keep the same upstream version number for the life of a release and apply security fixes on top (they "backport" them). A server can say Apache/2.4.6 and still be fully patched, because the vendor package carries the fixes. The scan only sees the number, so it lists CVEs that may already be closed. Check your installed package:

# Debian / Ubuntu: is the CVE mentioned in the package changelog?
apt changelog nginx | grep CVE-2016-0746

# Red Hat / Rocky / Alma
rpm -q --changelog httpd | grep CVE-

Your distribution's security tracker also says, per CVE, which package version fixed it. If it is fixed, note it and move on.

Stop announcing your version

Once you are patched, there is no reason to publish your exact version:

# nginx
server_tokens off;

# Apache
ServerTokens Prod
ServerSignature Off

# PHP (php.ini): removes X-Powered-By
expose_php = Off

This removes an easy targeting signal, and it is good practice (see HTTP security headers). It fixes nothing: a vulnerable server with a hidden version is still vulnerable, and the next scan simply has nothing to look up. Update first, hide second.

Check your domain on mlab.sh

A domain scan reads the software versions your site discloses, matches them against public advisories, and tags each CVE with its CVSS, EPSS and KEV status.

Scan your domain on mlab.sh

4 Red Flags

A KEV entry marked in range

Someone is exploiting this flaw right now, and your version is affected. Confirm the feature is in use, then patch or mitigate today.

A version years behind the current release

Dozens of in-range CVEs usually mean the product is no longer updated at all. Plan an upgrade to a supported branch.

"Lookup: incomplete" read as all clear

The vulnerability database did not answer for every product. Re-scan later before drawing any conclusion.

Hiding the version instead of updating

The scan goes quiet, the flaw stays. Attackers often try exploits without checking the version first.

Dismissing every CVE as "backported" without checking

Backports explain many false positives, not all of them. Check the changelog or the distribution tracker for each in-range entry that matters.

Related Modules

TLS configuration explained

Protocol versions, cipher suites and certificate validity: what a TLS scan result means and how to fix a weak configuration.

Your attack surface: subdomains

What subdomain enumeration reveals to an attacker, and how to shrink the surface: forgotten hosts, staging, admin panels.

HTTP security headers explained

HSTS, CSP, X-Frame-Options, cookie flags: what each header blocks, what a missing one means in a scan, and a safe configuration to start from.