Mapping the Email Threat Taxonomy

TL;DR

• I mapped all 125 entries of the email threat taxonomy to STRIDE, to CAPEC 3.9 and to CWE 4.20, and checked every CAPEC and CWE ID against MITRE’s published data.
• 31 entries (25%) have a CAPEC attack pattern that describes them directly. 65 have only a generic parent pattern, and 29 have nothing at all.
• STRIDE fits 75 entries cleanly. For the other 50 (40%) it gives a label but not a question anyone would ask in a review.
• The protocol layers (SMTP, MIME, DNS, client protocols) are well covered. The gaps are in content scanners, the delivery pipeline, operations and the structural hazards: the places where email’s risk comes from how components are composed, not from any one protocol.
• CWE does much better: 68 entries (54%) have a weakness that names the flaw, and only six have none. Of the 24 entries STRIDE and CAPEC both miss, only three escape CWE too. But a weakness catalogue names a flaw once you have found it; it doesn’t help you find it.
• That is the case for a domain taxonomy: STRIDE, CAPEC and CWE tell you what kind of thing went wrong; they don’t tell you where to look in a mail flow.

Introduction

In The Unmodeled Attack Surface I made a claim: apply STRIDE to email infrastructure and it will surface something, but it won’t surface the threats in the taxonomy. A claim like that deserves evidence, so here it is.

Back in 2022 I published a mapping of MITRE’s Common Attack Pattern Enumeration and Classification (CAPEC) to the STRIDE categories, and updated it to CAPEC 3.9 for my book. This post runs the same exercise in the other direction. I took every one of the 125 entries in the email threat taxonomy and asked three questions:

1. Which STRIDE categories does it belong to, and does STRIDE fit cleanly? A clean fit means a facilitator holding a STRIDE prompt would plausibly ask the question that finds this threat. A loose fit means a category can be assigned, but only after you already know the threat is there.
2. Is there a CAPEC attack pattern for it? Direct means a CAPEC entry describes this attack or a near-exact analogue. Partial means only a generic parent pattern applies. None means CAPEC has nothing that would lead you to it.
3. Is there a CWE weakness for it? Direct means a weakness in MITRE’s Common Weakness Enumeration (CWE) names the flaw the entry describes, at the Base or Variant level MITRE recommends for mapping, or a Class that is exactly this flaw and that MITRE allows for mapping. Partial means only a broader or adjacent weakness applies. None means no CWE weakness names it.

Every CAPEC ID below was checked against MITRE’s published CAPEC 3.9 data (the STIX bundle in MITRE’s CTI repository), and every CWE ID against the CWE 4.20 release of 30 April 2026, so each ID exists, none is deprecated, and the name is MITRE’s own. The CWE choices also follow MITRE’s guidance on mapping to CWE: nothing MITRE marks as prohibited for mapping, and the entries it discourages only for a Partial match. For CAPEC and CWE, the rating applies to the entry’s list as a whole, and the IDs are in best-fit order, so for a Direct match the first ID names the flaw. The fit ratings are my judgement, and I’d welcome challenges to any of them.

Note to threat modelers: the point of this post is not that STRIDE, CAPEC and CWE are bad. I have spent years building on all three. The point is that they are general-purpose, and a domain like email needs a domain map as well.

What the mapping shows

Across all 125 entries, 31 have a CAPEC pattern that describes them directly, 65 have only a generic parent such as Functionality Bypass or Exploiting Multiple Input Interpretation Layers, and 29 have no pattern at all. STRIDE fits 75 entries cleanly and 50 loosely. Twenty-four entries get both a loose STRIDE fit and no CAPEC pattern; those are the ones a general-purpose session is least likely to find. CWE names the flaw directly for 68, gives only a broader or adjacent weakness for 51, and has nothing for six. Of the twenty-four entries STRIDE and CAPEC both miss, CWE names five directly and 16 only broadly; just three are missed by every framework.

