CVE vs CWE vs CAPEC: What’s the Difference? Complete 2026 Guide

By Abdul Shakoor · SentrixHub

If you’ve spent any time in cybersecurity, you’ve seen the acronyms fly past: CVE, CWE, CAPEC, and their cousins CVSS and CPE. They look similar, they’re all maintained by overlapping organizations, and they all deal with “security problems” — so it’s completely natural to mix them up. Beginners do it constantly, and honestly, plenty of experienced people stay fuzzy on the exact boundaries too.

Here’s the simplest way to hold them apart before we go deep. Imagine a health system. A CWE is a type of disease (the general weakness). A CVE is a specific patient who caught that disease (one real, identified case). A CAPEC is the method a criminal uses to take advantage of the sickness. CVSS is the danger rating of how bad the case is. And CPE is the address telling you exactly which product and version is affected. Keep that picture in mind — we’ll return to it — and the whole taxonomy suddenly clicks.

This guide is the complete, bookmarkable reference on how CVE, CWE, and CAPEC differ, how they connect, and how real security teams use them every day. Let’s build it from the ground up.

What is a vulnerability? (the foundation concepts)

Before comparing the frameworks, you need a few core terms straight, because the frameworks exist precisely to organize these ideas.

A weakness is a flaw or mistake in software design or code — something done in a way that could cause a security problem. It’s a latent condition, not necessarily exploitable yet. A vulnerability is a specific, identified weakness in a specific product that an attacker actually could exploit. In other words, a weakness becomes a vulnerability when it shows up in real software as a concrete, exploitable hole.

An attack pattern is the reusable method an attacker uses to exploit weaknesses — the “how” of an attack, described generically enough to apply across many targets. An exploit is the actual code or technique that takes advantage of a specific vulnerability. A threat is the potential for harm (the attacker and their intent), while risk is the combination of how likely that harm is and how bad it would be. Finally, the attack surface is the sum of all the points where an attacker could try to get in.

Here’s the relationship in one sentence: a weakness in code becomes a vulnerability in a product, which an attacker exploits using an attack pattern, creating risk to the business. CWE, CVE, and CAPEC are simply the official catalogues for the first three of those ideas.

What is CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a dictionary of specific, publicly known security vulnerabilities — each one a real flaw found in a real product. When security professionals say “there’s a new CVE,” they mean a particular vulnerability has been identified, catalogued, and given a unique ID.

CVE is maintained by MITRE, a US non-profit, with funding and support from CISA (the Cybersecurity and Infrastructure Security Agency). The program began in 1999 to solve a messy problem: before CVE, every vendor and tool described the same vulnerability differently, so nobody could tell if they were talking about the same issue. CVE gave the world one shared name for each vulnerability.

A CVE ID looks like CVE-2021-44228 — the letters “CVE,” the year it was assigned, and a unique number. That famous example is Log4Shell, the critical flaw in the Log4j logging library. Each CVE record includes the identifier, a short description of the vulnerability, references to advisories and patches, and details about affected products.

The lifecycle runs roughly like this: someone discovers a potential vulnerability, it’s reported to a CNA (CVE Numbering Authority — organizations authorized to assign CVE IDs, such as major vendors), a CVE ID is reserved, and once details are confirmed the record is published. From there, the National Vulnerability Database (NVD), run by NIST, enriches the CVE with a severity score, weakness mapping, and affected-product data. This is the difference that trips people up: CVE identifies which specific vulnerability exists; it doesn’t tell you the underlying flaw type or how severe it is on its own.

What is CWE?

CWE stands for Common Weakness Enumeration. If CVE is the catalogue of specific cases, CWE is the catalogue of types — the underlying categories of weakness that cause vulnerabilities in the first place. It’s also maintained by MITRE.

A CWE describes a root cause: a kind of coding or design mistake that keeps producing vulnerabilities. For example, CWE-79 is Cross-Site Scripting, CWE-89 is SQL Injection, CWE-434 is Unrestricted Upload of File with Dangerous Type, and CWE-787 is Out-of-bounds Write. Notice these aren’t specific products or incidents — they’re classes of flaw that appear again and again across all software.

CWE is organized into categories and views (different ways of slicing the list — by development concern, by research concept, and so on), which lets different audiences navigate the same data. MITRE also publishes the well-known CWE Top 25 Most Dangerous Software Weaknesses, a regularly updated ranking of the weaknesses causing the most real-world damage. That understanding of root causes is exactly what secure-development standards build on — the file-handling weakness behind an unrestricted file upload vulnerability, for instance, maps directly to CWE-434.

The key point: CWE tells you what kind of flaw something is — the root cause — not any single real-world instance of it.

What is CAPEC?

