What Happens When a CVE Becomes a KEV?

Every week, I help put together Blumira Briefings, a short security news program aimed at IT departments and MSPs from Blumira.

A lot less time is spent on assembling an edition vs. figuring out whether what I’m looking at actually means what I think it means. I’m checking original sources, looking at vendors advisories, digging into CVE records, confirming if exploitation has been observed, and generally trying to answer a simple question: does this matter?

This week, one of the stories I researched sent me down a small rabbit hole involving a CVE identifier, the CVE record itself, and CISA’s Known Exploited Vulnerabilities catalog.

The more I looked, the more I realized that I often think about several different pieces of vulnerability information as though they were interchangeable while they’re not - and that raised a question worth answering: what actually happens when a CVE becomes a KEV That’s when I realized I was treating several different sources as though they were answering the same question.

A CVE is where the investigation starts

A CVE, or Common Vulnerabilities and Exposures identifier, provides us with a standardized way to refer to a specific publicly known vulnerability, and that’s very useful. If I’m researching a vulnerability, and I see something like CVE-2026-XXXXX, I now have a unique identifier I can use to find information across different sources.

While valuable, the CVE number itself doesn’t tell me whether the vulnerability is being exploited, whether it’s present in any of my client’s environments, or if there’s a patch available. Most importantly, it doesn’t tell me what I should do about it. The CVE number is an identifier, and by itself, that’s all it tells me.

Remembering that it’s an identifier is important because it’s very easy to see a CVE number attached to a headline and immediately jump straight to “oh shit, who got what exfiltrated today?” Sometimes that reaction’s appropriate; most of the time it isn’t. A CVE is just the beginning of the investigation - it’s the “dun-dun” and not Dick Wolf’s Executive Producer credit.

Then there’s CVSS

The next piece of the puzzle is CVSS: the Common Vulnerability Scoring System. CVSS gives us a standardized way to describe the technical severity of a vulnerability. It considers things such as attack vector, complexity, privileges required, user interaction, and the potential impact on confidentiality, integrity, and availability.

A vulnerability with a CVSS score of 9.8 looks pretty scary - and it may be, but there’s a problem with treating that number as the answer. CVSS describes the vulnerability, but it doesn’t tell us what’s happening in the real world. A critical vulnerability that nobody has exploited and a moderately scored vulnerability that attackers are actively using are very different problems for a team. The score is useful, it just isn’t the entire risk calculation - and that’s where things get interesting.

Enter the KEV catalog

CISA’s Known Exploited Vulnerabilities catalog is different because its inclusion criteria are about observed exploitation. A CVE tells me a vulnerability exists and CVSS helps me understand it’s technical severity. A KEV entry tells me that there is evidence that the vulnerability is being exploited in the wild.

When a vulnerability gets added to KEV, the vulnerability itself hasn’t suddenly changed. The software hasn’t magically become more vulnerable because CISA added it to a list - our understanding of the risk has changed.

There is now evidence that someone is using the vulnerability as part of an attack (keep in mind this doesn’t mean it’s widespread), and that should change the questions we’re asking. Before exploitation is known, I might be asking:

How severe is this vulnerability?

Once it’s in KEV, I should be asking:

Do any of my clients have this vulnerability, and what am I doing about it?

Those are two very different questions.

Where vulnerability management gets practical

For an MSP, a KEV addition isn’t just another piece of security news - it’s a reason to revisit environments. If a vulnerability affecting a product you manage is added to KEV, the next thoughts are straightforward:

• Which clients have it?
• Which versions are installed?
• Are the affected systems exposed?
• Is a patch available?
• If a patch isn’t available, is there a mitigation?
• Has the remediation actually been completed?
• Can we verify that?

The same goes for an IT department. You are an organization and the users are your clients; you just can’t fire them. The KEV entry doesn’t perform any of those actions for you. IT doesn’t patch the server, change a firewall rule, update an application, or tell you whether one of your clients is affected. It’s a call to action, and the value comes from what you do with it.

Timing matters

