Primitive Families

Module 1 argued that isolated findings are too small a unit for understanding real consequence. Module 2 answers the obvious next question: if you do not want to stay at the weakness-label layer, what do you use instead?

The problem is not that CVEs and CWEs are useless. The problem is that they describe flaws at a level that is often too close to discovery and too far from exploit-path construction.

Different weaknesses can give an attacker the same practical leverage. A path traversal issue and a mis-scoped file reference bug may both change what files become reachable. A SQL injection and a template injection may both change what data or execution surface the attacker can influence. If you reason only in raw weakness labels, those structural similarities stay buried.

That is why this project introduces primitive families. They reduce diverse weaknesses into reusable capability categories so the next stages of path construction become easier to reason about.

If Module 1 gave you the category shift, this module gives you the first working tool.

A primitive family is a recurring capability category derived from exploiting a weakness in a real environment.

The important part of that definition is capability. A primitive family is not mainly another label for the weakness. It is a way of answering a more useful question: what can the attacker do once this issue is real?

That shift matters because exploit-path work is not built out of weakness names alone. It is built out of usable transitions:

• read something that should not be readable
• control a reference that should not be attacker-controlled
• influence data that later logic trusts
• affect execution that should stay outside attacker reach

Primitive families are the first layer of the middle layer described in the paper. They let you collapse many specific issues into a smaller number of reusable building blocks without pretending every environment is identical.

This is why the current starter set in Exploit Paths is intentionally practical rather than final: disclosure, reference control, data influence, state corruption, execution influence, authorization bypass, sphere crossing, and sequencing manipulation.

The goal is not taxonomic purity. The goal is a useful reduction step that helps the learner move from findings to paths.

Three layers are easy to blur if you do not separate them explicitly.

A weakness is the underlying flaw or class of flaw.

A primitive is the capability that flaw creates once exploited in context.

A technique is the attack behavior or method used as part of a route.

That distinction matters because these layers answer different questions:

• weakness: what is wrong?
• primitive: what can the attacker now do?
• technique: how might that capability be used in practice?

One reason this module exists is to keep the course from collapsing into taxonomy confusion later. If a learner treats weakness labels, capability abstractions, and attack techniques as interchangeable, the rest of the middle layer becomes much harder to use cleanly.

Primitive families are abstractions, not magic reductions.

A capability is only real to the degree that the environment makes it real. File disclosure depends on what paths are actually reachable. Execution influence depends on what interpreters, handlers, or execution surfaces are present. Authorization bypass only matters if there is a boundary worth bypassing and a route that reaches it.

That is why primitive families should not be taught as if they erase context. They organize reasoning, but they do not replace validation.

The right mental model is:

• the weakness gives you a clue
• the primitive family gives you a reusable capability hypothesis
• the environment tells you whether that hypothesis survives

This is also why the primitive layer helps the course move forward without forcing Module 2 to do Module 5's job. You do not need the full validation loop yet. You only need to understand that capability abstraction is useful precisely because the same family can recur across different weaknesses while still depending on concrete conditions.

Use Apache HTTP Server as the clean mapping example for this module.

The visible weakness is path traversal. At the weakness-label layer, that is already useful information. But by itself it does not yet tell you the best reusable way to reason about what the issue enables.

The stronger reduction is:

• weakness: path traversal
• primitive family: reference control
• immediate capability: attacker-influenced access outside intended file boundaries

That is a better working abstraction because it helps explain why the same route can later support more than one outcome. If the route only exposes files, the path may stay at disclosure. If the same route reaches CGI-enabled behavior, it can survive toward execution.

That is exactly why primitive families matter. They let you preserve what is structurally useful about the issue without pretending the original weakness label is the whole story.

For the full grounded case, see Apache HTTP Server: path traversal to execution.

Choose three public CVEs and normalize each one into a primitive family.

Use this sequence:

1. summarize the vulnerability briefly
2. identify the likely underlying weakness or CWE
3. describe what capability the issue creates if exploitation succeeds
4. map that capability to the best-fit primitive family
5. list the environmental preconditions that make the capability real
6. describe the strongest plausible outcomes that primitive might support

The goal is not to build a full exploit path yet. The goal is to practice the reduction step that turns raw findings into reusable building blocks.

Suggested deliverable shape:

• CVE
• Likely weakness or CWE
• Capability created
• Primitive family
• Preconditions
• Potential outcomes
• Justification

If you do this well, you should start to notice that very different-looking issues often collapse into the same capability family once you stop staring only at the weakness label.

Double check that you can now:

• explain why raw weakness labels are not enough for path construction
• define a primitive family as a capability abstraction rather than a weakness synonym
• distinguish weakness, primitive, and technique cleanly
• account for environmental preconditions when assigning a primitive family
• take a real CVE and map it into a reusable capability category

If those moves still feel fuzzy, reread Module 1, then compare this lesson against the middle-layer sections of the paper.

Module 3 introduces path roles and outcome classes.

That matters because primitive families tell you what kind of capability you have, but not yet what job that capability is doing in a route or what state the route ultimately reaches. The next lesson separates those layers so the model stays reusable instead of collapsing into one overloaded vocabulary.

Continue to Module 3 when you are ready.

This module borrows from public work on weakness structure, vulnerability theory, and reusable attack behavior, then pushes the argument toward capability normalization as a working step in exploit-path construction.

• MITRE CWE chains and composites
• MITRE CWE research concepts view
• MITRE introduction to vulnerability theory
• CAPEC