CAPEC stands for Common Attack Pattern Enumeration and Classification. Where CWE describes the weakness (the defender’s and developer’s view), CAPEC describes the attack — the reusable method an attacker uses to exploit those weaknesses. It, too, is a MITRE project.

An attack pattern captures how an adversary behaves: the goal, the steps, the prerequisites, and the weaknesses it targets. For example, CAPEC-66 is SQL Injection (the attack technique), and CAPEC-63 is Cross-Site Scripting as an attack. Each CAPEC entry describes the execution flow — how the attack unfolds — and links to the CWEs it typically exploits, giving you a bridge between attacker behaviour and underlying weakness.

CAPEC is the attacker’s-eye catalogue. It’s used heavily in threat modeling, penetration testing, and red-teaming, because it answers the question defenders most need to anticipate: how would someone actually come after this? The same attacker mindset drives tools and techniques like Frida hooking in mobile testing, where understanding the attack method is the whole point.

The key point: CAPEC describes the attacker’s method — the “how” — not the weakness itself and not any specific vulnerability.

The biggest comparison table: CVE vs CWE vs CAPEC

Here’s the side-by-side that ties the three together. Bookmark this table — it answers most of the confusion in one glance.

Aspect	CWE	CVE	CAPEC
Full name	Common Weakness Enumeration	Common Vulnerabilities and Exposures	Common Attack Pattern Enumeration and Classification
Represents	A type of weakness (root cause)	A specific real vulnerability	An attacker’s method
Answers	What kind of flaw is it?	Which exact vulnerability exists?	How would an attacker exploit it?
Maintained by	MITRE	MITRE (with CISA)	MITRE
Focus	The weakness / root cause	The instance / case	The attack technique
Primary audience	Developers, security architects	Everyone: defenders, vendors, scanners	Pentesters, threat modelers, red teams
ID format	CWE-79	CVE-2021-44228	CAPEC-66
Example	Cross-Site Scripting (CWE-79)	Log4Shell (CVE-2021-44228)	SQL Injection attack (CAPEC-66)
Severity built in?	No (uses CVSS separately)	No (NVD adds CVSS)	No (qualitative likelihood)
Analogy	The disease type	The specific patient	The criminal’s method

The one-line memory version: CWE is the weakness, CVE is the instance, CAPEC is the attack. Everything else follows from that.

Watch: CVE, CWE & CAPEC Explained

If a visual explanation helps, the video above walks through how CVE, CWE, and CAPEC differ and connect. It’s a useful companion to the comparison table above — seeing the relationship explained aloud makes the distinctions stick.

How they connect: the relationship chain

These frameworks aren’t rivals — they’re links in a single chain that runs from a coding mistake all the way to business impact. Understanding the flow is more valuable than memorizing definitions.

The chain reads: Weakness (CWE) → becomes a Vulnerability (CVE) in a product → described by severity (CVSS) → located in a specific product/version (CPE) → exploited via an Attack Pattern (CAPEC) → resulting in Impact.

Here it is as a simple diagram:

Each framework covers one link. CWE is the root cause, CVE is the concrete case, CVSS rates it, CPE pinpoints where it lives, and CAPEC explains how it gets attacked. Miss one and you have a blind spot in your vulnerability management.

CVE vs CWE

This is the most common confusion of all. CWE is the weakness type; CVE is a specific instance of that weakness in real software.

Take a concrete example. CWE-89 (SQL Injection) is the general weakness — the class of mistake where untrusted input reaches a database query. A specific product that ships with that flaw gets its own CVE ID. So one CWE (SQL Injection) can be the root cause of thousands of different CVEs across thousands of products. The CWE is the reusable “why”; each CVE is a real “where and when.”

Put simply: you fix a CVE by patching a specific product; you prevent whole families of future CVEs by addressing the underlying CWE in how you build software. This is why secure-coding practices target CWEs, while patch management targets CVEs.

CWE vs CAPEC

These two are close cousins and often linked directly in MITRE’s data. The difference is perspective. CWE is the defender’s/developer’s view — the weakness. CAPEC is the attacker’s view — the method used against that weakness.

For SQL Injection, CWE-89 describes the flaw (input isn’t sanitized before hitting the database), while CAPEC-66 describes the attack (how an adversary crafts malicious input to exploit it). They’re two sides of the same coin: one says “here’s the hole,” the other says “here’s how someone climbs through it.” Threat modelers move constantly between the two — starting from a weakness and asking which attack patterns apply, or starting from an attack pattern and asking which weaknesses it needs.

CVE vs CAPEC

CVE is a specific vulnerability; CAPEC is a generic attack method. A CVE is tied to one product and one flaw. A CAPEC is abstract and reusable — the same attack pattern (say, SQL Injection) applies to countless CVEs across the software world. You could think of CVE as a single unlocked door in one building, and CAPEC as the burglar’s general technique for getting through unlocked doors anywhere.

