The Unit Shift

Most security work is still narrated as if the main job were to find vulnerabilities, classify them, and stop there. That frame is still useful, but it is no longer the strongest way to understand where real impact comes from.

The more important question is not just, "what bugs exist?" It is, "what becomes reachable once a weakness changes the state of the system?"

That is the unit shift at the center of Exploit Paths. The claim is not that vulnerability discovery stops mattering. The claim is that isolated findings are often too small and too static to explain meaningful consequence on their own. A weakness matters because it changes what an attacker can do next, what state becomes reachable, and what stronger outcomes become plausible if the route survives validation.

If you want the broader version of that argument, read the thesis or the longer paper. This module gives you the compact lesson version: why the field's default unit is often too narrow, and why paths are the better frame.

An exploit chain and an exploit path are close enough to blur together if you are not careful.

An exploit chain usually describes a sequence: one issue leads to another, then to an outcome. That is useful, but it still tends to focus on the visible linked events.

An exploit path, as this project uses the term, is a sequence of capability transitions that transforms an initial state into a materially different and security-relevant outcome. That wording matters for two reasons.

First, it moves the focus away from raw vulnerability labels and toward what each step actually enables. Second, it treats the route as something that has to survive constraints, preconditions, and validation rather than as a tidy story assembled after the fact.

That is why this project keeps separate language for findings, capabilities, paths, and outcomes. Later modules will make that middle layer more explicit. For now, the important point is simple: a finding tells you something is there; an exploit path helps you reason about what becomes possible because it is there.

If you want the workflow version of that move, the walkthrough compresses the same logic into the operating loop.

Reachability is the center of this shift.

A flaw may sound severe and still fail to matter much in practice if it does not bridge into anything important. A flaw that looks modest in isolation can become decisive when it exposes the exact capability needed for a later step. That is why severity language and issue counts often under-describe real impact.

What matters is not only whether a weakness exists, but what it makes reachable:

• a new file or object
• a credential or secret
• a more privileged execution surface
• a boundary crossing
• a stronger final outcome

This is why compositional reasoning matters. Modern systems rarely fail in one dramatic step. They fail because one partial capability survives long enough to connect with the next one.

The public literature already points in this direction. MITRE's CWE chains and composites work and the NIST attack-graph prior both reinforce the same underlying point: system consequence cannot be understood well by examining isolated issues one at a time.

Module 1 does not need you to master that literature. It needs you to internalize the practical implication: the right question is increasingly what becomes reachable, not just what weakness label was assigned.

Use the following starter example as the concrete version of the shift.

Imagine a file-path control issue that initially looks like constrained file access. In a findings-first frame, that may be treated as a disclosure bug, triaged mostly by severity label, and left there.

In a paths-first frame, the next question is different: what can that access reach?

If the same route reveals configuration, service credentials, deployment secrets, or references to more privileged assets, the consequence changes. The issue is no longer just "a disclosure." It becomes a leverage gain and possibly a bridge into a stronger outcome.

That is the move this course wants you to get comfortable making:

• start with the weakness
• identify the capability it creates
• ask what new state becomes reachable
• ask what stronger transition that new state enables

The grounded cases library shows public examples of that same structural move in the wild. For a clean supporting case, see Apache HTTP Server: path traversal to execution. You do not need to memorize the cases yet. You only need to see that exploit-path reasoning is a way to make consequence legible before you are staring at a finished exploit.

Choose a public CVE and analyze it through the exploit-path lens instead of the findings-first lens.

Use this sequence:

1. summarize the vulnerability briefly
2. identify the capability the issue appears to create
3. ask what becomes reachable because of that capability
4. sketch a candidate path from initial state to stronger outcome
5. explain why the path tells you more than the vulnerability label alone

Keep the exercise constrained. The goal is not to prove a full exploit. The goal is to practice the unit shift.

Suggested deliverable shape:

• Vulnerability summary
• Initial capability
• Reachable state or states
• Candidate exploit path
• Potential outcome
• Unit-shift reflection

If you want a clean external grounding source for the weakness side of the exercise, start with CVE.org, NVD, and relevant vendor advisories.

By the end of this module, you should be able to explain:

• why vulnerability discovery alone is not a strong enough frame for understanding impact
• what an exploit path adds beyond a raw finding list
• why reachability is the better question
• why consequence emerges from composition, not just classification
• why later modules need a middle layer instead of jumping directly from weaknesses to outcomes

If those points are still fuzzy, reread the thesis or the paper before moving on.

Module 2 introduces primitive families.

That next lesson matters because once you accept that paths are the right unit, you need a better language for describing what different weaknesses actually enable. Raw weakness labels are too close to discovery and too far from path construction. Primitive families are the first layer of that bridge.

Continue to Module 2 when you are ready.

This module borrows from adjacent public work on weakness composition and multi-step reachability, then pushes the argument toward exploit paths as a workflow and validation unit.

• MITRE CWE chains and composites
• NIST attack-graph prior
• Apache HTTP Server vulnerabilities 2.4
• CISA alert on Apache HTTP Server