As the number of vulnerabilities in the software ecosystem increases, we’re often asked to triage and address new CVEs in software that we’re building and running. However, there’s a great deal of jargon and hidden assumptions built into the CVE system, making it difficult for practitioners to respond effectively.
Let’s see if we can demystify CVEs and ensure you’re better prepared to evaluate and respond to them.
Wait, what is a CVE?
CVE stands for “Common Vulnerabilities & Exposures”; in other words, it’s a record that identifies a specific software vulnerability and provides intelligence, both human and machine readable, about the issue. CVE identifiers are in the format of CVE-2026-33870. The initial “CVE” just tells us that this is a CVE record.
The year identifies the year in which the CVE was discovered. Confusingly, this may be different from the year in which it was published; for example, CVE-2022-4980 was actually published in 2025.
The final set of numbers is the unique identifier, within the year, for that CVE record.
Some more TLAs
There are lots of three letter acronyms, or TLAs, as well as some longer ones that come up when we read a CVE. Many of these will be critical to our analysis of a particular vulnerability so we should define them, first, before putting them to use.
Attributes of a CVE
CVEs go through a process of enrichment, which adds analysis of the vulnerability to the record. This enrichment provides us with important information about the potential severity, applicability, and root cause(s) of the vulnerability. Enrichment may come from the CNA (CVE Numbering Authority) who filed the CVE, from CISA-ADP (a program run by the US Cybersecurity and Infrastructure Security Agency), and from NVD (the National Vulnerability Database).
CVSS
CVSS, or Common Vulnerability Scoring System, is a measure of how severe a vulnerability could potentially be. CVSS scores run from 0 to 10 and are broken up severity levels:
It’s important to account for the word ‘potentially’ in the description of CVSS scores. A critical CVE may only be critical in particular configuration – the score measures the worst possible case.
CVSS has gone through multiple iterations. You may find CVEs with CVSS v4, 3.1, and v2 scores. Typically, the higher version is preferable although v4, released in 2023, is not yet used extensively.
CPE
CPEs, or Common Platform Enumerations, are machine-readable strings that tell us what software a particular CVE applies to. At first glance, CPEs appear difficult to interpret but, with a bit of practice, we can quickly decipher them. For example,
CPEs are one way that vulnerability scanners match the software you’re running with the CVEs that affect it.
CWEs
A CWE, or Common Weakness Enumeration, is a link to a root cause of the vulnerability. These are higher level concepts that categorize the problems that resulted in a particular CVE.
A simple example is CWE-319, “Cleartext Transmission of Sensitive Information”. This CWE tells us that the software failed to encrypt sensitive data when it was communicated, enabling an attacker to intercept communications to gain access to the data. A particular CVE may need multiple CWEs to explain fully.
CWEs tend to be more useful for threat modeling and software development than they are for vulnerability management. It’s often said that developers tend to make the same mistake more than once and the presence of CWEs in your codebase is a reminder to look for the same categories of vulnerabilities more broadly.
Putting it together
Now that we understand the components, let’s look at a particular CVE. We mentioned CVE-2026-33870 earlier and we’ll use it as an example now.
The description
CVEs start with a freetext description of the problem and, as a human, we can learn a great deal from the description. For CVE-2026-33870:
Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Versions 4.1.132.Final and 4.2.10.Final fix the issue.
That’s pretty dense prose but it tells us several important things, especially that the impact is HTTP request smuggling. Like me, you might have to look up HTTP request smuggling, but this gives us some knowledge about the potential impact of the vulnerability and, if this is our own code/application, potentially enough info to tell us if we’re potentially impacted.
Severity
The CNA, GitHub, rated this as a CVSS 7.5 or high severity.
The vector tells us exactly how GitHub came up with that score.
Many organizations base response primarily on the severity, using different SLAs/KPIs for critical and high severity CVEs than for other ones, so knowing that this is high severity may, immediately, push us towards responding. While the vector can be complex to interpret, it may sometimes inform our response further – for example, if this application functioned entirely locally, “Attack Vector: Network” would make this far less interesting to us. Unfortunately, since we’re using netty, that seems unlikely to be the case.
Applicability
Here are the CPEs from CVE-2026-33870:
This particular CVE affects a Java web server known as netty. The CPEs here show us two things:
- Every version of netty before 4.1.32 is affected.
- Releases of netty in the 4.2 branch are affected before 4.2.10.
In other words, when developers fixed this particular vulnerability, they fixed it in the 4.1 branch and the 4.2 branch. You can update to 4.1.132 or 4.2.10 (or later) to patch it and, if you’re already running a later version, you’re not impacted by this CVE.
Root cause
The CWE for this CVE won’t surprise us since we’ve already read the description:
The Mitre writeup for CWE-444 gives us a full description and examples of how this particular weakness might work.
Additional intel
There are a few other things that may be of interest in the NVD CVE page. First, the references section provides links to the original bug, code changes, and additional discussion. This may come in handy if you need to answer deeper questions about what was vulnerable or how it was fixed.
The change log can also be invaluable for analysts. In this case, there’s nothing we would be worried about, but we can see that, while the CNA, GitHub, supplied the CVSS score and the CWE, the report was enriched by NVD later to add the CPEs. In other cases, we may see significant changes in the CVE metadata over time; for example, the CVSS score may have been recalculated and changed significantly.
Conclusion
Understanding a CVE is only the first step, the real challenge is keeping up with the volume and acting fast enough to reduce risk. Minimus solves this by eliminating most vulnerabilities before they reach your environment, using minimal, hardened images that reduce what you need to triage and remediate in the first place. With fewer CVEs and faster patching, teams can focus on what actually matters. Get a demo to see how Minimus simplifies vulnerability management from the start.