CVE vs CWE vs CVSS

People lump these together, but they answer three different questions. CVE identifies the vulnerability. CWE classifies its underlying weakness. CVSS scores its severity.

CVSS (Common Vulnerability Scoring System), maintained by FIRST, produces a number from 0.0 to 10.0 that expresses how severe a vulnerability is, based on factors like how easily it’s exploited and how much damage it causes. So for a single CVE, you’ll typically see all three: the CVE ID (which vulnerability), a CWE mapping (what kind of weakness), and a CVSS score (how bad). Prioritization lives here — teams triage which CVEs to patch first largely by CVSS severity, refined by real-world exploitation data. The exact-wording precision of a CVSS score matters, which is why getting it right (and not mis-citing it) is something we’ve stressed when explaining individual CVEs like CVE-2026-4020.

CVE vs CWE vs CPE

CPE (Common Platform Enumeration) is the piece most beginners have never heard of, but it’s essential. If CVE tells you which vulnerability, CPE tells you exactly which products and versions are affected. It’s a structured naming scheme for software, hardware, and operating systems.

Here’s how it all comes together inside the NVD: NIST takes a CVE, adds a CVSS score (severity), maps it to one or more CWE entries (weakness type), and lists the affected products as CPE strings (where it lives). That’s why the NVD is so powerful — it’s the hub that links the identifier (CVE), the root cause (CWE), the severity (CVSS), and the affected products (CPE) into one enriched record. A vulnerability scanner uses the CPE data to figure out whether your specific software versions match a known CVE.

Vulnerability vs weakness

This is the plain-English version of CVE vs CWE, and it’s worth stating clearly because the words get used interchangeably in casual conversation. A weakness is a flaw that might cause a problem — a mistake in code or design (that’s CWE territory). A vulnerability is a weakness that is actually present and exploitable in a specific product (that’s CVE territory).

Analogy: a weakness is “leaving windows unlocked is a bad habit” (a general flaw). A vulnerability is “the window on the third floor of this building is unlocked right now” (a specific, exploitable instance). Every vulnerability stems from a weakness, but a weakness only becomes a vulnerability when it appears, exploitable, in real software. Weak choices around credentials, for example — the kind we cover in dangerous passwords — are weaknesses that turn into concrete vulnerabilities the moment they ship in a product.

Real example walkthrough: Log4Shell end to end

Abstract definitions only go so far, so let’s trace one real, well-documented vulnerability through every framework. We’ll use Log4Shell, one of the most significant vulnerabilities of the modern era.

• CVE: CVE-2021-44228 — the specific vulnerability in the Apache Log4j library.
• CWE: It maps primarily to weaknesses around unsafe deserialization and injection of untrusted input (the root-cause type of flaw). This is the “what kind” answer.
• CVSS: It received the maximum severity score of 10.0 (Critical) — reflecting how trivially it could be exploited and how devastating the impact was. This is the “how bad” answer.
• CPE: The affected products were expressed as CPE strings identifying the specific vulnerable versions of Apache Log4j. This is the “exactly where” answer.
• CAPEC: The attacker behavior — crafting malicious input that the logging library processes and turns into remote code execution — aligns with injection-style attack patterns. This is the “how it’s attacked” answer.
• Impact & mitigation: Because Log4j was embedded in countless applications, the business risk was enormous. Mitigation meant upgrading to a patched Log4j version, and detection involved scanning for vulnerable versions (via CPE matching) and watching for exploitation attempts.

See how each framework answered exactly one question? CVE named it, CWE classified it, CVSS scored it, CPE located it, and CAPEC explained the attack. That’s the whole taxonomy working as designed on a single real case.

The complete workflow: from code to defence

Here’s how these pieces appear naturally across a vulnerability’s entire life, from the developer’s first mistake to the SOC’s final detection.

A developer, under deadline pressure, introduces a weakness (CWE) — say, unsensitized input handling. The product ships. Later, a security researcher finds that the weakness is exploitable and reports it. A CVE is assigned to name the specific vulnerability. The NVD enriches it: a CVSS score rates its severity, it’s mapped to the relevant CWE, and affected versions are listed as CPE strings. Meanwhile, CAPEC describes how attackers would exploit this class of flaw, feeding threat models and pentests. The vendor releases a patch, defenders prioritize it by CVSS and exploitation data, and the SOC builds detection for exploitation attempts. Risk drops.

Every acronym in this guide has a job in that story — and none of them can do another’s job. That’s the entire point of keeping them distinct.

Real-world enterprise workflow

In a mature security program, these frameworks are wired into tooling. A vulnerability scanner matches your assets’ CPE data against known CVEs to tell you what you’re exposed to. Those findings are prioritized by CVSS severity, sharpened with threat intelligence and the CISA KEV (Known Exploited Vulnerabilities) Catalog, which flags CVEs that are actually being exploited in the wild — a powerful prioritization signal. Runtime protections such as a RASP tool can block exploitation attempts against known weaknesses while patches are rolled out.

