Reading a CVE

Advisories look like alphabet soup: a CVE number, a CWE number, a CVSS score, sometimes a KEV flag. Each answers a different question, and once you know the five questions you can read any record in two minutes and decide whether to drop everything. We will do that on one real record, CVE-2023-32315.

The five questions

We take them in turn.

Who and what: vendor, product, title

First, orient yourself. The record names the vendor (Ignite Realtime), the product (Openfire) and a title: "Ignite Realtime Openfire Path Traversal Vulnerability". The description explains Openfire is an XMPP server, which is chat server software. Its administrative console is a web application for managing it.

Always read the vendor and product first, because the question that matters most is "do we run this?" If not, you are done.

The CVE identifier

A CVE ID has the form CVE-year-number. It is a name, nothing more: a shared label so that a vendor, a scanner and a news article all mean the same flaw. It does not tell you severity. The number inside is an assignment counter, so a bigger number is not a worse bug.

The description: affected and fixed

The description tells you what happened in prose. Read for three things:

1. What goes wrong. Here, the admin console had a path traversal flaw reachable through the setup environment, letting an unauthenticated user reach restricted admin pages.
2. Which versions are affected. "All versions of Openfire that have been released since April 2015, starting with version 3.10.0."
3. What the fix is. Patched in releases 4.7.5 and 4.6.8, and the record points to a GitHub advisory for mitigations if you cannot upgrade immediately.

Notice what that shows: a flaw that affected every release for roughly eight years. A bug is not "new" just because its CVE is.

CWE: the type of weakness

CWE (Common Weakness Enumeration) is a catalogue of kinds of mistakes. CWE-22 is path traversal: a program builds a file or page location from input and fails to stop that input from stepping outside the area it was meant to stay in. (See path traversal.) Think of it as the genre, while the CVE is the specific book. CWE helps you spot patterns, for example that your team keeps making the same input-handling mistake. Many records carry no CWE yet, or carry a vaguer one.

CVSS: severity as a vector

CVSS gives a score from 0 to 10, grouped into labels: 0.1 to 3.9 low, 4.0 to 6.9 medium, 7.0 to 8.9 high, 9.0 to 10 critical. Our record scores 7.5, High. The score is computed from a vector that you should learn to read:

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

So the vector says: remotely, easily, with no login and no victim action, an attacker gets high-impact access to confidential information. It is the first lesson of this level written as a code: the C, I and A at the end are the triad.

One honest caution. The vector scores only a confidentiality impact, while the description says an unauthenticated user can reach pages reserved for administrators. A score is a compressed summary and can understate what a flaw enables in practice. Read the description, not just the number.

KEV: is it actually being used?

Severity says how bad a flaw could be. KEV, the Known Exploited Vulnerabilities catalog run by the US agency CISA, says what has been seen in real attacks. Our record's KEV entry gives:

• Added: 2023-08-24, about three months after publication on 2023-05-26.
• Due date: 2023-09-14, three weeks later. This deadline binds US federal agencies, but many organisations use it as a benchmark.
• Ransomware use: recorded as false for this entry.
• Required action: apply mitigations per vendor instructions, or stop using the product if mitigations are unavailable.

A KEV listing is the strongest signal on the page. It moves a vulnerability from "could be used" to "has been used".

EPSS: how likely, soon

EPSS is a model's estimate, from 0 to 1, of the chance a vulnerability is exploited in the next 30 days, with a percentile saying how it ranks against all others. This record shows a score and percentile of 1, the top of the scale. Treat it as a ranking aid; it is a forecast, not a fact, and it works best next to KEV.

The dates

Three dates tell you the timeline: published (2023-05-26), KEV added (2023-08-24), and last updated (the record shows 2026-06-17). Updated does not mean new danger; records get edited long after the fact. The gap between the first two is the window in which a patch existed and attacks were underway. The record does not say when the first attack happened, so do not assume.

Putting it together

For a team that runs Openfire reachable from the internet, this record reads: remotely exploitable, no login needed, confirmed exploited, top-ranked likelihood, a fix exists. That is "patch or isolate today". A team that does not run Openfire reads it, shrugs and moves on. A team that runs it only on an internal network has more time, but the same record tells them what to schedule.

How AI changes this

Speed on both sides. Beam's AI-led attacks in October 2026 covers PHP2Shell, which that post reports was found with AI and attacked before a patch shipped. If that pattern holds, the gap between publication and exploitation shrinks, and fields like KEV and EPSS matter more than waiting for a monthly review.

Defenders can triage with AI. A model is good at reading a feed of hundreds of advisories and answering "which of these affect software we run, and which are in KEV?". It can draft the ticket. But it can get versions wrong or invent a fix, so confirm vendor, product and fixed version against the record itself.

Agents read advisories too, and text is untrusted. If you let a coding agent read vulnerability pages or issue trackers, remember that descriptions and comments are text from outside your trust boundary. An agent that follows instructions found in advisory text is a prompt injection victim. Use records as data to check, not as commands.

Your agent's own dependencies have CVEs too. Agent tools, MCP servers and plugins are software with versions. Beam covers checking dependencies against known CVEs in check dependencies for known CVEs in CI.

What stays the same: the five questions. A faster world needs the same reading skill.

Try it

This lab decodes a vector locally. It contacts nothing.

vector = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"
names = {
    "AV": {"N": "network", "A": "adjacent", "L": "local", "P": "physical"},
    "AC": {"L": "low complexity", "H": "high complexity"},
    "PR": {"N": "no privileges", "L": "low privileges", "H": "high privileges"},
    "UI": {"N": "no user action", "R": "user action required"},
    "S": {"U": "scope unchanged", "C": "scope changed"},
    "C": {"N": "no", "L": "low", "H": "high"},
    "I": {"N": "no", "L": "low", "H": "high"},
    "A": {"N": "no", "L": "low", "H": "high"},
}
for part in vector.split("/")[1:]:
    key, val = part.split(":")
    print(key, "->", names[key][val])

Save as decode.py, run python3 decode.py, then change the vector (for example PR:N to PR:H) and predict whether the score would go up or down before reading it. Then open the public NVD page for any CVE you choose and fill in a five-line summary: vendor and product, CWE, CVSS vector in words, KEV yes or no, EPSS.

Check yourself

Next

You can now read a record. Next we separate three words people use as if they were one: vulnerability, exploit and incident.