What is a CVE? A Plain-English Guide for Engineering Teams

A CVE is a license plate for vulnerabilities. You don't need to memorize acronyms — you need three things: how to tell if a CVE matters to you, what the score means, and what to do when one shows up in your stack.

TL;DR

A CVE (Common Vulnerabilities and Exposures) is a unique ID assigned to a publicly known security flaw in software. Think of it as a license plate for vulnerabilities: every flaw gets a number, every tool uses the same number, and that's how the entire industry talks about the same problem without confusion.

You don't need to memorize the acronyms. You need to know three things: how to tell if a CVE actually matters to you, what the score means, and what to do when one shows up in something you depend on.

The "license plate" analogy

When a security flaw is discovered in some software — let's say nginx — somebody assigns it an ID like CVE-2026-33032. From that moment on, every security tool, every patch note, every advisory, every Twitter post, and every news article will use that same ID to refer to that exact flaw.

Without CVEs, the industry would be a mess. One vendor would call it "the nginx auth bypass." Another would call it "MCPwn." A third would just describe it. You'd never know if they were talking about the same thing or three different problems.

The CVE program solved this in 1999. A non-profit called MITRE assigns the IDs, and 450+ "authorized issuers" (companies like Microsoft, Red Hat, GitHub, and your favorite open-source projects) can request them when they find flaws.

That's it. That's the whole concept.

What a CVE ID actually tells you

The format is CVE-YEAR-NUMBER. Two things to know:

  • The year is when the ID was reserved, not when the vulnerability was discovered or when it was fixed. CVE-2026-33032 was published in 2026.
  • The number is just a counter. CVE-2024-1234567 is valid — there's no upper limit anymore.

What a CVE ID does not tell you:

  • How serious it is
  • Whether it affects you
  • Whether it's been exploited
  • How to fix it

Those things live in other databases, layered on top of the CVE. This trips people up: they hear "CVE" and think they have everything they need. They don't.

The four things you actually need to know about a CVE

When a CVE comes across your desk — through a vendor advisory, a Slack alert, or a customer asking "are we vulnerable?" — these are the four questions that matter.

1. Are we even running the affected software?

This is the question 80% of people get wrong, because they don't have a clean answer to "what software do we actually run?" If your team has 200 engineers and 1,500 dependencies in your monorepo, you might be running affected software in 30 places without realizing it.

Asset inventory is the boring foundation. Without it, every CVE becomes a panicked Slack thread.

2. How serious is it? (CVSS)

Every important CVE gets scored on the CVSS (Common Vulnerability Scoring System) — a 0 to 10 scale.

  • 0–3.9: Low. Probably won't ruin your week.
  • 4–6.9: Medium. Worth a JIRA ticket.
  • 7–8.9: High. Probably worth dropping things to look at.
  • 9–10: Critical. Stop scrolling and read the advisory now.

CVSS is helpful but incomplete. A CVSS 9.8 in an obscure library nobody runs in production is less urgent than a CVSS 7.0 in something powering your authentication. Score is signal, not gospel.

3. Is anyone actually exploiting it? (KEV and EPSS)

This is the question that separates real security work from paranoia.

  • KEV (Known Exploited Vulnerabilities) is a list maintained by CISA — the U.S. cybersecurity agency. If a CVE is on KEV, attackers are using it right now, in the wild. KEV listings are facts, not predictions.
  • EPSS (Exploit Prediction Scoring System) is a probability score from 0% to 100% that estimates how likely a CVE is to be exploited in the next 30 days. EPSS 95% means "this thing is going to be hit."

A CVSS 9.8 with EPSS 0.1% and no KEV listing is theoretically scary, practically not your problem this week. A CVSS 7.5 with EPSS 92% and a KEV listing is your weekend.

This distinction is where most teams waste effort: they patch by CVSS score and miss the actually-exploited mid-severity stuff.

4. Is there a fix?

Sometimes the vendor releases a patch the same day the CVE goes public. Sometimes there's no patch for weeks. The advisory should tell you.

If there's no patch yet, you're in "compensating controls" territory: temporarily blocking the vulnerable feature, restricting network access, or adding monitoring. Knowing this distinction matters because rolling out an emergency patch and adding a temporary firewall rule are very different operations.

A real example: how to think about CVE-2026-33032

Let's apply this to a real CVE we covered recently.

CVE-2026-33032 — an authentication bypass in nginx-ui (a popular tool for managing nginx configs through a web UI).

  • CVSS: 9.8 — critical
  • Affected: nginx-ui versions before v2.3.4
  • Patch: Yes, available in v2.3.4
  • KEV: Yes, added by CISA on April 13
  • EPSS: High (active exploitation observed)

How an engineering manager should read this:

  1. Do we run nginx-ui anywhere? If yes, this is urgent. If no, scroll past it.
  2. What version are we on? Anything before 2.3.4 is vulnerable.
  3. Is it internet-facing? If yes, assume it's already being scanned by attackers. If it's only accessible from internal networks, urgency drops.
  4. Patch and verify. Update to v2.3.4, restart, confirm.

That's it. Four steps. The hard part isn't the patching — it's knowing whether step 1's answer is "yes."

How CVEs get discovered and published