STRIDE fit, CAPEC 3.9 match and CWE 4.20 match for each of the nine layers and the structural hazards, with the number of entries per row that STRIDE and CAPEC both miss, and how many of those CWE misses too. Client protocols, SMTP, MIME and DNS have the most direct CAPEC patterns, five or six each; the three outlined layers, the delivery pipeline, content scanners and operations, have one or two each, and operations stays mostly grey even for CWE.

The split by layer is the interesting part. The protocol layers (MIME, DNS, SMTP and client protocols) map well: their attacks are old, well studied and catalogued. The layers that map worst are the ones that didn’t exist when those catalogues were written, or that aren’t protocols at all:

• Content scanners. Seven of 13 entries have no CAPEC pattern. CAPEC 3.9 has nothing for prompt injection, classifier evasion or classifier poisoning, and nothing for a scanner that a sample can fingerprint and behave benignly for. CWE has caught up with some of this: Improper Neutralization of Input Used for LLM Prompting (CWE-1427) names scanner prompt injection, and Inadequate Detection or Handling of Adversarial Input Perturbations in Automated Recognition Mechanism (CWE-1039) names classifier evasion. Classifier poisoning still has no weakness at all.
• Delivery pipeline and structural hazards. STRIDE fits only loosely for eight of the 13 pipeline entries and for all eight structural hazards. A fail-open scanner or an inherited verdict can be labelled Elevation of Privilege, but no STRIDE prompt makes you ask about scanner timeouts or hop ordering. CWE does better on the pipeline, where Not Failing Securely (CWE-636) names fail-open scanning and Unprotected Alternate Channel (CWE-420) names the unscanned path. For the structural hazards it has only two direct matches: Use of Less Trusted Source (CWE-348) for envelope and header duality, and Interpretation Conflict (CWE-436) for the interpretation differential.
• Operations and storage. Mostly partial matches to Privilege Abuse or Collect Data from Common Resource Locations, which tell you nothing about archives, backups or search indexes as second copies of the mailbox. CWE is not much better here: 10 of the 13 entries get only a broader weakness, such as Improper Protection of Alternate Path (CWE-424) for the archive and Exposure of Backup File to an Unauthorized Control Sphere (CWE-530) for backups, neither of which says that the copy lives under a different access model and outlives remediation.
• DNS, the other way round. CAPEC describes MX redirection and cached policy poisoning directly; CWE has no weakness for either, because the flaw is in records and caches the platform depends on, not in the platform’s own code. The three frameworks don’t fail in the same places, which is one more reason to treat them as labels rather than as a method.

Note to facilitators: if you run STRIDE on an email platform, add the delivery pipeline, content scanner and operations layers of the taxonomy as an explicit second pass. That is where STRIDE alone leaves you blind.

Where CWE fits

At first glance CWE closes most of the gap. 68 entries have a weakness that names the flaw, against 31 with a matching attack pattern, and only six have nothing at all. If you stopped at the counts, you would conclude that the general frameworks have email covered after all.

They don’t, and the reason is in what CWE is. STRIDE prompts you with categories of threat and CAPEC describes attacks; CWE is a catalogue of weaknesses, the mistakes in software and design that attacks exploit. It answers “what do we call this flaw?”, not “where should we look?”. Three things in the mapping show the difference:

• A few weaknesses carry a lot of entries. The mapping uses 100 different weaknesses, but five of the most cited, User Interface (UI) Misrepresentation of Critical Information (CWE-451), Not Failing Securely (CWE-636), Interpretation Conflict (CWE-436), Improper Protection of Alternate Path (CWE-424) and Reliance on Untrusted Inputs in a Security Decision (CWE-807), appear against 41 of the 125 entries. CWE-451 fits a spoofed display name, a hijacked thread and an assistant that relays a lure in the platform’s own voice equally well. It is the right label for all three, and a question for none of them.
• The match comes after the find. Every Direct CWE in the tables was chosen by someone who already knew the threat. Nobody walks a mail flow through more than 900 weaknesses; you walk it layer by layer, and then you reach for the CWE to label what you found.
• What all three miss has the same shape. The three entries that STRIDE, CAPEC and CWE all miss, Remediation Race, Signing Failure Outage and Legitimate Mutation, are about copies, outages and legitimate behaviour rather than a flaw in one component: a retraction that the synced copies have already escaped, a signing failure that makes every record unresolvable, and the rewriting that forwarders and gateways are allowed to do. CWE has nothing for them because nothing is wrong with any single piece of software.

