MITRE CAPEC Guide: Attack Patterns, CWE Links and Using CAPEC in Design Reviews

Application teams know their weaknesses as CWE entries and their attackers as ATT&CK techniques, but threat modelling, test planning and developer training need the layer in between: how an attacker actually exploits a class of weakness. MITRE's Common Attack Pattern Enumeration and Classification (CAPEC) is that layer, a public catalogue of attack patterns such as SQL Injection (CAPEC-66), Cross-Site Scripting (CAPEC-63) and Credential Stuffing (CAPEC-600), each linked to the CWE weaknesses it exploits and, where relevant, to ATT&CK techniques. This guide explains how CAPEC is structured, how it differs from ATT&CK and CWE, how to use it in threat modelling, security requirements and penetration test scoping, and what its limits are, including the fact that the list has not been updated since version 3.9 in January 2023. It is for application security engineers, threat modellers, testers and security architects; it builds on the CWE Top 25 Guide rather than repeating it.

Key takeaways

• CAPEC describes how, CWE describes what. A CWE entry is a weakness in code or design; a CAPEC entry is the attacker's method for exploiting one or more such weaknesses, with prerequisites, skills, consequences and mitigations.
• Use the abstraction levels deliberately. Meta patterns (61 in version 3.9) suit architecture-level threat modelling; Standard (181) and Detailed (317) patterns suit test cases and code review.
• CAPEC complements ATT&CK rather than competing with it. MITRE describes CAPEC as focused on application security and ATT&CK as focused on network defence, and the two cross-reference each other.
• Most entries are still Draft. Of the 615 attack pattern objects in the 3.9 STIX release, 402 are marked Draft and only 154 Stable, so treat details as guidance, not specification.
• Check the mappings against current ATT&CK. Some ATT&CK references in CAPEC 3.9 point at techniques that ATT&CK v20 has since revoked, such as the old Impair Defenses sub-techniques.

What CAPEC is and where it came from

CAPEC's own site describes it as a "publicly available catalog of common attack patterns" that helps users understand how adversaries exploit weaknesses. It was established by the U.S. Department of Homeland Security as part of its Software Assurance strategic initiative and first released in 2007. MITRE maintains it alongside CWE.

• Current version: CAPEC List Version 3.9, released on 24 January 2023, and still the latest release on the CAPEC news page when checked on 27 October 2026.
• Size: the 3.9 STIX 2.1 release published in MITRE's CTI repository contains 615 attack pattern objects, of which 559 are not deprecated, plus 877 course-of-action (mitigation) objects linked to them by 1,172 relationships.
• Formats: the website, XML and CSV downloads on capec.mitre.org, and STIX 2.1 in the mitre/cti GitHub repository, which is the easiest format for tooling.
• Licence and cost: free to use, which is why many threat modelling tools and testing frameworks embed it.

How an attack pattern entry is structured

Every entry follows the same schema, which is what makes CAPEC useful for repeatable work. Taking CAPEC-66 SQL Injection as the example:

Abstraction levels in practice

• Meta: broad methods such as CAPEC-112 Brute Force, CAPEC-94 Adversary in the Middle (AiTM), CAPEC-122 Privilege Abuse and CAPEC-21 Exploitation of Trusted Identifiers. Use them when the design is still a diagram.
• Standard: a specific technique, such as CAPEC-66 SQL Injection, CAPEC-62 Cross Site Request Forgery, CAPEC-664 Server Side Request Forgery or CAPEC-593 Session Hijacking. Use them for security requirements and test plans.
• Detailed: a pattern for a specific technology or variant. Use them for code review checklists and targeted tests.

How CAPEC relates to CWE, ATT&CK and CVE

MITRE's comparison page says CAPEC is "focused on application security", describing the techniques adversaries use to exploit known weaknesses, while ATT&CK is "focused on network defense", describing the operational phases of an intrusion before and after exploitation. It also notes that many CAPEC patterns are carried out through specific ATT&CK techniques and that the two efforts cross-reference each other.

