How to Read a CVE Report: A Beginner's Guide to CVSS, CWE, and Exploitability Scores

A CVE entry looks like it was written for machines. A cryptic ID, a vector string full of slashes, a decimal number with one digit after the point. The good news is that most of that scaffolding isn't for you. Four or five fields carry the real decision weight, and once you know which ones they are, you can read a vulnerability record in two minutes and know whether it should ruin your afternoon.

What's Actually in a CVE Record

A CVE is an identifier, not a verdict. The CVE Program, coordinated by MITRE and funded by CISA, hands out IDs through numbering authorities — vendors, research outfits, coordinators — so that everyone can refer to the same bug without arguing about nicknames. The sequence number means nothing. CVE-2024-40000 is not worse than CVE-2024-00001.

• CVE ID — a shared name. Year plus sequence. No ranking implied.
• Description — prose describing what breaks. Read it twice; the trigger conditions are usually buried in there.
• References — vendor advisory, patch notes, sometimes a researcher write-up.
• Affected products and versions — often as version ranges or CPE strings. This is where most triage goes wrong.
• Weakness (CWE) — the class of bug, such as cross-site scripting or an out-of-bounds write.
• Scores — CVSS, usually a base score, sometimes with a vector string.
• Exploit context — where available: KEV listing, EPSS probability, public proof-of-concept.

One caveat worth internalising early: the National Vulnerability Database enriches these records with its own scores and mappings, and that enrichment lags. If a record says "awaiting analysis" and shows no score, that is a backlog, not a signal that the bug is harmless. Go to the vendor advisory instead.

CVSS: Read the Vector, Not Just the Number

CVSS scores run from 0.0 to 10.0 and land in bands: None, Low, Medium, High, Critical. The base score describes the intrinsic characteristics of a vulnerability assuming a worst-case deployment, which is exactly why it can mislead you. A 9.8 in software you don't run is trivia. A 6.5 in the authentication service on your public edge is a fire.

The vector string is where the reasoning lives. Take a familiar one:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Decoding it

• AV:N — attackable over the network.
• AC:L — no special conditions to line up; repeatable.
• PR:N — no account or privileges required.
• UI:N — no victim has to click anything.
• S:U — impact stays within the vulnerable component's security scope.
• C:H/I:H/A:H — full loss of confidentiality, integrity, and availability.

That combination is the classic unauthenticated remote code execution profile, and it scores 9.8. Now change a few letters: AV:L instead of AV:N, PR:L instead of PR:N, UI:R instead of UI:N. Same product, same CVE, but the attack now needs local access, a valid low-privilege account, and a user who does something unwise. The number drops sharply, and so does your urgency — unless you happen to run multi-tenant systems where local access is cheap.

CVSS v4.0 adds metrics such as Attack Requirements and splits out Threat and Supplemental groups. The severity bands look familiar, but the underlying math changed. Don't compare a v3.1 score to a v4.0 score as if they came off the same ruler.

CWE Tells You What Kind of Bug It Is

Common Weakness Enumeration entries are taxonomy labels. CWE-79 is cross-site scripting, CWE-89 is SQL injection, CWE-787 is an out-of-bounds write, CWE-416 is use-after-free, CWE-22 is path traversal, CWE-287 is improper authentication, CWE-502 is unsafe deserialisation.

CWE isn't a severity. It's a shortcut to pattern recognition. Memory corruption classes such as CWE-787 and CWE-416 often mean a path to code execution, so they get attention even at medium scores. Injection and traversal bugs frequently mean data exposure — bad, but not always an instant emergency. And when a vendor ships the same CWE in the same product two quarters apart, that tells you something about their development process that no score will.

Exploitability: The Part CVSS Doesn't Cover

A base score cannot know whether anyone is actually attacking the thing. That's what the exploit signals are for.

EPSS estimates the probability that a given CVE will be exploited in the wild within the next 30 days, expressed from 0 to 1. A high probability next to a medium score deserves more attention than a low probability next to a high one.

CISA's Known Exploited Vulnerabilities catalog is a harder signal: these are bugs with evidence of real-world exploitation. The remediation deadlines attached to it apply to US federal agencies, but the list itself is useful to anyone.

Public proof-of-concept code is the third signal. A working exploit in a public repository collapses the time between disclosure and widespread scanning.

Severity tells you how bad it could be. Exploitability tells you how likely it is to happen to you. Patching decisions need both, plus one more thing: whether the affected component is actually yours.

A Five-Minute Triage Routine

1. Confirm you run it. Check the version, build number, and container image tag. Vendors backport fixes, so a version that looks old in a table may already be patched.
2. Check the exposure. Internet-facing, partner-facing, or internal? Compare that against the vector's AV value. A network vector on an isolated lab box is not the same problem as a network vector on your VPN concentrator.
3. Check the prerequisites. Look at PR and UI. If the attack needs a valid account or a user click, the practical risk changes — sometimes dramatically.
4. Check the exploitation signals. KEV, EPSS, the vendor's own wording about exploitation, and whether a proof-of-concept is circulating.
5. Decide and record it. Patch inside your normal window, apply a compensating control such as a configuration change or a WAF rule, or accept the risk — with a name, a date, and a reason attached.
6. Re-read the record later. Scores, CWE mappings, and exploit status all change after publication. A record you dismissed in week one may look very different in week three.

Two rules of thumb will carry most of the weight. Anything in the KEV catalog, or anything unauthenticated and network-reachable on an exposed system, goes to the front of the queue regardless of whether the score is 7.1 or 9.8. Everything else competes on exposure, exploit signals, and effort — and a 9.8 in a package nobody deploys can wait behind a 5.5 in your single sign-on gateway.

Write down your reasoning, even in one line: affected hosts, exposure, signal, decision, review date. Six months from now, that note is the difference between a deliberate risk decision and a gap you can't explain.

Photo: Syirwan Ainu / Pexels