That is where CWE earns its place: on the finding, not in the session. Use the taxonomy to decide where to look, STRIDE to frame the question, and CWE, with CAPEC where there is a pattern, to label what you find, so that a finding from a threat modeling session lines up with scanner output, CVE records and your issue tracker.

Note to AppSec teams: if your findings already carry CWE IDs from your scanners, tag threat modeling findings the same way. It is the cheapest way to see where design review and tooling overlap, and where only one of them is looking.

The full mapping

STRIDE letters are listed with the best fit first, and CAPEC patterns and CWE weaknesses in best-fit order. Each table gives every entry’s STRIDE categories and fit, and its CAPEC patterns and CWE weaknesses by ID and name. A loose STRIDE fit together with a CAPEC match of None marks the entries a general-purpose session is least likely to find; a CWE match of None means there is not even a weakness to file the finding under. The same tables are on each layer’s page in the taxonomy, and the Excel, SKOS and STIX downloads carry the mapping as text you can search and filter.

1. Delivery pipeline

2. Authentication protocols

3. Client protocols

4. SMTP

5. MIME and S/MIME

6. DNS layer

7. Content scanners

8. Human-facing layer

9. Operations and storage

Structural hazards

Table: STRIDE, CAPEC and CWE mapping for Structural hazards (T), 8 hazards, with each entry’s STRIDE categories and fit, CAPEC 3.9 patterns and CWE 4.20 weaknesses. The full mapping is in the Excel, SKOS and STIX downloads on the email infrastructure taxonomy overview page.](images/email-mapping-table-10-T.png)

Final thoughts

STRIDE and CAPEC hold up well on the protocols. If your threat model stops at “can someone spoof the sender, tamper with the message or flood the server”, you will find most of the SMTP and DNS entries. That is not where the interesting failures are.

The entries STRIDE and CAPEC both miss share a shape. They are about how components are composed (a hop that trusts another hop’s verdict, a scanner that fails open, a second copy of the mailbox with its own access model), about time (a verdict that decays, a remediation that races the sync), and about the new machinery we have bolted on (classifiers, LLM assistants, prompt injection). None of those is a property of a single protocol, so none of them shows up when you walk a protocol through STRIDE.

CWE changes the labels, not the conclusion. It can name the flaw behind more than half the entries, and that matters when a finding has to sit next to a scanner result or a CVE. But it names the flaw after you have found it, and a handful of weaknesses stretch to cover dozens of very different threats. The question of where to look is still open.

That is the argument for a domain taxonomy, and for card games built on one. A general framework tells you what kind of thing went wrong. A domain map tells you where to look.

If you think I have rated a fit too harshly or too kindly, or know a CAPEC pattern or a CWE weakness I missed, tell me on LinkedIn and I’ll update the mapping.

Stay tuned!

References

• The Unmodeled Attack Surface: A Threat Taxonomy for Email Infrastructure (update to the post’s URL once published)
• Email Infrastructure Threat Taxonomy, with a page per layer and the full mapping in the Excel, SKOS and STIX downloads
• CAPEC-STRIDE Mapping
• MITRE CAPEC 3.9, from the STIX 2.1 bundle in the MITRE CTI repository (capec/2.1/stix-capec.json), used to verify every CAPEC ID and name in this post
• MITRE CWE 4.20 (30 April 2026), from the JSON release in the CWE-CAPEC REST API working group repository, used to verify every CWE ID and name in this post
• MITRE’s guidance on mapping to CWE, which sets out which entries may be used for mapping