In the 3.9 data, 450 of the 559 non-deprecated patterns reference at least one CWE and 177 reference at least one ATT&CK technique. The ATT&CK links cluster in credential, session and social engineering patterns, for example:

Injection and client-side patterns such as SQL Injection and XSS have no ATT&CK mapping in CAPEC; at the intrusion level they generally surface as T1190 Exploit Public-Facing Application. See the CVE, CWE and CPE Guide and the MITRE ATT&CK Guide for Defenders.

Navigating the catalogue

• Mechanisms of Attack view (view 1000): groups patterns by the technique used. Its top-level categories include Collect and Analyze Information (118), Inject Unexpected Items, Engage in Deceptive Interactions, Manipulate Timing and State, Abuse Existing Functionality, Employ Probabilistic Techniques, Subvert Access Control (225), Manipulate Data Structures and Manipulate System Resources.
• Domains of Attack view (view 3000): groups patterns by what is attacked. In the 3.9 data the non-deprecated patterns split into Software (345), Communications (93), Social Engineering (60), Supply Chain (41), Physical Security (15) and Hardware (4).
• From a weakness: CWE entries list related attack patterns, so a SAST finding can be traced to the CAPEC patterns that exploit it and from there to test cases.
• From an ATT&CK technique: ATT&CK technique pages cite CAPEC IDs where a mapping exists, which helps red teams turn an adversary technique into application-level test ideas.
• From your own findings: start with the CWE entries that recur in your SAST, DAST and penetration test results (the CWE Top 25 is a reasonable external benchmark), pull the CAPEC patterns linked to each, and check whether your threat models, requirements and tests cover them. This turns a list of past mistakes into a forward-looking test plan.
• Programmatically: load the STIX bundle, filter out deprecated entries, and index by abstraction, domain and related CWE; that is how most tools present CAPEC inside threat models.

Using CAPEC in threat modelling and requirements

CAPEC does not replace a threat modelling method such as STRIDE; it supplies concrete attacks for each threat category so models are less dependent on the modeller's memory. See the Threat Modelling Guide.

1. Model the system: draw data flows, trust boundaries and the identities that cross them, including service accounts, API keys and tokens.
2. Select candidate patterns: for each element, shortlist Meta and Standard patterns from the relevant domains (Software and Communications for most web systems; Social Engineering for support and help desk flows; Supply Chain for build and dependency paths).
3. Filter by prerequisites: discard patterns whose prerequisites cannot hold in this design, and record why. This step is what makes the output defensible to reviewers.
4. Rate in context: use CAPEC's likelihood and severity only as a starting point; rate against your own exposure, data and controls.
5. Turn patterns into requirements: write each surviving pattern as a security requirement or abuse case, for example "the API rejects replayed session tokens (CAPEC-593)". See the Security Requirements and Abuse Cases Guide.
6. Link verification: map each requirement to an OWASP ASVS 5.0 requirement or a test case so it is checked before release. See the OWASP ASVS Guide.
7. Revisit on change: new trust boundaries, new identity types or new third-party integrations trigger a fresh pattern selection for the changed elements.

Choosing a level for the job

Small teams and large programmes

A small team can get most of the value from a curated list of 30 to 50 Standard patterns relevant to its stack, used as a checklist in design reviews and penetration test scopes. A large programme should embed CAPEC in its threat modelling tool, link it to SAST and DAST findings through CWE, and report coverage by domain and mechanism across the application portfolio.

Using CAPEC in testing, training and measurement

• Penetration test scoping: list the CAPEC patterns in scope and ask testers to report results against them, which exposes untested areas. See the Penetration Test Scoping Checklist.
• Finding classification: tag each finding with CWE (the weakness) and CAPEC (the attack used), which separates design problems from coding problems in trend reports.
• Developer training: MITRE lists developer training and education as a CAPEC use case; teach the Standard patterns that match your recurring CWE findings. See the Developer Security Training Programme Guide.
• Bug bounty triage: classify reports by CAPEC pattern to see which attack classes external researchers find that internal testing misses.

