From Vulnerability Discovery to Exploit Path Construction

Security work is still commonly described as if the main job were to find vulnerabilities, classify them, rank them, and stop there. That framing remains useful, but it is no longer the strongest description of where high-leverage work is moving.

The more important question is increasingly this: how well can we construct, test, and refine exploit paths from partial capabilities to meaningful outcomes?

This paper argues that exploit path construction and validation, not isolated vulnerability discovery, should be treated as the primary unit of analysis for understanding and operationalizing security impact.

An exploit path, as this paper uses the term, is a sequence of capability transitions that transforms an initial system state into a materially different and security-relevant outcome.

This is not a claim that exploit chaining is new. Skilled practitioners have reasoned this way for a long time. The narrower claim is that the field still operationalizes too much of its work around isolated weaknesses, while the real differentiator is becoming path construction and validation.

Findings still matter. The problem is not that vulnerability-centric work is wrong. The problem is that it under-describes what actually determines impact.

A system can contain many weaknesses, but impact depends on how those weaknesses compose with each other, with configuration, with deployment surfaces, and with the validation loop available to the analyst or system. A severe-sounding flaw may matter less than a smaller foothold that bridges into the right next state. A modest-looking issue may become decisive when it exposes the capability needed for a later transition.

This is where many workflows break down. The compositional reasoning often sits between tools, inside the heads of experts, or at the tail end of the process where it appears as a one-off exploit or a severity judgment.

The framework uses a few terms that are easy to blur together if they are introduced only in prose.

Primitive family names a reusable capability category that abstracts away from specific weaknesses and focuses on what an attacker can do once the weakness is exploited.

Path role names the function that capability serves inside a path, such as foothold, leverage gain, boundary crossing, or execution trigger.

Outcome class names the resulting state if the path survives validation, such as disclosure, privileged action, or remote code execution.

These are not meant as final standards language. They are meant as a usable middle-layer vocabulary for reasoning about paths.

If the question is what becomes reachable, then the natural unit is the path.

A path can be read as an initial state, a capability transition, a new reachable state, another transition, and an eventual outcome.

This does not mean every path needs perfect formalization. It means the workflow should be organized around candidate paths and their survival under validation, not around isolated labels alone.

An issue is not fully described by what class it belongs to. It is better described by what it changes about the reachable state space and what new transitions that change enables.

Once paths become the unit, a middle layer becomes necessary.

That middle layer sits between raw weakness labels and final outcomes. It is where this project places primitive families, approximate capabilities, constraints, transition edges, and partial validation state.

The point of this layer is not taxonomic purity. The point is operational usefulness. A flat list of weakness names is often too close to discovery and too far from path construction.

Three distinctions matter here: primitive family names the recurring capability category, path role names what that capability is doing in the path, and outcome class names the state the path reaches if it survives validation.

That is why a working set such as disclosure, reference control, data influence, state corruption, execution influence, authorization bypass, sphere crossing, and sequencing manipulation is useful even before it is perfect. It externalizes reasoning that is often implicit.

A clean version of this story would say: identify primitives, match patterns, build chains, and generate proofs of concept. That version is directionally right and still too simple.

The stronger model is convergence under imperfect structure. Real capabilities are partial. Real environments produce near-misses. Real chains fail because of assumptions, missing preconditions, broken state, or configuration differences.

That means validation is not a downstream check. It is the anchor of the whole process.

The exploit path validation loop is closer to this: identify or infer approximate capabilities, construct candidate paths, validate quickly against the target environment, prune weak paths and revise stronger ones, and keep the paths that survive.

A normalized example used across this project starts with a file-path control issue that appears to provide constrained file access. In a findings-first frame, that may look limited. In a paths-first frame, the more important question is what the path exposes next.

If the same path reveals configuration, service credentials, or deployment secrets, the issue is no longer just a disclosure label. It becomes a leverage gain and a bridge into stronger control. If the path reaches a more privileged execution surface, the consequence changes again.

Apache HTTP Server CVE-2021-41773 and CVE-2021-42013 provide the cleanest public anchor for that logic. Path traversal and file disclosure were not the whole story. In environments where CGI execution was enabled and reachable through the exposed path, the same path could escalate from disclosure toward remote code execution because the exposed surface reached into a stronger execution context.

The weakness label is only the start of the analysis. The path is the thing that matters.

The most misleading way to describe the current moment is as model magic.

The more useful description is workflow industrialization: the systematic automation and scaling of search, synthesis, validation, and refinement across large codebases, environments, and attack surfaces.

That changes what good systems need to externalize. The important differentiators become how capabilities are represented, how candidate paths are ranked, how validation is executed, and how failures feed back into the next iteration.

This does not remove the need for expertise. It changes where that expertise lives. More of it can be encoded in representations, validation routines, and reusable path logic instead of remaining trapped in isolated intuition.

This framework does not start from nothing, and it does not replace every existing lens.

CWE provides structural descriptions of weaknesses, including chains and composites. CAPEC helps bridge weaknesses to recurring offensive behaviors. ATT&CK catalogs adversary behaviors. Attack Flow offers a way to represent multi-step offensive activity. Attack-graph research supports the reachability argument directly.

What is different here is the center of gravity. Rather than focusing on weakness classification alone or adversary behavior alone, this framework emphasizes capability-oriented primitives and validation-driven exploit path construction as the operational unit of analysis.

The novelty claim is intentionally limited. This paper does not claim to invent exploit chains. It claims that the middle layer between weakness labels and realized outcomes is strategically important, operationally under-specified, and worth making explicit.

This paper is best read as a conceptual and workflow-oriented foundation.

It is not a complete taxonomy, a formal graph model, a finished pattern library, or a full case-study archive.

Its narrower job is to make the unit shift durable, define the role of the middle layer, show why validation is central, and ground the framework in enough public material to be useful.

Future work should refine the primitive layer, expand the mapped example corpus, and build the starter primitive/path library deliberately instead of letting it leak into the first paper by accident.

Security impact is not determined by vulnerabilities in isolation, but by the paths they enable. As systems grow more complex and interconnected, the decisive question is no longer simply what weaknesses exist, but what becomes reachable because they exist.

That is the unit shift this paper makes explicit: from vulnerability discovery to exploit path construction and validation.

The middle layer matters because it gives that path a usable vocabulary. Primitive families, path roles, outcome classes, constraints, and transition logic make it possible to represent, test, and refine reasoning that would otherwise remain trapped in expert intuition.

This paper does not offer the final taxonomy or the final library. It offers the framing that makes those later artifacts worth building. The path, not the isolated finding, is the thing that ultimately matters.