In Module 01 you learned that a CVE is just an identifier, a case number. Now we open the case file. When you look up a CVE on the National Vulnerability Database, what you're looking at is a structured record. Every record has the same five parts in roughly the same order. Once you can read one, you can read all of them.

Below is what the record for CVE-2024-3094, the XZ Utils backdoor, looks like, stripped down. We'll go through each row in the sections that follow.

These five rows tell you everything you need: what happened, how bad, what kind of bug, what's affected, where to read more. That's the whole skill.

The description is one paragraph written by the CNA, the CVE Numbering Authority that assigned the ID. It is the official, primary record of what the vulnerability is. Every news article, every vendor advisory, every blog post about the bug starts from this paragraph.

Read it carefully. Descriptions are dense on purpose. A good one tells you: what software is affected, what the flaw is, and what an attacker can do with it.

Notice what's in there. What software: xz, specifically versions starting at 5.6.0. What the flaw is: malicious code hidden in the upstream package, activated during build. What an attacker can do: intercept and modify data going through liblzma. Because OpenSSH links against this library on many Linux systems, that means tampering with SSH authentication.

This particular bug has a story behind it. It was planted by an attacker who spent three years building credibility under the fake name Jia Tan, eventually becoming a trusted maintainer of xz. They were caught by accident when a Microsoft engineer noticed SSH logins on a test machine were running half a second slower than usual. The description above is the dry version. The real story is one of the best in modern security history.

Every analysed CVE has a CVSS score, Common Vulnerability Scoring System. It's a number from 0 to 10 that summarises how bad the flaw is. Bigger number, worse flaw. The XZ backdoor scored a perfect 10.0.

The score breaks into five bands. Each band has a name you'll see used everywhere: in ticketing systems, vendor advisories, client conversations. Memorise these.

Underneath the number sits a vector string, something like CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. That's a structured breakdown of why the score is what it is. It looks like nonsense right now. We'll unpack it properly in Module 03.

For now, you only need to know the bands. When a client asks "how bad is it," Critical, High, Medium, or Low is the answer. The exact decimal rarely matters in the first conversation.

One thing to flag now, before anyone gets carried away: CVSS measures technical severity. It doesn't know whether you run the affected software, whether the vulnerable code path is reachable in your setup, or whether your business cares about the system in question.

A CVSS 10.0 in software you don't run is a 0 to you. A CVSS 6.5 in your customer payment system is your whole afternoon. The score is a starting point, not a verdict.

Two rows of the record answer "what kind of bug is this, and which software does it affect". They look related but they are different things, and the difference matters.

So for the XZ backdoor: the weakness type is CWE-506 (Embedded Malicious Code: rare and dramatic; most bugs are unintentional). The affected products are exactly xz versions 5.6.0 and 5.6.1. Earlier versions are fine. Later versions are fine. Just those two.

Why both? CWE tells you what to understand. If you've learned CWE-89 once, every SQL injection CVE makes sense the moment you see the category. CPE tells you what to scan for: automated tools compare your software inventory against the CPE list to find matches.

The bottom of every CVE record is a list of links. This is where most interns stop reading. Don't be one of them. The references section is where the actual story lives: patches, vendor advisories, technical writeups, exploit details. Each link is tagged with what type of source it is.

Four reference tags you'll see most often:

Patch: links to the fix. First thing you check. If a Patch reference exists, the bug has an official remedy. If not, you might be looking at a zero-day or an unresponsive vendor.

Vendor Advisory: the official statement from whoever maintains the software. Microsoft, Red Hat, Cisco, the open-source project. Trust this over third-party writeups.

Third Party Advisory: a security researcher's or vendor's external writeup. Often more readable than the official version. Often more thorough.

Exploit: proof-of-concept code or technical exploitation detail. Not always present, sometimes deliberately withheld. When it's there, you read it. You don't run it against anything you don't own.

Three questions. They draw on everything above. If you get all three, you're ready for Module 03 (CVSS scoring). If you miss any, the result card tells you which section to re-read.