Metrics

• Threat model coverage: percentage of in-scope applications with a current threat model that records CAPEC patterns considered and discarded.
• Requirement traceability: share of selected patterns with a linked requirement and a passing test.
• Test coverage: CAPEC patterns in scope versus patterns actually exercised in the last penetration test.
• Recurrence: repeat findings per CAPEC pattern per quarter, which shows whether training and guardrails work.
• Escape rate: production incidents or bounty reports whose pattern was in the threat model but not tested.

Where identity fits

Many of the most used patterns are identity attacks: CAPEC-600 Credential Stuffing, CAPEC-560 Use of Known Domain Credentials, CAPEC-593 Session Hijacking, CAPEC-196 Session Credential Falsification through Forging and CAPEC-21 Exploitation of Trusted Identifiers. In threat models, apply them to non-human identities as well as users: API keys in clients, service-to-service tokens, CI credentials and agent identities are trusted identifiers too. See the OWASP NHI Top 10 NHI4 Insecure Authentication Guide.

Framework mapping

Common failure patterns

• Using CAPEC as a checklist without prerequisites: teams list hundreds of patterns, rate none of them in context and produce a threat model nobody reads. Filter by prerequisites first.
• Trusting stale cross-references: CAPEC 3.9 still references eight Impair Defenses sub-techniques and the DLL Side-Loading sub-technique, all of which ATT&CK v20 has revoked. Check every ATT&CK ID against the current release before putting it in a report.
• Treating ratings as risk scores: CAPEC's likelihood and severity are generic and are missing for many entries (214 non-deprecated entries have no likelihood rating). They are not a substitute for your own risk assessment.
• Stopping at the weakness: fixing a CWE finding without asking which CAPEC patterns exploit it misses sibling attacks. In the McKinsey Lilli platform exposure, values were parameterised but JSON field names were concatenated into SQL on an unauthenticated endpoint; a review against CAPEC-66 and its prerequisites, rather than a single "use parameters" rule, would have covered the field names too.
• Ignoring the missing domains: CAPEC predates agentic AI and has little on prompt injection or model abuse. Pair it with MITRE ATLAS and the OWASP LLM Top 10 for AI systems. See the MITRE ATLAS Guide.
• Assuming the list is current: with no release since January 2023, new attack classes will not appear; track the CAPEC news page and supplement from ATT&CK, ATLAS and OWASP.

Practitioner checklist

• Load the CAPEC 3.9 STIX bundle into your threat modelling or test tooling and filter out deprecated entries.
• Build a curated list of Standard patterns for your main technology stacks.
• Record in every threat model which patterns were considered, which were discarded and why.
• Write a security requirement or abuse case for each pattern that survives, linked to an ASVS requirement or test.
• Tag penetration test and SAST findings with both CWE and CAPEC.
• Validate every CAPEC to ATT&CK reference against the current ATT&CK release before reporting it.
• Apply identity patterns to service accounts, API keys and agent identities, not only to users.
• Supplement CAPEC with ATLAS and OWASP LLM guidance for AI systems, and check the CAPEC news page for new releases.

Standards and references

• MITRE CAPEC: About CAPEC
• MITRE CAPEC: ATT&CK and CAPEC comparison
• MITRE CAPEC: News and releases
• MITRE CAPEC: SQL Injection (CAPEC-66)
• MITRE CAPEC: Mechanisms of Attack view (1000)
• MITRE: Cyber Threat Intelligence repository (CAPEC STIX 2.1)
• MITRE: Common Weakness Enumeration
• OWASP: Application Security Verification Standard 5.0

Related NHI Mgmt Group resources: CWE Top 25 Guide · Threat Modelling Guide · MITRE ATT&CK Guide for Defenders · Penetration Testing Guide · Secure Code Review Guide