What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for one disclosed vulnerability in a specific product, written as CVE-year-number, for example CVE-2026-111497. The CVE Program, run by MITRE with authorized numbering authorities, assigns it so everyone can refer to the same flaw by the same name.

Why it matters

Before CVE, each vendor and scanner named the same flaw differently, so nobody could tell whether two advisories meant the same thing. A CVE ID solves the naming problem and only that: the record holds a description, the affected products and versions and references, and other databases add the rest. NIST's National Vulnerability Database (NVD), for instance, adds CVSS severity scores and CWE classifications to CVE records.

IDs are assigned by CVE Numbering Authorities (CNAs): vendors such as large software companies for their own products, open-source projects, and coordinators. The year in the ID is the year the ID was assigned, or the year the flaw was made public if that came first; it says nothing about when the bug was introduced.

Example: from a CVE ID to 'am I affected?'

Take CVE-2026-111497, the memory-corruption bug in the Brotli decoder that our brief calls HTTP2Shell. The ID alone tells you nothing about your app; the work is matching the record against what you run:

1. Read the record on cve.org and the vendor's advisory linked from it. Write down the affected product and the exact affected and fixed versions.

2. Find what you run, with harmless commands on your own systems: your package lockfile, the server's version output, the container image tag. On CyberGym, the legal practice target, one endpoint reports the app's version directly:

$ curl -s https://cybergym.hackergpt.app/rest/admin/application-version
{"version":"19.1.1"}

3. Compare. If your version is in the affected range and the vulnerable feature is reachable, patch; if a fix is not available yet, apply the vendor's interim mitigation. The same version endpoint is also a reminder of why exposing versions publicly helps attackers do this matching faster than you.

Common mistakes

  • Treating 'no CVE' as 'no vulnerability'. Bugs in your own code never get a CVE. CVEs cover published products, not your app's logic.
  • Patching by CVE count. Ten low-impact CVEs can matter less than one that is reachable and exploited. Prioritise by exposure and exploitation.
  • Trusting the first blog post. Affected version ranges get corrected after publication. Check the record and the vendor advisory.
  • Confusing CVE with CVSS or CWE. CVE names one flaw, CVSS scores its severity, CWE names the kind of weakness.

Related terms

Go deeper

Sources

Test only sites you own or have written permission to test. To practise without one, use CyberGym, a legal, deliberately vulnerable target. Practise on CyberGym.