Understanding Vulnerability Databases

Vulnerability databases are centralised repositories that collect, organise, and publish information about known security vulnerabilities. Instead of every security team discovering the same issues repeatedly, vulnerability databases provide a shared source of truth for the cyber security community.

These databases document:

• What the vulnerability is
• Which products or versions are affected
• How severe the issue might be
• Where to find more technical details or fixes

Vulnerability databases are used by security analysts, system administrators, penetration testers, and automated security tools to understand existing threats and make informed security decisions.

Without vulnerability databases:

• Vulnerabilities would be named inconsistently
• Patch tracking would be difficult
• Security tools would lack reliable reference data

By standardising vulnerability information, these databases enable efficient vulnerability management, risk assessment, and remediation planning across organisations.

Learning Objectives

By completing this room, you will:

• Understand what vulnerability databases are  
• Learn why vulnerability databases are important
• Recognise common vulnerability database terminology
• Explore different vulnerability databases through hands-on tasks

Prerequisites

Before starting this room, it is recommended that you are familiar with:

• Networking Core Protocols
• Networking Essentials
• Web Application Basics

Before vulnerability databases existed, security teams often worked in isolation. The same vulnerability could be researched multiple times by different people, described using other names, and patched without clear visibility. This made it easy for critical security issues to be missed or misunderstood.

Vulnerability databases address these challenges by providing a centralised and standardised source of information. They help security professionals:

• Avoid duplicate research by referencing known issues
• Use consistent naming for vulnerabilities across tools and teams
• Stay aware of available patches and security advisories

Vulnerability databases also help connect the full security lifecycle. A vulnerability describes a weakness in software or configuration, an exploit demonstrates how that weakness can be abused, and a patch or mitigation provides a way to fix it. Databases act as the link that ties all of this information together.

In real-world security operations, vulnerability databases are essential for vulnerability management and patching. They allow teams to track affected systems, prioritise fixes, and reduce risk in a structured and efficient way.

Vulnerability databases use standardised building blocks to describe security issues in a consistent and actionable way. These building blocks ensure that vulnerabilities can be accurately identified, assessed, and referenced across different tools and databases.

Vulnerability Identifier (CVE)

A vulnerability identifier uniquely identifies a known security flaw so it can be tracked consistently across tools and databases. The most widely used identifier is the Common Vulnerabilities and Exposures (CVE) system (opens in new tab), which assigns a unique ID to each vulnerability. For example, CVE-2021-44228 refers to the Log4Shell vulnerability, allowing scanners, databases, and reports to reference the same issue unambiguously.

Severity Representation (CVSS)

Severity in vulnerability databases is represented using the Common Vulnerability Scoring System (CVSS) (opens in new tab). CVSS assigns a numerical score that reflects how easily a vulnerability can be exploited and the potential impact if it is successfully abused. For example, a vulnerability with a CVSS score of 9.8 is considered critical and generally requires immediate attention. You can learn more about CVSS ratings in the Vulnerabilities 101 room. 

Affected Product Identification (CPE)

Vulnerability databases identify affected software using Common Platform Enumeration (CPE) (opens in new tab), which provides a standardised naming format for vendors, products, and versions to clearly define what is vulnerable. For example, instead of stating “Apache is affected,” a CPE entry specifies the exact Apache version that contains the vulnerability.

Common Weakness Enumeration (CWE)

Vulnerability databases also classify the underlying weakness that caused a security issue using Common Weakness Enumeration (CWE), which groups vulnerabilities by root cause, helping security professionals understand why a flaw exists, not just what is affected. For example, a vulnerability mapped to CWE-94 (Improper Control of Generation of Code) indicates a code-injection weakness, even if it appears across different products.

CVE Numbering Authorities (CNA)

CVE Numbering Authorities (CNAs) (opens in new tab) are organisations authorised to assign CVE identifiers to newly discovered vulnerabilities. CNAs help scale the CVE program by allowing vendors and organisations to report vulnerabilities in their own products directly. For example, Microsoft, as a CNA, assigns CVE IDs to vulnerabilities affecting Windows or Microsoft services, ensuring these issues are consistently tracked across the CVE List and other vulnerability databases.

