From Vulnerability Discovery to Exploit Path Construction
A first durable articulation of the shift from vulnerability-centric workflows toward systems that identify capabilities, construct candidate paths, and validate them into working chains.
Findings first
Paths first
Most security workflows still behave as if the core job is to find vulnerabilities, classify them, rank them, and hope the important ones stand out on their own.
That frame remains useful, but it under-describes where impact actually comes from. The more important question is how well we can construct, test, and refine exploit paths from partial capabilities to meaningful outcomes.
An exploit path, as this project uses the term, is a sequence of capability transitions that transforms an initial system state into a materially different and security-relevant outcome.
The real signal is not just that models can emit something clever or that benchmark numbers move. The signal is that security work can be organized as a workflow that identifies approximate capabilities, composes candidate paths, validates them quickly, and iterates toward working chains.
Traditional security workflows are not wrong. They are incomplete.
The problem is not a lack of technique. The problem is that the compositional reasoning still sits between the tools, inside the heads of experts, or at the very end of the process where it shows up as a one-off exploit or a severity judgment.
A system can contain many weaknesses, but impact depends on how those weaknesses compose with configuration, deployment surfaces, and the validation loop available to the analyst or system. A bug that looks modest in isolation can become decisive inside a chain. A severe-sounding flaw can matter less than a smaller foothold that bridges into the right next state.
That is why findings still matter but cannot remain the final object of analysis. They describe what is wrong. They do not fully describe what becomes reachable because it is wrong.
A bug matters because it changes what becomes reachable.
That means the better unit of analysis is the path: an initial state, a capability transition, a new reachable state, another transition, and an eventual outcome.
Apache HTTP Server CVE-2021-41773 and CVE-2021-42013 provide a clean public case that grounds that shift. Path traversal and disclosure were not the end of the story, because the same route could survive toward remote code execution when the surrounding CGI surface was enabled.
This is not a claim that exploit chaining is new. Skilled researchers already think this way. The narrower and more important claim is that the field still publishes, organizes, and operationalizes too much of its work around isolated vulnerabilities instead of around explicit path construction and validation.
Once paths become the unit, the job changes. The goal is not only to identify weaknesses. It is to understand what each weakness enables, how those capabilities compose, what constraints remain, and which candidate routes survive contact with reality.
That path-oriented view requires a middle layer between raw weakness labels and final attacker outcomes.
That middle layer is where this project places primitive families, approximate capabilities, constraints, transition edges, and partial validation state.
Three distinctions need to stay explicit. Primitive family names the recurring capability category. Path role names what that capability is doing in the route. Outcome class names the state the route reaches if it survives validation.
A capability-oriented primitive layer is more useful than a flat list of weakness names because many different weaknesses collapse into similar path roles once exploit construction begins. That is usually much closer to what path reasoning actually cares about.
This framework does not start from nothing. Public prior work such as CWE chains and composites, CAPEC, attack graphs, ATT&CK, and Attack Flow already points toward structured multi-step reasoning. The difference here is the center of gravity: exploit-path construction and validation as the operational unit.
A useful way to read the middle layer is as working capability families rather than final taxonomic truth. The goal is not perfect naming. The goal is to make path construction computationally and organizationally possible.
An early version of this idea sounds neat: identify primitives, match patterns, build chains, generate PoCs. That is directionally right and still too clean.
The stronger model is convergence under imperfect structure.
Real primitives are partial. Real patterns collapse the search space without removing the need for revision. Real environments create near-misses constantly.
That is why validation is not a downstream check. It is the anchor of the whole system.
A useful public name for that process is the exploit path validation loop: identify approximate capabilities, construct candidate paths, validate quickly, prune weak routes, and keep the paths that survive.
A weak example is still useful here: a disclosure step that leaks configuration or credentials can amplify a later step; a timing-sensitive corruption step may fail repeatedly until the loop adapts. That is why the system has to search, reject, and retry rather than only compose clean symbols.
The most misleading way to understand this transition is through benchmark summaries or model mystique.
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.
The strongest interpretation of the current shift is not that a model has become magically smart enough in the abstract. It is that search, synthesis, validation, and refinement can be organized into a repeatable loop, and that more expertise can be encoded in representations, validation routines, and reusable path logic instead of remaining trapped in one-off intuition.
Security work shifts from counting findings toward exploring reachability.
The middle layer becomes strategically important. Teams that can represent primitive families, constraints, and transitions explicitly will be better positioned than teams that still rely entirely on fragmented tools and expert synthesis at the end.
Validation becomes a first-class discipline rather than an afterthought, and more expertise can be encoded in reusable structures instead of remaining trapped in one-off intuition.
The practical implication is straightforward: security workflows, tools, and research should invest less in isolated finding counts as the end state and more in explicit path reasoning, structured validation loops, and reusable models of how capability turns into consequence.
The primitive layer is grounded but not finished. Pattern families are not yet written down. Reliability, preconditions, and environmental variance still need more explicit representation. Additional public examples still need to be mapped beyond the first anchor.
Those are not reasons to wait. They are reasons to keep the first version honest about what it is: a framework draft, a workflow model, and a serious claim about where security is heading.
Three terms should stay separate.
- Primitive family. The recurring capability category, such as disclosure, reference control, authorization bypass, or sequencing manipulation.
- Path role. What that capability is doing in this route, such as foothold, leverage gain, boundary crossing, or execution step.
- Outcome class. The state the route reaches if it survives validation, such as disclosure, privileged action, cross-sphere movement, or execution.
CVE-2021-41773 / CVE-2021-42013
Apache HTTP Server 2.4.49 and 2.4.50 provide a clean public case that grounds why the weakness label is not the whole story. Path traversal and file disclosure became a route toward stronger outcomes when CGI execution surfaces were available.
- Primitive families. Reference control and disclosure are the recurring capability types the route exposes first.
- Path role. The route acts as a foothold that becomes leverage gain and then a boundary-crossing bridge into a stronger execution surface.
- Outcome class. The initial outcome is disclosure, but the higher-value surviving outcome can become execution when the environment permits it.
A simple way to read the thesis is through a modest example. A file-path control issue might first look like constrained file access. If that path exposes configuration or secrets, the result is no longer just disclosure. It becomes a transition into stronger control.
Apache HTTP Server 2.4.49 and 2.4.50 provide a clean public case that grounds why the weakness label is not the whole story. Path traversal and file disclosure became a route toward stronger outcomes when CGI execution surfaces were available.
That is the difference between counting a weakness and reasoning about a chain. The first gives you a label. The second gives you a route.
If the thesis lands, move into application, grounding, or shareable slices.
The thesis is the full written model. The next useful move depends on what you need next: the compressed workflow, the grounded public cases, or the shorter arguments that are easier to circulate.
Read the walkthrough
Use the shortest serious version of the workflow when you want the model in one pass without the full thesis pacing.
Open the walkthroughExplore the case pages
See the framework mapped onto real public cases so the actors, objects, transitions, and outcomes become legible.
Browse the casesRead the posts
Use the shorter pieces when you want narrower arguments that are easier to share, reference, or reuse independently.
Read the posts