What Is a CVE? Understanding Common Vulnerabilities and Exposures

When security researchers discover a vulnerability in software, it gets assigned a CVE identifier — a globally unique ID that anyone can reference. CVE-2021-44228 is Log4Shell. CVE-2022-22965 is Spring4Shell. CVE-2014-0160 is Heartbleed.

Understanding the CVE system helps you track vulnerabilities in your tech stack, communicate risk clearly, and prioritize remediation.

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It's a dictionary of publicly known security vulnerabilities, maintained by MITRE Corporation and funded by the US Department of Homeland Security.

Each CVE entry includes:

• CVE ID: A unique identifier (format: CVE-YYYY-NNNNN)
• Description: What the vulnerability is and what's affected
• References: Links to advisories, patches, and proof-of-concept code
• Status: Reserved, Published, Disputed, or Rejected

CVEs are assigned by CVE Numbering Authorities (CNAs) — vendors, researchers, and CERT organizations authorized to assign CVE IDs. Large vendors like Microsoft, Google, and Apple are their own CNAs.

CVE ID Format

CVE-YYYY-NNNNN

• YYYY: Year the CVE was assigned (not necessarily the year of discovery or exploitation)
• NNNNN: Sequence number (can be more than 4 digits for high-volume years)

Examples:

• CVE-2021-44228: Apache Log4j2 Remote Code Execution (Log4Shell)
• CVE-2022-22965: Spring Framework RCE (Spring4Shell)
• CVE-2023-44487: HTTP/2 Rapid Reset (affected most web servers)
• CVE-2024-3094: XZ Utils backdoor (supply chain attack)

The National Vulnerability Database (NVD)

The NVD (nvd.nist.gov), maintained by NIST, enriches CVE data with:

• CVSS scores (severity ratings)
• CWE classification (type of vulnerability)
• CPE (affected product list)
• References to patches, exploits, and advisories

The NVD is the authoritative source for CVE severity scores and is what most security tools query when checking for vulnerabilities.

CVSS: How Severity Is Scored

The Common Vulnerability Scoring System (CVSS) provides a numeric severity score from 0 to 10. CVSS v3.1 (current standard) uses a vector string that encodes multiple dimensions.

CVSS v3.1 Base Score Metrics

Exploitability:

Metric	Possible Values
Attack Vector (AV)	Network (N), Adjacent (A), Local (L), Physical (P)
Attack Complexity (AC)	Low (L), High (H)
Privileges Required (PR)	None (N), Low (L), High (H)
User Interaction (UI)	None (N), Required (R)

Impact:

Metric	Possible Values
Confidentiality (C)	None (N), Low (L), High (H)
Integrity (I)	None (N), Low (L), High (H)
Availability (A)	None (N), Low (L), High (H)

Scope (S): Unchanged (U), Changed (C) — does exploitation affect components beyond the vulnerable one?

Severity Levels

CVSS Score	Severity
9.0–10.0	Critical
7.0–8.9	High
4.0–6.9	Medium
0.1–3.9	Low
0	None

Reading a CVSS Vector

Log4Shell (CVE-2021-44228) has the vector:

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

• AV:N — Exploitable over the network
• AC:L — Low attack complexity (trivial to exploit)
• PR:N — No privileges required
• UI:N — No user interaction required
• S:C — Scope changed (affects other components)
• C:H/I:H/A:H — Complete confidentiality, integrity, and availability impact

Result: 10.0 / Critical

Zero-Day vs Known CVEs

Known CVE: A vulnerability that has been publicly documented. A patch may or may not exist. Your responsibility is to detect when components you use are affected and patch promptly.

Zero-day: A vulnerability that is being actively exploited before a CVE has been assigned or a patch released. These are the hardest to defend against because standard patch management doesn't help. Defense requires: defense-in-depth, behavioral detection, and WAF virtual patching.

N-day: A known CVE where a patch exists but hasn't been applied. The vast majority of breaches exploit n-days, not zero-days — unpatched known vulnerabilities are more common and easier to exploit.

Tracking CVEs for Your Tech Stack

GitHub Dependabot

Automatically opens pull requests when your dependencies have CVEs:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

OSV (Open Source Vulnerabilities)

Google's OSV database (osv.dev) covers CVEs for npm, PyPI, Go, Maven, and more:

# Query osv.dev API
curl "https://api.osv.dev/v1/query" \
  -d '{"package": {"name": "lodash", "ecosystem": "npm"}}' \
  | jq '.vulns[].id'

Subscribing to CVE Feeds

For infrastructure software (nginx, PostgreSQL, Redis, Node.js, etc.):

• NVD notifications: nvd.nist.gov/vuln/search → email alerts by keyword
• Vendor security advisories: Subscribe to your cloud provider, OS vendor, and major software security bulletins
• CVE RSS feeds: Many vendors publish RSS feeds for their security advisories
• CISA KEV (Known Exploited Vulnerabilities): cisa.gov/known-exploited-vulnerabilities-catalog — the subset of CVEs with confirmed in-the-wild exploitation; prioritize these above all others

Checking Your Infrastructure

# Check nginx version against CVE database
nginx -v  # Get version
# Search nvd.nist.gov for "nginx" + version

# Check Node.js release for security updates
node --version
# Check nodejs.org/en/blog/vulnerability for the release line

# Automated: use `trivy` for container/filesystem scanning
trivy fs .  # Scan current directory
trivy image nginx:1.25  # Scan Docker image

Responsible Disclosure

When security researchers discover a CVE:

1. Report privately to the vendor (vendor's security contact or bug bounty)
2. Coordinate disclosure — vendor has time to develop and release a patch (usually 90 days, per Google Project Zero standard)
3. Public disclosure — CVE assigned and advisory published after patch availability
4. Full disclosure — technical details and proof-of-concept published

If you discover a vulnerability in software you use, report it to the vendor first. Most major software vendors have dedicated security reporting pages.

Building a CVE Response Program

1. Inventory your tech stack — know every library, framework, OS, and service you use (SBOM: Software Bill of Materials)
2. Subscribe to feeds for your specific components
3. Define SLAs — Critical CVEs patched within 72 hours, High within 2 weeks
4. Automate detection — Dependabot, Snyk, Trivy in CI/CD
5. Track remediation — every CVE is a ticket with an owner and due date
6. Virtual patching — WAF rules can block exploitation of known vulnerabilities while you prepare the patch