Vulnerability Metadata

In addition to identifiers and severity scores, vulnerability entries include metadata such as a technical description, reference links, and remediation information. This data helps users understand the vulnerability and locate trusted guidance. For example, a CVE entry may include links to vendor advisories or security research explaining how to patch the issue.

Severity vs Risk

Severity describes the technical impact of a vulnerability, while risk considers how that vulnerability affects a specific environment. Risk depends on factors such as system exposure, usage, and business importance. Example: A high-severity vulnerability on an isolated test system presents lower risk than a medium-severity vulnerability on an internet-facing production server.

The CVE List is a public catalogue of known security vulnerabilities that provides a unique identifier for each issue. Its primary purpose is to ensure that every vulnerability can be consistently referenced across tools, reports, and databases.

The CVE List is maintained by MITRE (opens in new tab), which coordinates with vendors and security researchers to assign CVE identifiers. MITRE does not analyse severity or provide remediation guidance; its role is limited to tracking and standardising vulnerability names.

Each CVE entry provides a standardised identifier, a brief description of the vulnerability, and information about affected vendors or products, allowing security professionals to recognise and reference an issue quickly. The CVE List may also include severity scores and version details when provided by the assigning authority. 

Practical

Open your browser and navigate to the official CVE website at https://www.cve.org (opens in new tab). Use the search bar to look up CVE-2026-22869, which will display the vulnerability details as shown below:

Once you search for the CVE, you will get the following results:

1. The top of the page displays the Published and Updated dates, both listed as 2026-01-13, showing when the vulnerability was first disclosed and last modified.
2. The Title and Description section shows that the vulnerability allows arbitrary code execution in Eigent through a GitHub Actions CI workflow using the pull_request_target trigger.
3. The CWE for this CVE is CWE-94, which shows that the vulnerability is caused by improper control of code generation, leading to a code injection issue.
4. Locate the CVSS section and review the severity information. Observe the CVSS v4.0 score of 8.9 (High), indicating that the vulnerability can be exploited remotely without authentication or user interaction.
5. This section shows the exact products affected by the vulnerability; in this case, the vendor is eigent-ai, the product is eigent, and all versions prior to commit bf02500bbbab0f01cd0ed8e6dc21fe5683d6bfb5 are affected.

The CVE List provides structured information, including vulnerability descriptions, severity scores, weakness classifications, and affected products. However, it may not always include exploitation details, proof-of-concept, or mitigation steps, which require further research from external sources.

The National Vulnerability Database (NVD) is a public vulnerability database maintained by the National Institute of Standards and Technology (NIST). It builds upon the CVE List by enriching CVE entries with additional analysis, scoring, and structured data.

While the CVE List focuses on uniquely identifying vulnerabilities, the NVD provides context and assessment, making it more useful for risk analysis and vulnerability management workflows. The NVD enhances CVE records by adding CVSS severity scoring, CPE-based affected product mappings, and impact metrics. This allows security teams to better understand the vulnerability's severity and which specific systems may be affected.

Unlike the CVE List, the NVD performs its own analysis and standardisation, ensuring consistency across severity scores and product data. As a result, many security tools rely on the NVD as a primary data source for vulnerability prioritisation.

Practical

Open your browser and navigate to the NVD vulnerability search (opens in new tab)page as shown below:

Use the search bar to look up CVE-2025-67501 and open the vulnerability record from the results list.

Once the CVE detail page loads, observe the following sections:

