CVE and Vulnerability Databases

Once you know what is probably running on a target, the next question is simple to ask and sometimes hard to answer: is there a known weakness in it? Public vulnerability databases exist to answer exactly that question, in a shared, structured language. In this lesson you will learn to read and use them correctly.

Chapter 2 gave you a documented, honest map of Lighthouse Labs: hosts, ports, likely services, and a confidence level for each. Chapter 3 turns that map into a prioritised list of hypotheses to verify, starting with the most structured public resource available: CVE records.

What CVE means

CVE stands for Common Vulnerabilities and Exposures. It is a system of unique identifiers, such as CVE-2023-12345, each one describing one specific, publicly known weakness in a specific piece of software. The CVE system is coordinated through cve.org, and its records are mirrored and enriched with severity scores by the National Vulnerability Database (NVD), maintained by NIST.

The purpose of CVE is to give everyone, researchers, vendors, and defenders, a shared name for the same weakness, instead of everyone describing it differently. When you tell a client "your service is affected by CVE-2023-12345", that single identifier lets them look up an authoritative, independent description, a severity score and, usually, a vendor fix.

Anatomy of a CVE record

A typical entry in the NVD includes:

• Identifier: the unique CVE number.
• Description: a short, technical summary of the weakness and the affected software.
• Affected versions: which versions of which product are concerned, which is exactly why a confirmed, accurate version number from your reconnaissance phase matters so much.
• Severity score: most records include a CVSS (Common Vulnerability Scoring System) score, usually from 0 to 10, summarising how severe the weakness is in typical conditions.
• References: links to the vendor's own advisory, patches, and sometimes further technical analysis.

Understanding CVSS without memorising formulas

CVSS scores compress several factors into one number: how easy the weakness is to exploit (for example, does it require network access or physical access, does it require the attacker to already have an account), and what impact a successful exploitation has (on confidentiality, integrity, availability). As a rough guide, scores below 4 are usually considered low severity, 4 to 7 medium, 7 to 9 high, and above 9 critical, but a professional always reads the actual description rather than relying on the number alone, since a "high" score in a context the client does not actually expose might matter less than a "medium" score in a context that is directly reachable from the internet.

Searching a database responsibly

Searching the NVD or CVE.org for a product name and a version is normal, public, and legitimate professional research. A few habits make it more reliable:

• Search by product name and the version range from your reconnaissance notes, not by guessed version numbers.
• Read the full description, not only the title, since two records can sound similar but affect very different configurations.
• Check the publication date against what you know about the software's update history: a weakness patched years ago in a version far older than what you observed is unlikely to be relevant.
• Note every candidate CVE you find, even the ones you later discard, together with the reason you discarded them. This protects you if the client later asks "did you check for X?"

From a CVE list to a hypothesis list

Finding a matching CVE record is not the end of the work; it is a hypothesis, exactly like a banner was a hypothesis in the previous chapter. A record that matches a product and version range is a strong candidate, but the only way to be sure is to verify it against the actual target, which is the topic of the rest of this chapter and the exploitation chapter that follows. Never write "the target is vulnerable to CVE-2023-12345" in a report purely because a version number matched; write "the target's reported version appears to be in the affected range for CVE-2023-12345, which [was / was not] confirmed by direct testing".

Other useful public references

Beyond CVE and the NVD, a few other public resources complement vulnerability analysis:

• OWASP (owasp.org), already familiar from the previous course, maintains lists such as the OWASP Top 10 describing the most common categories of web application weaknesses, useful to frame findings even when no specific CVE applies.
• MITRE ATT&CK (attack.mitre.org) catalogues techniques attackers use once inside a system, which is more useful for later chapters but worth knowing about now.

Your fil rouge: building a candidate list for Lighthouse Labs

Using the table you produced at the end of chapter 2, pick two or three of your fictional lab services and, playing the role of a researcher, write down what kind of CVE search you would run for each (product name, version range), what you would look for in the description, and how you would decide whether to keep it as a candidate. Since Lighthouse Labs is fictional, you will not find a real matching CVE, and that is fine: the goal here is to practise the process of searching and judging a record, which you can apply for real, carefully and only within scope, in any future professional engagement.

Your turn: judge two findings

You find two CVE records that might apply to a target's web server, based only on the version string from its banner.

1. Record A: published recently, affects a narrow version range that matches your banner exactly, CVSS score 8.9, description matches the exposed feature on your target.
2. Record B: published several years ago, affects a broad historical version range that loosely includes your banner's reported version, CVSS score 9.5, description concerns a feature you have not observed on the target at all.

Which one deserves more attention first, and why? What would you do before writing either one into your report as confirmed?

See a solution

Record A deserves more attention first, despite its lower score, because it matches both the version and the actually observed feature, making it a precise, plausible hypothesis. Record B has a higher score but a vague match and an unobserved feature, making it a weak hypothesis that is more likely a false positive from version guessing. In both cases, nothing should be written as "confirmed" until it has been tested directly against the target, in the authorised scope, which is exactly what the exploitation chapter will cover.

Searching databases by hand does not scale to a whole network. Next, you will see how automated vulnerability scanners do a similar job, much faster, and what their limits are.