Application Security

What Is CVE (Common Vulnerabilities and Exposures)?

CVE stands for Common Vulnerabilities and Exposures. It is a system that keeps track of cybersecurity vulnerabilities that are already known to the public.

What Is CVE (Common Vulnerabilities and Exposures)?

CVE stands for Common Vulnerabilities and Exposures. It is a system that keeps track of cybersecurity vulnerabilities that are already known to the public.

Each CVE record has its own ID, like CVE-2024-492881, and explains a specific weakness in software, hardware, or firmware that attackers could use to exploit the system.

The CVE Program was launched by MITRE Corporation, a U.S. federally funded nonprofit focused on cybersecurity and technology. Today, MITRE continues to manage the CVE system with oversight from the CVE Board—a group that includes security experts, vendors, and global stakeholders. Organizations, vendors, security tools, and researchers worldwide use CVE to track vulnerabilities and manage patches.

Why CVE Matters in Cybersecurity

Before CVE, researchers and organizations relied on separate naming schemes, which made it difficult to track vulnerabilities across different tools and reports.

CVE helps solve this problem by offering:

  • Consistent identifiers for each vulnerability
  • Centralized visibility into the global security database
  • Easier collaboration among vendors, researchers, and organizations involved in cybersecurity.

CVE forms the foundation for security tools like vulnerability scanners, SCA, ASPM, and patch management systems that rely on CVE IDs to detect and prioritize risks.

How does CVE work?

Each CVE record in the vulnerability database includes

  • A CVE ID - a unique identifier for a vulnerability
  • A Description - explanation of the vulnerability
  • References - trusted external sources that provide detailed information about vulnerability
  • A CVSS Score - severity rating, a rating that tells you how serious or impact of a vulnerability is if it’s exploited.

All CVEs are stored publicly at cve.org, and also mirrored in the National Vulnerability Database (NVD) maintained by NIST (National Institute of Standards and Technology), which is a non-regulatory agency of the United States Department of Commerce.

Known vs. Unknown Vulnerabilities

Known Vulnerabilities

Vulnerabilities that security organizations and researchers are aware of and can provide patches to address the vulnerabilities.

The known vulnerabilities are often already published in databases like CVE or NVD.

Example:

CVE-2017-5638 — the Apache Struts vulnerability exploited in the Equifax breach (2017).

Unknown (Zero-Day) Vulnerabilities

These are undiscovered or undisclosed flaws; they exist in software but are not yet documented in CVE databases.

Attackers can exploit them before the vendor releases a patch. This is a flaw that is very dangerous.

Example:

A browser vulnerability is used by attackers before Google or Microsoft releases a fix.

  • NVD (National Vulnerability Database)
  • CVSS (Common Vulnerability Scoring System)
  • Zero-Day Vulnerability
  • Exploit
  • Patch Management
  • Vulnerability Management
  • Common Weakness Enumeration (CWE)

FAQ: CVE

What is a CVE ID?

A CVE ID is a unique identifier assigned to a publicly disclosed vulnerability (e.g., CVE-2025-01234).

Who maintains the CVE system?

The CVE Program is managed by MITRE Corporation, with oversight from the CVE Board and funding by U.S. government agencies such as the Department of Homeland Security (DHS) and CISA.

Are all vulnerabilities listed in CVE?

No. Only publicly known vulnerabilities get CVE IDs. Unknown vulnerabilities or Zero-day vulnerabilities are not yet registered.

How do CVE and CVSS relate?

CVE identifies the vulnerability; CVSS (Common Vulnerability Scoring System) measures its severity.

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)