1. Description: The description explains that WeGIA, an open-source web manager, contains an SQL injection vulnerability in the /html/matPat/editar_categoria.php endpoint due to improper input validation of the id_categoria parameter. It also clearly states that the issue is fixed in version 3.5.5.
2. Metrics: Scroll to the metrics section and note that NVD has not yet provided its own CVSS score, while the CNA (GitHub, Inc.) assigns a CVSS v4.0 score of 9.4 (Critical). This highlights how NVD displays multiple severity sources when available.
3. References: Scroll to the References section and observe the listed external links. One of the references is tagged as Exploit, which links to a GitHub Security Advisory. This advisory provides technical details and proof-of-concept information demonstrating how the SQL injection vulnerability can be exploited.
4. Weakness Enumeration: Locate the CWE section, which maps this vulnerability to CWE-89, confirming that the root cause is SQL injection.
5. Known Affected Software Configurations: Review the affected software list, which uses CPE identifiers to show that WeGIA versions up to (but not including) 3.5.5 are vulnerable.

Most of the time, the CVE List (on CVE.org (opens in new tab)) and the NVD detail page show the same description, product info, and links; it’s because the NVD has already enriched that CVE with all available data. While both CVE.org and the NVD reference the same CVE identifiers, the NVD is generally more comprehensive.

The NVD enriches CVE records with detailed CVSS severity scoring and vector breakdowns, clearly tagged references such as patches or exploits, and structured CPE and CWE mappings. This additional context makes the NVD more useful for vulnerability assessment, prioritisation, and risk-based decision-making than the CVE List alone.

In addition to the CVE List and the NVD, several other public vulnerability databases exist, each designed to serve a specific purpose during pentesting or securing a system.

Exploit-focused databases, such as ExploitDB, concentrate on proof-of-concept exploits and real-world attack techniques. Penetration testers and red teamers commonly use these databases to understand how vulnerabilities can be practically exploited.

Vendor security advisories are published directly by software vendors and provide authoritative information about vulnerabilities in their products. These advisories often include patch availability, mitigation steps, and recommended upgrade paths, making them valuable for defenders and system administrators.

Community-driven and regional databases collect vulnerability information from open-source contributors, researchers, or region-specific CERTs. These databases may surface issues earlier than official sources or provide additional context not found elsewhere.

Each of these databases serves a different role; some focus on exploitation, others on remediation, and others on early disclosure or regional awareness. Together, they complement the CVE List and NVD rather than replacing them.

Practical

Open your browser and navigate to the Exploit Database search (opens in new tab)page:

Use the search bar to look up CVE-2025-10327. You can also search using other filters, such as exploit title, platform, author, or content, if a CVE ID is not available.

Once the results load, note that ExploitDB lists a matching exploit entry. Click on the exploit to view its full details.

On the exploit detail page, review the following information:

• Exploit overview: The page shows the exploit title “RPi-Jukebox-RFID 2.8.0 - Remote Command Execution”, along with a unique EDB-ID (52468) and the associated CVE-2025-10327.
• Exploit Metadata: Note the author name, exploit type (WEBAPPS), platform (MULTIPLE), and the publication date. This metadata helps identify the exploit’s origin and intended target environment.
• Exploit Authenticity: The small down arrow next to Exploit indicates whether a downloadable PoC is available for the exploit. The EDB Verified label indicates whether the exploit has been tested and verified by ExploitDB. Additionally, the Vulnerable App field is useful for quickly setting up a PoC, as it points to the affected application or version needed to test the exploit.
• Proof-of-Concept Code: Scroll down to view the Python-based exploit code, which demonstrates how an attacker can inject a malicious payload into the playlist parameter to execute arbitrary system commands on the target system.

Unlike the CVE List and NVD, which focus on identification and assessment, ExploitDB provides hands-on exploitation details and proof-of-concept code. This makes exploit-focused databases particularly valuable for understanding how vulnerabilities are abused in real-world attacks.

Vulnerability databases play a critical role in cyber security by providing a structured and standardised way to identify and exploit vulnerabilities in a system.

In this room, we explored why these databases matter, the key building blocks they use, and how different databases, such as the CVE List, NVD, and ExploitDB, serve different purposes. Through hands-on tasks, we learned how to search for vulnerabilities, interpret severity scores, identify affected products, and locate exploit information. Together, these skills help security professionals, especially a pentester, assess risk more effectively and make informed security decisions.

We hope you enjoyed learning and sharpening your skills throughout this room!