The short answer: A CVE (Common Vulnerabilities and Exposures) is a unique tracking number for a publicly known security flaw in a specific piece of software or hardware, like CVE-2026-12345. It does not tell you whether you are affected or how urgent it is. That takes three more questions: Do we run it? Is it reachable? Is anyone actually exploiting it?
If you have a website, a laptop, or a payment terminal, CVEs apply to you. A plugin on a bakery’s WordPress site, the firewall your IT team installed in 2019, and the ERP system finance runs on all show up in the same public list.
The problem isn’t a lack of information. It’s too much of it. In 2025, 48,185 CVEs were published, up 20.6% from 2024. That’s roughly 132 new flaws every day. Nobody patches all of them, and nobody needs to.
This guide explains what a CVE is once, then breaks out what it means for three readers: the owner of a non-IT business with a website, the IT manager who came up through networking, and the executive who signs off on risk.
What a CVE actually is
Think of a CVE like a vehicle recall number. The number doesn’t fix the car, and it doesn’t mean your car has the problem. It gives everyone, from the manufacturer to the mechanic to the owner, one name for the same defect.
A CVE ID has three parts:
- CVE: the prefix, meaning it’s in the official list.
- 2026: the year the ID was assigned or the flaw was made public, not necessarily when it was discovered.
- 12345: a sequence number. There’s no meaning in it; higher isn’t worse.
Who runs it. The CVE Program has been run by the nonprofit MITRE under a contract funded by CISA. Hundreds of vendors and researchers, called CVE Numbering Authorities (CNAs), can assign IDs for their own products. In April 2025, the program came within a day of losing its federal contract before CISA extended it by 11 months. CVE Board members also launched the independent CVE Foundation to reduce reliance on a single funder. It was a reminder that the industry leans heavily on this one shared list.
Where the details live. The CVE record itself is short: an ID, a description, and references. Databases like NIST’s National Vulnerability Database (NVD) and vendor advisories add severity scores, affected versions, and fix guidance.
What a CVE is not.
- Not proof you’re vulnerable. You have to be running the affected version.
- Not a measure of urgency. That comes from scoring and real-world exploitation data (next section).
- Not the whole picture. Misconfigurations, weak passwords, and exposed files often have no CVE at all, and they cause plenty of breaches.
How CVEs get prioritized: three signals that matter
A CVE number tells you what. These three signals tell you how worried to be.
| Signal | Who publishes it | What it answers | Scale |
|---|---|---|---|
| CVSS (Common Vulnerability Scoring System) | FIRST; scores appear in NVD and vendor advisories | How bad could this be in theory? | 0.0–10.0 (None, Low, Medium, High, Critical) |
| EPSS (Exploit Prediction Scoring System) | FIRST | How likely is it to be exploited in the next 30 days? | 0–100% probability |
| CISA KEV (Known Exploited Vulnerabilities) | CISA | Has it been confirmed exploited in the wild? | Listed / not listed |
Here’s why that matters. Of the 48,185 CVEs published in 2025, 3,984 were rated Critical. CISA added only 245 vulnerabilities to its KEV catalog that year, bringing it to 1,484 total, and many of those additions were older flaws, not 2025 ones. Put simply, the list of confirmed-exploited flaws grew by roughly one entry for every 200 CVEs published.
CVSS alone overstates urgency. As we covered in Attack-Path Analysis: Why Isolated CVEs Miss Your Real Risk, a “critical” on an isolated test box can matter less than a “medium” on an internet-facing server. Real priority comes from combining severity, exploitation, and where the flaw sits in your environment.
If you own a business with a website
You don’t need to read CVE feeds. You need to know what your website is built on and who keeps it updated.
Most small-business sites run on a stack of other people’s software: a content system like WordPress, Wix, Shopify, or Squarespace; themes and plugins; a programming language like PHP; and a hosting server. Each layer can get CVEs. On fully hosted platforms like Wix, Shopify, and Squarespace, the vendor patches the core for you, but third-party apps and custom code are still your responsibility. Attackers use automated tools that scan millions of sites for known flaws, so being small doesn’t make you invisible. It just makes you an easy target if nothing gets patched.
What a CVE could mean for you in practice:
- A contact-form plugin flaw lets someone inject spam links or malware into your pages.
- An outdated e-commerce extension exposes customer names, addresses, or order data.
- Your site gets flagged by Google as unsafe, and traffic drops overnight.
Questions to ask your web designer, agency, or host:
- Who is responsible for applying security updates, and how often?
- Which plugins or add-ons are installed, and are any no longer maintained?
- What version of PHP (or other language) is the site on? PHP 8.1 is already past end of life, and PHP 8.2 security support ends December 31, 2026. If you’re on either, see our PHP 8.2 end-of-life guide.
- Do we have backups we’ve actually tested restoring?
- Would we know if the site were compromised?
If nobody has a clear answer, that’s your first action item, not a CVE.
If you’re an IT manager who came up through networking
You already think in reachability. Use it. A CVE on a device is a question of what can talk to it, the same way you’d reason about an ACL or a routing table.
The shift from network engineering to vulnerability management is mostly a shift in scope. You used to track firmware on switches, routers, and firewalls. Now the inventory includes web apps, APIs, cloud services, endpoints, and the open-source libraries buried inside all of them.
A practical triage order:
- KEV-listed and internet-facing. Patch or mitigate now. Edge devices like VPN concentrators, firewalls, and remote-access gateways show up in KEV constantly.
- KEV-listed, internal only. Next in line. Assume a foothold is possible and these become the lateral-movement path.
- High EPSS, reachable from untrusted networks. Schedule within your normal patch window.
- High CVSS, low EPSS, segmented. Track it. Compensating controls like segmentation, ACLs, and disabling the vulnerable service often buy time.
- Everything else. Batch it into routine maintenance.
Where network instincts help most:
- Segmentation is a mitigation. A critical CVE on a VLAN nothing can reach is lower priority. Document that reasoning; auditors will ask.
- Management planes matter. Exposed admin interfaces turn moderate CVEs into serious ones.
- Choke points beat volume. Fixing one flaw that sits on many attack paths reduces more risk than closing fifty isolated findings.
Where to watch out: Scanner output is noisy. False positives, duplicate findings across tools, and version-string guesses (“the banner says 2.4.49, so it must be vulnerable”) eat hours. Verify before you escalate, and track the CVE through to a confirmed fix, not just a closed ticket.
If you’re in the C-suite
A CVE is a business risk with a public timestamp. Once a flaw is published, attackers, customers, insurers, and regulators can all see it. What they’ll want to know is how quickly you responded.
Why it reaches your desk:
- Disclosure and liability. Breaches traced to a known, unpatched CVE are hard to defend. “We knew about it for six months” reads badly in a breach notice, a lawsuit, or an SEC filing.
- Compliance. Frameworks like SOC 2, CMMC / NIST 800-171, PCI DSS, and ISO 27001 all expect a documented process for finding and fixing known vulnerabilities on a defined timeline.
- Cyber insurance. Underwriters increasingly ask about patch cadence and exposure to known-exploited flaws when pricing or renewing coverage.
- Customer trust. Security questionnaires from enterprise buyers routinely ask how you handle critical CVEs.
Metrics worth asking for (and ones to stop asking for):
| Ask for this | Instead of this | Why |
|---|---|---|
| Time to remediate KEV-listed CVEs on internet-facing systems | Total open CVE count | Counts grow with every scan; exposure time is what attackers exploit |
| % of critical assets with no known-exploited path | % of CVEs closed | Closing 1,000 low-risk findings can hide one open door |
| Exceptions with an owner and an expiry date | “We accept the risk” | Accepted risk without a review date becomes forgotten risk |
The one question to ask your team: “If a CVE in something we run hits the CISA KEV list tomorrow, how long until we know, and how long until it’s fixed?” A confident answer in hours or days is good. “It depends” is a gap worth funding.
A short checklist, whatever your role
- Know what you run: websites, plugins, devices, cloud services, and who owns each.
- Know who patches it and how often.
- Check new CVEs against the CISA KEV catalog first, not CVSS alone.
- Prioritize anything reachable from the internet.
- Verify findings before escalating; scanners guess.
- Track each fix through to confirmed remediation.
- Report on exposure time and closed attack paths, not raw CVE counts.
Stop Sorting by Score. Start Fixing What Matters.
Scan Ninja's AI-native scanner finds vulnerabilities across your websites, APIs, and infrastructure, filters out false positives at the source, and ranks what's left by real exploitability and business impact. Whether you need a one-time PHP Exposure Assessment for a single site or ongoing Managed Vulnerability Remediation, we take you from findings to verified fixes.
Sources
- 2025 CVE Data Review — Jerry Gamblin (48,185 CVEs in 2025; 3,984 Critical)
- CISA Expands KEV Catalog — Cybersecurity News (245 KEV additions in 2025; 1,484 total)
- CVE database funding extended — Cybernews (April 2025 contract extension)