What is a CVE, and how do you know if you are affected?
A shared name for a known flaw
You have seen them in dependency warnings, security advisories and news headlines: CVE-2024-12345. A CVE is simply a public, unique identifier for one specific, known security vulnerability in software. That is the whole concept — it is a catalogue number so that everyone in the world refers to the same flaw by the same name, instead of describing it five different ways.
What the ID means
The format is CVE-YEAR-NUMBER. The year is roughly when it was assigned, and the number is just a sequential identifier within that year. The ID itself carries no judgement about how bad the flaw is — CVE-2024-0001 is not more serious than CVE-2024-9999. It is a label, not a ranking.
Each CVE points to a record describing the affected software, which versions are vulnerable, and usually how the flaw can be triggered. Think of it as the index card; the details live on the card, not in the number.
Severity is a separate thing
Because the ID says nothing about impact, severity is tracked separately — most commonly via a CVSS score from 0 to 10, plus context like whether the flaw is being actively exploited in the wild. Two CVEs can describe wildly different risks: one a remote, no-authentication takeover, another a minor issue that needs an unlikely set-up. Always read past the ID to the score and the conditions.
The question that actually matters: are you affected?
A CVE existing does not mean you are exposed. You are affected only if three things line up:
- You use the affected software. It is a dependency of your app, directly or transitively, or part of your server stack.
- You run an affected version. The record lists which versions are vulnerable; if yours is outside that range, often you are fine.
- The flaw is reachable in how you use it. Some vulnerabilities only apply to a feature or configuration you may not even use.
All three matter. A scary CVE in a library you do not call the vulnerable part of may be a non-event for you — and a 'medium' one in something internet-facing may be your top priority.
How to check yourself
- Audit your dependencies. Tooling that reads your lockfile can flag known CVEs in the packages you actually pull in, including transitive ones.
- Know your versions. Keep track of what versions of frameworks, servers and libraries you run, so you can match them against advisories quickly.
- Watch trusted advisories. Follow the security feeds for your stack rather than reacting only to headlines.
- Patch deliberately. When a CVE applies to you, updating to a fixed version is usually the fix — done with a lockfile so you know what changed.
This is routine maintenance, not a fire drill. Most CVEs you encounter will not apply to you; the skill is quickly telling which ones do.
Check what your live site reveals
Some vulnerabilities show up in what your running site exposes — server banners, outdated components, telltale headers. An automated scan inspects your live responses for these signals so you are not relying on memory of every version you deployed. Scan your site and see what it reveals.