Timing is one of the things that caught my attention while researching the story for Blumira Briefings. A vulnerability can exist as a CVE for some period of time before it appears in KEV (and the opposite can happen, too, which is what led me down the rabbit hole.) That’s important because a vulnerability doesn’t have to be new to become newly important. If a vulnerability management process is focused primarily on newly disclosed CVE’s, you’re not protecting ya neck; something that was already in the vulnerability database last week may suddenly deserve a much higher priority today.

That’s why I think there’s value in treating KEV additions as their own category of security intelligence. A newly published CVE answers, “what’s new?” while a new KEV entry answers “what’s newly known to be exploited?” and those are two completely different things.

Authoritative sources don’t always agree immediately

There’s another lesson here that I think is often overlooked; we tend to imagine authoritative security sources as synchronized databases - perfect starts of authority for information we rely on. They aren’t. A vendor may publish an advisory and a CVE record may be created or updated. A vulnerability database may ingest that information, and somewhere down the line CISA may add the vulnerability to KEV.

Those things can happen at different times, and information can also change as more becomes known. That means finding conflicting or incomplete information doesn’t necessarily mean someone is incompetent or that one of the sources is fraudulent. Sometimes, you’re looking at different points in the lifecycle of the same vulnerability. That doesn’t make the discrepancies unimportant - quite the opposite.

If I’m preparing a security briefing for an SMB IT/MSP audience, those discrepancies are exactly what I need to slow down and verify what we’re reporting. I don’t want to tell someone that a vulnerability is being actively exploited simply because I found a scary CVSS score. I also don’t want to tell them something is low priority simply because the CVE was published several weeks ago. Context matters.

The Gitea Example

The specific example that started this rabbit hole was a Gitea vulnerability. The vulnerability was already listed in CISA’s KEV catalog, but when I followed the CVE identifier back to CVE.org, the record was still marked RESERVED.

That seemed weird. How can something be a Known Exploited Vulnerability if the CVE record itself isn’t even populated?

The important thing I learned is that these aren’t synchronized views of one master database. The CVE system and CISA’s KEV catalog have different purposes and different workflows. A CVE identifier can be reserved before the full record is published, while other organizations can already have enough information about the vulnerability - and its exploitation - to act on it.

In other words, “RESERVED” doesn’t mean “this vulnerability isn’t real yet,” it means the CVE record isn’t finished yet. The distinction is important, particularly when we’re using these sources to prepare security information for other people. I initially treated the CVE record’s status as though it represented the status of the vulnerability itself. It doesn’t, and that’s probably the larger lesson: authoritative doesn’t mean instantaneous, synchronized, or infallible.

What actually happens when a CVE becomes a KEV?

Nothing magical happens to the CVE.

The identifier remains the identifier and the vulnerability remains the vulnerability. What changes is that we now have an additional, and very important, pieces of information about it - known exploitation.

Confirmation of exploitation changes its place in the queue and for an IT department or MSP, that’s the point. You probably have more vulnerabilities in your environments than you can remediate simultaneously; something that we call reality. Vulnerability management isn’t simply about finding every vulnerability, determining which deserve attention first is just as important.

CVE information helps identify what you’re dealing with, CVSS helps describe its technical severity, and vendor advisories tell you what the vendor recommends. Your RMM, vulnerability scanner, or other management tools can help determine whether you actually have affected systems, and KEV provides the red flag that exploitation is no longer theoretical. Put all of it together, and you have a much better basis for deciding what to do next.

This is changing how I think about security briefings

One of the things I enjoy about working on Blumira Briefings is that the process forces me to look past the headline. The goal isn’t to simply find a few interesting security stories, sitting in front of my RSS reader can accomplish that, fast. The goal is to figure out which stories are useful, and then explain why. Sometimes it means following a story back to the original advisory, researching CVE records, or discovering that two authoritative sources don’t quite agree yet. Increasingly, it means asking a completely different question than the one that started the research, and that’s what happened here.

I started with a CVE and ended with me thinking more carefully about what it means when that same vulnerability eventually appears in KEV - it’s also why we’re making KEV additions a more visible part of future Blumira Briefings. A vulnerability doesn’t have to be newly discovered to be worth talking about. Sometimes, the important development is that our understanding of the threat has changed - and for many, that’s the most important update of all. The CVE tells you what you’re looking at; the KEV entry may tell you why you should be looking at it right now.