CVE vs CWE vs CAPEC: What's the Difference?

The Big Picture

If you have spent any time in cybersecurity, you have almost certainly seen the acronyms CVE, CWE, and CAPEC used — sometimes interchangeably, but they describe very different things. Understanding each one and how they relate helps you think more clearly about vulnerabilities, fix root causes, and communicate with security tools and compliance frameworks.

Here is the simplest possible summary:

• CVE — a specific vulnerability in a specific product. "This version of this software has this bug."
• CWE — a class of coding weakness. "This type of bug exists across many products."
• CAPEC — an attack technique. "This is how attackers exploit this type of weakness."

All three are maintained by MITRE Corporation under US government contracts. They form a layered security vocabulary used by government agencies, security tools, compliance frameworks, and vulnerability researchers worldwide.

CVE — Common Vulnerabilities and Exposures

A CVE is a unique, public identifier for a specific security vulnerability in a specific product or version. The format is CVE-YEAR-NUMBER, for example CVE-2021-44228 for Log4Shell.

CVE entries contain:

• A unique ID (e.g., CVE-2021-44228)
• A description of the vulnerability
• References to advisories, patches, and proof-of-concept exploits
• The CWE(s) that describe the underlying weakness

CVEs answer the question: "Is my software vulnerable to this specific known bug?"

CWE — Common Weakness Enumeration

A CWE describes a category of software or hardware weakness — the type of mistake in code or design that leads to vulnerabilities. CWEs are not tied to a specific product; they describe patterns that appear across thousands of CVEs.

Examples of widely referenced CWEs:

CWEs answer the question: "What class of coding mistake caused this vulnerability, and how do we prevent it in future code?"

MITRE organises CWEs in a hierarchy. At the top are abstract Pillars (like "Improper Input Validation"), then Classes, then Base weaknesses (specific enough to map to specific CVEs), then Variants (very specific conditions). The NVD typically maps CVEs to Base-level CWEs.

OWASP Top 10 and CWE

The OWASP Top 10 — the most-referenced web security risk list — maps directly to CWEs. For example, "A03: Injection" covers CWE-89 (SQL), CWE-77 (Command), and CWE-79 (XSS). This is why understanding CWEs makes OWASP compliance much easier to reason about.

CAPEC — Common Attack Pattern Enumeration and Classification

CAPEC (pronounced "cape-eck") describes how attackers exploit weaknesses. While CWE describes the flaw in the code, CAPEC describes the attacker's methodology and technique used to abuse it.

CAPEC entries include:

• Attack name and ID (e.g., CAPEC-66: SQL Injection)
• Likelihood of attack and typical severity
• Prerequisites (what the attacker needs)
• Step-by-step execution flow
• Example instances
• Mitigations and detection methods
• Related CWEs and ATT&CK techniques

Some examples of CAPEC entries:

CAPEC answers the question: "How would an attacker actually exploit this type of weakness, step by step?"

CAPEC is heavily used in threat modelling exercises, red team planning, and in frameworks like MITRE ATT&CK (which describes adversary tactics and techniques at an even higher level).

How CVE, CWE, and CAPEC Connect

The three systems form a chain from abstract attack technique down to a specific exploitable instance in production software.

For example:

• CAPEC-198 (XSS via HTTP Query Strings) describes the attack technique
• CWE-79 (Cross-site Scripting) describes the weakness in the code
• CVE-2023-XXXXX is a specific XSS vulnerability in a specific version of a specific web application

Security tools use these links in both directions. A SAST (static analysis) tool might flag CWE-79 in code — before any CVE exists. A vulnerability scanner might find CVE-2023-XXXXX — and then surface the CWE to help the developer understand the root cause. A threat modelling tool might start from CAPEC-86 and ask "which CWEs could enable this attack, and do we have any CVEs for those in our stack?"

Real-World Example: Log4Shell

Let's trace Log4Shell through all three frameworks to make this concrete.

A developer who understands only the CVE knows to patch Log4j. A developer who understands the CWE knows to never evaluate untrusted strings as expressions in any language or framework. A security architect who understands the CAPEC knows to look for similar injection points across all logging and input-processing code — not just Log4j.

Side-by-Side Comparison

Frequently Asked Questions