blueredix logo
info cve-explained

How to read a CVE: severity, exploitation, what to fix first

Every security finding in your scan report comes with a severity score and sometimes a "known-exploited" flag. Here is how to read those scores and decide what to fix first when several show up at once.

What a CVE is

A CVE (Common Vulnerabilities and Exposures) is a unique identifier for a publicly known security weakness in a piece of software. Whenever a security researcher or vendor finds a flaw in, say, an Apache web server or an OpenSSH installation, that flaw gets a CVE number. For example, CVE-2024-3094 was the xz-utils backdoor discovered in early 2024. Every database, scanner, and security advisory worldwide can then refer to the same problem unambiguously.

The blueredix scanner looks at the software versions running on your servers (your web server, mail server, SSH service, and so on) and asks public databases which CVEs apply to those versions. The findings in your report are the answers, filtered to drop noise and prioritised by real-world risk.

How CVEs are scored

Each CVE comes with a number from 0 to 10 called the CVSS score. It is calculated from factors such as:

  • Where the attacker has to be: on the internet, on the local network, or sitting in front of the machine.
  • How reliably the attack works: every time, or only under unusual conditions.
  • Whether the attacker needs an account or any user interaction.
  • What the attacker can do if it works: read data, change data, take the system offline, take it over.

The score translates into a severity label most reports use:

CVSS Severity Typical meaning
9.0–10.0 Critical Attacker can take over the system from the internet, no account
7.0–8.9 High Serious. Usually data theft or full system control
4.0–6.9 Medium Useful for an attacker, but with conditions
0.1–3.9 Low Minor. Usually requires local access or rare timing

CVSS is useful but limited. It tells you what could happen, not how likely an attack is right now.

Two more numbers worth knowing

Two extra signals help separate “theoretically serious” from “actively exploited right now”:

  • EPSS is a probability between 0 and 1, updated daily, that estimates how likely a CVE is to be actively exploited in the next 30 days. It is based on real-world signals: published exploit code, attacks observed at honeypots, mentions in underground forums. A 9.8-CVSS bug with an EPSS of 0.001 is a serious flaw nobody is attacking. A 6.5-CVSS bug with an EPSS of 0.7 is being exploited right now.
  • KEV (Known Exploited Vulnerabilities) is a US government list of CVEs that are confirmed in active attacker use. If a finding has the KEV flag, the existence of working attacks is no longer hypothetical. They are in the wild.

The blueredix report shows all three signals so you can prioritise sensibly.

How to triage a list of findings

When several CVEs appear in a single scan, this order works well in practice:

  1. Anything KEV-flagged. Patch this week. Attackers are actively using it.
  2. CVSS 7+ AND EPSS 0.1+. Serious flaws with measurable exploit activity. Patch this month.
  3. CVSS 7+ but low EPSS. Serious in theory, no evidence of active exploitation. Patch in the next regular maintenance round.
  4. CVSS below 7. Lower priority. Schedule them in a “patch everything” round when convenient.

This is a heuristic, not a rule. Context matters. A medium- severity flaw on a public admin panel is more dangerous than a critical-severity flaw on a service that only listens internally.

What to do about a finding in practice

The fix for almost every CVE is the same: update the affected software to a patched version. The detail is which version.

  • Operating-system packages (most software on a Linux server, installed via the system’s package manager). The OS vendor back-ports security fixes onto the same version number, so the upstream version on your machine may already be patched even if CVE databases still list it as vulnerable. The blueredix scanner recognises this for major distributions (Ubuntu, Debian, RHEL, SUSE) and points you at the vendor’s security tracker rather than raising every CVE.
  • Self-installed software. Read the vendor’s security advisory, identify the fixed version, upgrade.
  • Vendor appliances (firewalls, NAS, printers). Typically a firmware update from the vendor’s support portal.

When patching can’t happen immediately, vendor advisories often include mitigations (configuration changes, firewall rules, or feature toggles) that reduce exposure until the patch lands.

Where to read more

If you want to understand a specific CVE in your report better, the articles below are organised by the kind of service or kind of bug.

By service type:

By bug type:

Further reading