Vulnerability Scanning with CVE and Exploit Databases

What is Vulnerability Scanning?

Vulnerability scanning is the process of identifying known weaknesses in systems, software, and configurations. Unlike exploitation, scanning focuses on detection and enumeration — finding what vulnerabilities exist before deciding how to act on them.

Two essential resources for vulnerability research are:

• The CVE (Common Vulnerabilities and Exposures) system
• The Exploit Database

CVE — Common Vulnerabilities and Exposures

The CVE program provides a standardized dictionary of known vulnerabilities and security issues in software and hardware products. Each vulnerability is assigned a unique CVE ID with a standardized format:

CVE-[YEAR]-[NUMBER]

Examples:
CVE-2024-29988    → a 2024 vulnerability with ID 29988
CVE-2014-0160     → Heartbleed (OpenSSL vulnerability)
CVE-2017-0144     → EternalBlue (SMB vulnerability used by WannaCry)

The MITRE Corporation maintains the CVE system. MITRE assigns CVE IDs and manages the overall program, while CVE Numbering Authorities (CNAs) — which include vendors, researchers, and government agencies — can also assign IDs within their domains.

Why CVE IDs Matter

Without a standardized identifier, everyone from security researchers to vendors and IT professionals might refer to the same vulnerability with different names, descriptions, or severity ratings. CVE IDs ensure:

• A shared vocabulary across the entire security community
• Unambiguous reference to a specific vulnerability
• Linkage between advisories, patches, and exploit code

National Vulnerability Database (NVD)

The National Vulnerability Database (NVD) is maintained by NIST (National Institute of Standards and Technology) and enriches CVE entries with additional metadata:

• CVSS scores (Common Vulnerability Scoring System) — a numerical severity rating from 0.0 to 10.0
• Affected product versions and vendor information
• Remediation guidance and patch references
• Weakness types (CWE classifications)

CVSS Severity Ratings:
0.0        → None
0.1 – 3.9  → Low
4.0 – 6.9  → Medium
7.0 – 8.9  → High
9.0 – 10.0 → Critical

How to query NVD:

Navigate to https://nvd.nist.gov/ and search by:

• CVE ID (e.g., CVE-2014-0160)
• Vendor name
• Product name
• CVSS score range

Example: Heartbleed (CVE-2014-0160)
CVSS: 7.5 (High)
Affected: OpenSSL 1.0.1 through 1.0.1f
Impact: Arbitrary memory disclosure — attackers could read server memory
        including private keys, session tokens, and user data

Exploit Database

Once a vulnerability is identified, the next step in a penetration test is finding whether working exploit code exists. The Exploit Database (exploit-db.com) is the primary public repository for exploit code.

What Exploit DB provides:

• Exploit code submitted by researchers and security professionals
• Categorization by vulnerability type, platform, and CVE
• Verified exploits marked as tested and confirmed to work

Workflow:
1. Discover vulnerability on target (via scanner or manual testing)
2. Look up CVE ID
3. Search Exploit DB for that CVE
4. Review exploit code and requirements
5. Test in authorized environment

searchsploit — Command Line Access to Exploit DB

searchsploit is a command-line tool available in Kali Linux that provides offline access to the Exploit Database.

# Search for exploits related to OpenSSL Heartbleed
searchsploit heartbleed

# Search for Apache 2.2 exploits
searchsploit apache 2.2

# Search by CVE ID
searchsploit CVE-2014-0160

# Show the exploit file path
searchsploit -p 32764

# Copy exploit to current directory
searchsploit -m 32764

Combining CVE and Exploit DB in Practice

Step-by-Step Vulnerability Research Workflow:

1. Run a vulnerability scan (nmap -sV, OpenVAS, Nessus)
   └── Identify service versions on target

2. Look up identified versions in NVD
   └── Find applicable CVEs with CVSS scores

3. Prioritize by severity (focus Critical and High first)

4. Search Exploit DB for matching CVEs
   └── Determine if public exploit code exists

5. Assess exploitability in the target context
   └── Does the configuration match the exploit requirements?

6. Test in authorized scope and document findings

Other Vulnerability Resources

Responsible Disclosure

Vulnerability research and exploit code must be used responsibly:

• Only test systems you have explicit written authorization to test
• Follow responsible disclosure policies when reporting new vulnerabilities to vendors
• Do not publish exploit code for unpatched vulnerabilities before the vendor has had time to respond
• Use exploit code only in controlled, authorized environments — never against production systems without permission