Most CVEs come from one of three places:

  1. Internal security teams at vendors finding flaws in their own products.
  2. External researchers doing penetration testing, bug bounties, or academic research.
  3. Attackers — yes, sometimes a CVE is born because someone got hacked and the post-mortem revealed a previously unknown flaw.

The disclosure process roughly:

  1. Researcher finds a flaw.
  2. They report it privately to the vendor (this is "responsible disclosure").
  3. Vendor confirms, develops a patch.
  4. A CVE ID is assigned.
  5. Vendor releases the patch.
  6. CVE goes public, often the same day.

Sometimes this works smoothly (most modern vendors). Sometimes it breaks down — vendor ignores the report, or there's a public disclosure before a fix is ready, or attackers find the same flaw independently and start exploiting it before the patch lands. That last case is called a zero-day: the defenders have zero days to prepare.

"Why do we have so many CVEs now?"

There are roughly 30,000+ new CVEs per year. That's about 80 per day. Why so many?

A few reasons working together:

  • More software is being written and maintained than ever before.
  • More researchers are looking for flaws, often professionally.
  • Bug bounty programs incentivize disclosure.
  • AI-assisted code review and fuzzing are finding flaws faster.
  • Open-source projects are increasingly issuing their own CVEs (good thing — used to be that flaws in popular open-source libraries went unidentified for years).

The volume is intimidating but most of these don't apply to most teams. The trick is filtering down to the ones that affect software you actually run.

Where engineering teams usually go wrong

A few patterns we see repeatedly when working with engineering teams:

Treating every CVE as urgent. Most aren't. A "critical" CVE in a library you don't use is noise. Filtering by relevance is more important than filtering by severity.

Treating CVSS as the only signal. CVSS doesn't know your environment. A "high" CVE in an internal-only admin tool is different from the same CVE in your public API gateway. EPSS and KEV add the missing exploitation context.

Not knowing your dependency tree. Most modern apps depend on hundreds of packages, each of which depends on more packages. A CVE might come up in something three layers deep that nobody on your team has ever directly imported.

Patching after the news cycle. By the time a CVE is on Hacker News, attackers have been exploiting it for a week. The window between disclosure and exploitation is often hours, not days.

No system for tracking what's been patched. Patching isn't binary — you patch one service, and now you have to verify, deploy, monitor, and confirm across every environment. Without tracking, you'll think you patched something that's still vulnerable in staging.

The minimum vulnerability management practice for non-security teams

You don't need a full security team to do this well. The minimum viable practice:

  1. Know what you run. Maintain an inventory: services, dependencies, third-party tools. This list is the most valuable security artifact your team owns.
  2. Subscribe to advisories for the major things you depend on. GitHub Dependabot for npm/pip/etc. Vendor security mailing lists for major infrastructure (AWS, Cloudflare, your database). CISA KEV for the high-priority ones.
  3. Have a triage process. When a CVE comes in: who looks at it, who decides if it matters, who owns the patch. Even a one-line Slack workflow is better than nothing.
  4. Patch the high-EPSS, KEV-listed stuff fast. Anything else can usually wait for the regular release cycle.
  5. Track what's been patched. A simple spreadsheet works at small scale. Beyond that, you need tooling.

This isn't about being a security team. It's about not getting blindsided by the obvious things.

Where VulnTracker fits

We built VulnTracker because the steps above sound simple but are mind-numbing in practice. Subscribing to 40 mailing lists, parsing advisories, mapping to your own stack, deduplicating, prioritizing by exploitation rather than CVSS — it's a part-time job nobody on an engineering team has time for.

VulnTracker takes the inventory you already have, watches every CVE source we know about, and tells you only the ones that affect your stack — ranked by exploitation and severity together, not just CVSS.

If you're at the point where you're spending hours triaging CVE feeds manually, start a 5-day free trial. If you're earlier in your journey and just want a daily summary of what's worth knowing across the whole industry, our daily digest is free, no account needed.

Either way, the goal is the same: spend less time chasing CVEs, more time building what you're actually trying to build.

Glossary

  • CVE — Common Vulnerabilities and Exposures. A unique ID for a publicly known security flaw.
  • CVSS — Common Vulnerability Scoring System. 0–10 severity score.
  • CNA — CVE Numbering Authority. An organization authorized to assign CVE IDs (450+ exist).
  • CISA — U.S. Cybersecurity and Infrastructure Security Agency. The federal agency tracking which CVEs are being exploited.
  • KEV — Known Exploited Vulnerabilities. CISA's list of CVEs being exploited in the wild right now.
  • EPSS — Exploit Prediction Scoring System. Probability that a CVE will be exploited within 30 days.
  • NVD — National Vulnerability Database. NIST's database that enriches CVEs with CVSS scores, affected products, and references.
  • MITRE — The non-profit that runs the CVE program.
  • Zero-day — A vulnerability being actively exploited before a patch exists.
  • Responsible disclosure — Privately reporting a flaw to the vendor before going public, giving them time to fix it.
  • Compensating controls — Temporary mitigations (firewall rules, feature toggles) used when a patch isn't yet available.

Got questions about a specific CVE that's affecting your stack? Reply to this post on Twitter or reach out directly — happy to help you think through it.

Be the company hackers skip.