CWE data guides secure-coding fixes so the same weakness doesn’t reappear, feeding back into the secure SDLC. CAPEC informs threat modeling and red-team exercises. Findings flow into the SIEM and EDR for detection, into patch management for remediation, and into compliance reporting for auditors. The frameworks that felt academic at the start turn out to be the connective tissue of day-to-day security operations — the same operational discipline behind sound API security and firewall practice.

The MITRE ecosystem (and where NIST and CISA fit)

MITRE runs an interconnected family of standards, and seeing the whole map helps enormously.

• CVE — specific vulnerabilities.
• CWE — underlying weakness types.
• CAPEC — attack patterns that exploit weaknesses.
• ATT&CK — real-world adversary tactics and techniques observed in actual campaigns (broader attacker behaviour, post-exploitation included).
• D3FEND — defensive countermeasures, mapping defences to attacker techniques.

They interlock: CWE (weakness) connects to CAPEC (how it’s attacked), which connects to ATT&CK (what adversaries actually do), while D3FEND describes how to defend. Alongside MITRE, NIST runs the NVD (enriching CVEs with CVSS, CWE, and CPE), FIRST maintains CVSS, and CISA supports CVE and publishes the KEV Catalog. Together they form the shared language of global vulnerability management — and standards like OWASP ASVS build on these same weakness classifications to define what secure software should verify.

Common misconceptions (cleared up)

A few myths cause most of the confusion. Let’s correct them directly.

“A CVE means a vulnerability.” Close, but imprecise. A CVE is the identifier for a specific, publicly disclosed vulnerability — the name and record, not the flaw type or its severity. The vulnerability exists in the software; the CVE is how we refer to it.

“CWE is an exploit.” No. A CWE is a weakness type — a root-cause category. It’s not code, not an attack, and not a specific incident. It’s the classification of the underlying mistake.

“CAPEC is malware.” No. CAPEC is a catalogue of attack patterns — generic methods attackers use. Malware is a tool an attacker might deploy; CAPEC describes techniques and behaviors, not specific malicious software.

“Every CVE has a CWE.” Not always. Most CVEs in the NVD are mapped to at least one CWE, but some lack a clear or assigned mapping, especially newly published ones. The link is common and valuable, but not guaranteed.

“CVSS and CVE are the same thing.” No. CVE names the vulnerability; CVSS scores its severity. One is an identifier, the other is a rating.

Beginner cheat sheet

Keep this near you until it’s second nature.

Acronym	Stands for	One-word role	Example	Analogy
CWE	Common Weakness Enumeration	Weakness type	CWE-89 (SQL Injection)	The disease
CVE	Common Vulnerabilities and Exposures	Specific vulnerability	CVE-2021-44228	The patient
CAPEC	Common Attack Pattern Enumeration & Classification	Attack method	CAPEC-66 (SQLi attack)	The criminal’s method
CVSS	Common Vulnerability Scoring System	Severity score	9.8 Critical	The danger rating
CPE	Common Platform Enumeration	Affected product/version	cpe:/a:apache:log4j	The address

The memory trick that makes it stick

If you remember nothing else, remember this health-and-crime story:

• CWE = the Disease — the type of illness (the weakness).
• CVE = the Patient — a specific person who caught it (the real vulnerability).
• CAPEC = the Criminal’s Method — how a bad actor takes advantage.
• CVSS = the Danger Rating — how serious this case is.
• CPE = the Address — exactly which building (product/version) is affected.

“The disease (CWE) infected a patient (CVE), whose danger level (CVSS) was rated at a specific address (CPE), and a criminal used a known method (CAPEC) to attack.” One sentence, five frameworks, permanently sorted.

Frequently asked questions

Conclusion

CVE, CWE, and CAPEC aren’t competing standards — they’re complementary pieces of one system. CWE is the weakness (the root cause), CVE is the specific vulnerability (the real case), and CAPEC is the attack pattern (the method). Add CVSS to rate severity and CPE to pinpoint affected products, and you have the complete language modern security teams use to find, prioritize, and fix security problems.

The practical takeaway: don’t just memorize the definitions — learn the chain. A weakness becomes a vulnerability, which is scored, located, and attacked, producing risk. Once you see how each framework answers exactly one question in that story, the acronyms stop being confusing and start being genuinely useful. Bookmark the cheat sheet, keep the disease-and-patient analogy in your back pocket, and you’ll never mix them up again.

If you’re building security knowledge from here, a natural next step is to see these concepts in action on real, documented vulnerabilities — which is exactly what our CVE breakdowns and secure-development guides are for.