CVE stands for Common Vulnerabilities and Exposures and is the global reference catalogue for publicly known security vulnerabilities. The program has been run by the MITRE Corporation since 1999 and is funded by the US cybersecurity agency CISA. Every vulnerability gets a unique identifier in the format CVE-YEAR-NUMBER, such as CVE-2021-44228 for Log4Shell, so that vendors, scanners, researchers and news articles all mean the same flaw. The IDs are assigned by several hundred CVE Numbering Authorities (CNAs) worldwide. The severity of a CVE is rated with the Common Vulnerability Scoring System (CVSS), a 0.0 to 10.0 scale maintained by FIRST: from 9.0 the rating is Critical, 7.0 to 8.9 is High, 4.0 to 6.9 Medium and below that Low. The scale of the system has grown dramatically: more than 40,000 new CVEs were published in 2024 alone, and in the WordPress ecosystem just under 8,000 vulnerabilities were disclosed in 2024, about 96 percent of them in plugins.
What does CVE stand for?
Before CVE existed, every security vendor described vulnerabilities in its own words, and nobody could tell whether the buffer overflow in one advisory was the same bug as the remote exploit in another. The Common Vulnerabilities and Exposures program, started by MITRE in 1999, solved this with something deceptively simple: a unique name per flaw. A CVE record contains that ID, a short description, references to advisories and patches, and the affected products.
The ID format is CVE-YEAR-NUMBER, where the year is the year of assignment, not necessarily of discovery, and the number has four or more digits. The official database lives at cve.org. On top of it sits the National Vulnerability Database (NVD), run by the US standards institute NIST, which enriches CVE records with severity scores, affected version ranges and weakness classifications. When your security scanner shows severity data for a CVE, it usually comes from the NVD.
How does a vulnerability get a CVE ID?
CVE IDs are handed out by CVE Numbering Authorities, CNAs for short. These are software vendors, security companies and research organisations authorised to assign IDs for their own products or their area of coverage. The network has grown to several hundred CNAs across dozens of countries, which is why a researcher who finds a flaw in, say, a Cisco product reports it to Cisco directly, and Cisco assigns the CVE itself.
The typical flow looks like this: a researcher discovers a vulnerability and reports it to the responsible CNA, the CNA reserves a CVE ID while the fix is being developed, and once a patch ships, the record is published together with the advisory. That reservation phase explains why you sometimes see a CVE ID mentioned publicly with no details attached yet.
For WordPress users there is a detail worth knowing: Wordfence, WPScan and Patchstack are all CNAs. The vast majority of WordPress plugin and theme CVEs are assigned by one of these three, which is also why their vulnerability databases are the most complete sources for the WordPress ecosystem.
What is the CVSS score?
A name alone does not tell you how bad a flaw is. That is the job of the Common Vulnerability Scoring System, an open standard maintained by FIRST, the global association of incident response teams. CVSS condenses the technical characteristics of a vulnerability into a score between 0.0 and 10.0. Version 2 appeared in 2007, version 3.0 in 2015, the refinement 3.1 in 2019, and version 4.0 in November 2023. In practice, most databases and advisories still speak CVSS 3.1, with 4.0 adoption growing slowly.
CVSS severity ratings from None to Critical
| Rating | CVSS score | Typical meaning |
|---|---|---|
| None | 0.0 | No impact |
| Low | 0.1 to 3.9 | Hard to exploit or very limited impact |
| Medium | 4.0 to 6.9 | Real impact, but with preconditions such as user interaction or existing privileges |
| High | 7.0 to 8.9 | Serious impact, often data exposure or privilege escalation |
| Critical | 9.0 to 10.0 | Typically unauthenticated remote exploitation with full compromise |
The infamous 9.8 you see on so many advisories is the signature score of an unauthenticated remote code execution: reachable over the network, no privileges, no user interaction required. A perfect 10.0 additionally breaks out of the vulnerable component into other systems, which is what Log4Shell managed.
How is a CVSS score calculated?
The base score is derived from a handful of metrics that describe how a flaw can be reached and what it breaks. On the exploitability side: Attack Vector (network, adjacent, local, physical), Attack Complexity, Privileges Required and User Interaction. On the impact side: the effect on Confidentiality, Integrity and Availability, plus in version 3.1 the Scope metric, which captures whether the damage crosses into other components. The individual choices are recorded in a compact vector string that you will find on every NVD entry:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N reachable over the network
AC:L low attack complexity
PR:N no privileges required
UI:N no user interaction needed
S:U scope unchanged
C:H/I:H/A:H high impact on confidentiality, integrity, availability
Result: base score 9.8, CriticalThe nice thing about the vector is that it tells you more than the number. A 7.5 with PR:N and a 7.5 with PR:H are very different animals for your threat model, and reading the vector takes ten seconds once you know the abbreviations.
What is new in CVSS 4.0?
Version 4.0 addresses the biggest criticisms of 3.1. The confusing Scope metric is gone, replaced by separate impact ratings for the vulnerable system and subsequent systems. User Interaction is now more nuanced with passive and active variants, and a new Attack Requirements metric captures conditions that must exist on the target. The old temporal metrics were reworked into threat metrics, and the standard now names its score flavours explicitly: CVSS-B for the pure base score, CVSS-BT with threat data and CVSS-BE with environmental context. Conceptually this is all an improvement. Practically, the ecosystem moves slowly, so expect to read 3.1 vectors for years to come.
Why a high CVSS score is not automatically your biggest risk
Here is the uncomfortable truth about CVSS: it measures severity, not probability. The overwhelming majority of published CVEs are never exploited in the wild at all, while some medium-scored flaws get hammered within hours because an exploit is public and the target is everywhere. Two datasets help close that gap. The EPSS score, also from FIRST, estimates the probability that a vulnerability will be exploited in the next 30 days based on real-world telemetry. And the CISA KEV catalogue lists vulnerabilities with confirmed exploitation, which is the strongest signal available.
A practical prioritisation rule for a site owner: patch first what is in KEV or has a high EPSS score and sits in an internet-facing component. A 9.8 in a plugin you deactivated last year matters less than a 7.5 in the contact form plugin that every visitor can reach. Severity is context, and only you know your context.
CVEs in the WordPress ecosystem
WordPress core itself is a hard target these days and accounts for well under one percent of disclosed vulnerabilities. The action is in the extension ecosystem: according to Patchstack, just under 8,000 new vulnerabilities were disclosed in the WordPress ecosystem in 2024, roughly 96 percent of them in plugins and most of the rest in themes. The most common categories are cross-site scripting, cross-site request forgery and broken access control. None of this means WordPress is insecure, it means the security of your site is decided by which plugins you install and how fast you update them. A plugin with 100,000 installations and a known unpatched flaw is a mass-scanning target within days, sometimes hours.
Famous CVE examples
- CVE-2014-0160, Heartbleed: memory disclosure in OpenSSL that let attackers read private keys from servers. The bug that gave vulnerabilities logos and names.
- CVE-2017-0144, EternalBlue: the SMB flaw behind the WannaCry ransomware wave in 2017.
- CVE-2021-44228, Log4Shell: a CVSS 10.0 in the Java logging library Log4j. One crafted string in any logged field led to remote code execution, and half the internet logged user input.
- CVE-2023-4966, Citrix Bleed: session token leakage in Citrix NetScaler, exploited by ransomware groups against thousands of appliances.
How does InspectWP use CVE data?
InspectWP detects the plugins and themes of an analysed WordPress site and matches them against known vulnerability data, so a report can tell you that a specific installed component has a published CVE, how severe it is and that an update is available. That closes the annoying gap between a CVE existing somewhere in a database and you actually finding out that it concerns one of your sites. Combined with scheduled automatic reports, you get the practical version of vulnerability management for WordPress: know what you run, know what is broken, update the things that matter first.