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 is still useful, but it is no longer the main thing. The more important question is how well we can construct, test, and refine exploit paths from partial capabilities to meaningful outcomes.
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 they compose. 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.
A bug matters because it changes what becomes reachable.
Apache HTTP Server CVE-2021-41773 and CVE-2021-42013 made that visible in public: path traversal and disclosure were not the end of the story, because the same route could become remote code execution when the surrounding CGI surface was enabled.
That means the better unit of analysis is the path: an initial state, a capability transition, a new state, another transition, and an eventual outcome.
This is not a claim that exploit chaining is new. Skilled researchers already think this way. The point is that the field still publishes, organizes, and operationalizes work around isolated vulnerabilities more than around explicit path construction.
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.
Primitive family, path role, and outcome class should be kept distinct. Primitive family names the capability type. 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 produce similar consequences, and those consequences are often closer to what exploit construction actually cares about.
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 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 important change is workflow design: how a system represents capabilities, path roles, and likely outcomes, then proposes and prunes candidate paths, validates outputs, and learns from failure.
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 over large codebases and attack surfaces.
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 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 example of 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 example of 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.