How to Read a CVE and Decide in Ten Minutes If It Touches You

A vendor mailing list, a news headline or a scanner puts a number in front of you and somebody asks whether it is urgent. Ten minutes of reading gets you to an answer you can write down and defend, and most of that time goes on the two questions the severity score cannot answer.

What the score is, and what it is not

CVSS version 4.0 "is composed of four metric groups: Base, Threat, Environmental, and Supplemental". Base covers "intrinsic qualities of a vulnerability that are constant over time and across user environments", while Environmental covers "characteristics of a vulnerability that are unique to a user's environment". The headline number knows nothing about you by construction, because the group that would carry that information is the one nobody filled in.

The specification names the shapes so they can be told apart. CVSS-B is Base alone, CVSS-BT adds Threat, CVSS-BE adds Environmental, and CVSS-BTE has all three. Nearly every number quoted in an article is CVSS-B, and there is a trap inside that worth knowing. The Exploit Maturity metric has a "Not Defined (X)" value which is "equivalent to Attacked (A) for the purposes of calculation", so an unmodified base score has already assumed the worst about exploitation before anyone checked. The version 3.1 specification asks consumers to do the other half of the work, that they "should supplement the Base Score with Temporal and Environmental Scores specific to their use of the vulnerable product".

The qualitative bands are fixed: 9.0 to 10.0 Critical, 7.0 to 8.9 High, 4.0 to 6.9 Medium, 0.1 to 3.9 Low.

Read the advisory that names the code path

A CVE record is created by a CVE Numbering Authority, an organisation "authorized to assign and populate CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope", and the National Vulnerability Database then enriches published records with impact metrics, weakness types and applicability statements. Neither tells you whether your deployment reaches the vulnerable code. The vendor's own advisory usually does.

The OpenSSL advisory of 15 March 2022 for CVE-2022-0778 is titled "Infinite loop in BN_mod_sqrt() reachable when parsing certificates". It explains that the function "is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form", then lists the vulnerable situations, among them TLS servers consuming client certificates and hosting providers taking certificates or private keys from customers. If you terminate TLS and never accept a client certificate, your exposure is not a certificate authority's, and that distinction comes from the advisory rather than from any score.

The OpenSSH 9.8 release notes of 1 July 2024 describe CVE-2024-6387 as a critical vulnerability "present in Portable OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary code execution with root privileges". The same notes add that successful exploitation "has been demonstrated on 32-bit Linux/glibc systems with ASLR", that under lab conditions "the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept", and that "OpenBSD is not vulnerable". A version range plus a requirement for hours of sustained connections is a different operational picture from the headline, and it changes what you do first.

Your version string may be lying to you

A scanner comparing an installed version to the upstream fixed version will report a patched machine as vulnerable, and on Debian and Ubuntu that is normal rather than a bug. The Debian security FAQ states the policy directly, "instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release". The version number stays where it was and the fix is inside it, so the package changelog or the distribution's security tracker settles the question.

Vendor severity ratings differ from the headline for a related reason. Red Hat notes that "the CVSS base scores may vary for each vendor's version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled", and rates lower when its own build or default configuration blunts the attack. A lower vendor rating is the Environmental group filled in by people who know how the package was built.

Is anyone actually using it

Two public sources answer this, and they answer different questions. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities meeting three thresholds, an assigned CVE ID, "reliable evidence that the vulnerability has been actively exploited in the wild", and "a clear remediation action". What does not count is the part worth knowing. Scanning does not, security research does not, and CISA states plainly that "having a publicly available PoC is not a requirement for a vulnerability to be included in the KEV catalog". Absence from the catalog is not evidence of safety, while presence is strong evidence of urgency. Federal civilian agencies must remediate listed vulnerabilities within set timeframes under Binding Operational Directive 26-04, issued on 10 June 2026, and CISA "strongly recommends all organizations review and monitor the KEV catalog".

EPSS answers the forward-looking question. It "estimates the probability a vulnerability will be exploited in the wild within the next 30 days", as a score between 0 and 1 for every published CVE, refreshed daily. Its own documentation is careful about the limits, noting that it "does not measure how much damage successful exploitation would cause, or whether it affects your environment". The percentile is relative, so "a vulnerability at the 90th percentile has a higher EPSS score than 90% of all scored vulnerabilities".

The ten minutes, in order

1. Do we run it, and at which version. If the asset inventory cannot answer inside a minute, that is the finding, not the CVE.
2. Read the vendor advisory and find the sentence that names the reachable path. Decide whether your deployment takes it.
3. Check the KEV catalog and the EPSS score for what the rest of the world is seeing.
4. Check your distribution's tracker for the fixed package version, so you patch the build you actually run.
5. Write the decision down with today's date, and a review date if you are deferring.

The output is one sentence a colleague can check. We run the affected version on the API gateway, we never accept client certificates so the path in the advisory is not one we take, it is not in the KEV catalog, the fix is already in the distribution, and it goes out with Thursday's patch wave.

Not every case needs the ten minutes. If it is in the KEV catalog and you run the affected version, patch first and read afterwards.

Triage like this works when it runs every week rather than after a headline, which is part of our security and compliance work, and the patch pipeline that carries the fix is part of infrastructure management.