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:
- Anything KEV-flagged. Patch this week. Attackers are actively using it.
- CVSS 7+ AND EPSS 0.1+. Serious flaws with measurable exploit activity. Patch this month.
- CVSS 7+ but low EPSS. Serious in theory, no evidence of active exploitation. Patch in the next regular maintenance round.
- 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:
- Vulnerabilities in web servers (Apache, nginx, IIS, Caddy)
- Vulnerabilities in OpenSSH
- Vulnerabilities in mail servers (Postfix, Exim, Dovecot)
- Vulnerabilities in databases (MySQL, PostgreSQL, MongoDB, Redis)
- Vulnerabilities in FTP servers
By bug type:
- Remote Code Execution (RCE)
- SQL injection
- Cross-site scripting (XSS)
- Server-side request forgery (SSRF)
- Path traversal
- Insecure deserialization
- Authentication bypass
Further reading
- MITRE CVE program, the public CVE registry.
- FIRST CVSS specification, the formal scoring system.
- FIRST EPSS model
- CISA Known Exploited Vulnerabilities Catalog
- BSI IT-Grundschutz on patch management