A scanner finds three issues on a customer-facing app and rates them Low to Medium. An unauthenticated endpoint that leaks sequential user IDs. An insecure direct object reference (IDOR) on the account recovery page. A password-reset endpoint that accepts a token without binding it to the intended user or session. Patch them whenever the dashboard says. No weekend escalation.
Now read them in order. The leaked IDs tell you which accounts exist. The IDOR exposes an active password-reset token belonging to another user. The reset endpoint accepts that token without binding it to the requesting session, so you set a new password and walk into the account. Point it at a privileged user, and you are reading customer records. Three low-to-medium findings, one critical outcome, and nothing in the severity column saw it coming.
That sequence is vulnerability chaining, and it explains why isolated severity scores often fail to represent real attack impact. Here is how chaining works, why severity scores miss it, and how agentic pentesting tests each link until it either proves the full path or rejects it.
Vulnerability chaining is the practice of using multiple weaknesses in sequence so that each one enables the next, producing an impact that no single weakness could deliver on its own. The first flaw gives you a foothold or a piece of information. The second uses what the first produced. By the end of the chain, a set of findings that looked minor in isolation has carried an attacker to something that matters.
Chaining vulnerabilities like this breaks the way most teams measure risk. Security programs score findings individually and patch the worst ones first. A chain ignores that ranking, because it can run entirely through Low and Medium findings and still end at customer data.
This is also where chaining gets confused with a handful of related ideas that sound interchangeable and are not.
These four terms get used as synonyms, and that is a problem, because each one answers a different question. Getting them straight changes what your team measures and what a pentest report is allowed to claim.
| Concept | What it is | The question it answers |
|---|---|---|
| Vulnerability chaining | Using multiple weaknesses in sequence so combined impact exceeds any single flaw | How do small bugs become a big breach? |
| Attack path analysis | Identifying possible routes from an entry condition to a target asset or outcome | Where could an attacker go from here? |
| Attack graph | A model of entities, relationships, permissions, reachability, and possible transitions | What is connected to what, and who can become whom? |
| Exploit chain | A sequence of validated exploitation steps that achieves a defined objective | Did this work, end to end? |
The distinction that carries the most weight is the last one. Attack path analysis and attack graphs deal in what is possible. An exploit chain is what was proven. You can map a thousand possible paths through a graph and still not know whether any of them work.
Here is the line worth keeping in your head for the rest of this: scanners report findings, attack-path analysis connects possible relationships, and agentic pentesting tests whether those relationships can be turned into a working sequence of actions.
CVSS is designed to score the characteristics of an individual vulnerability. It does not calculate the combined impact of several findings used in sequence against a specific environment.
A CVSS score describes one finding in isolation: its attack vector, complexity, the privileges it needs, the impact if exploited. Each dimension stops at the boundary of that finding. Several moderate weaknesses can still combine into a critical outcome when each one enables the next step, and a per-finding score has no way to represent that relationship.
This is not a flaw in CVSS, and severity-per-finding is useful. The mistake is treating the severity column as a risk ranking. Risk depends on reachable outcomes, and reachability is a property of how findings connect. EPSS and CISA KEV add exploit likelihood, but they also score findings one at a time. None of them answer the question a chain raises: can someone get from here to something you care about?
A finding becomes a link in a chain only when it meets four conditions. Miss any one and you have two unrelated bugs, not a path.
First, the result of one step has to enable the next. An information leak that exposes user IDs is only a leak until those IDs are the exact input some other flaw requires.
Second, something has to carry forward: access, identity, reachability, or data. The output of step one becomes the fuel for step two, whether that is a token you captured, a network position you reached, or a record you read.
Third, every transition has to be technically valid. Not plausible, not "an attacker could probably." The step either works against the target as it runs, or it does not belong in the chain.
Fourth, the final outcome has to be demonstrated, not assumed. A chain that ends with "and from here an attacker would likely reach the database" is not finished. It ends when the database is reached, or when it is shown that it cannot be.
Those four conditions are also a test for any attack path someone hands you. If a step cannot show what it carried forward, or cannot prove the transition worked, the chain has a gap.
Three patterns show up often enough to be worth walking through. None depends on an exotic zero-day. They are combinations of ordinary findings.
Start with an unauthenticated endpoint that returns predictable user identifiers, the kind of sequential integer ID that tells you account 1001 exists, and so does 1002. On its own, an enumeration issue. Low.
Next, an IDOR on the account recovery flow. Supply one of those IDs and the endpoint returns an active password-reset token belonging to another user. Medium, in isolation.
Then the reset endpoint, which accepts that token without binding it to the requesting session. The leaked ID picked the target, the IDOR handed over the token, and the reset endpoint let you set a new password on an account that is not yours. Point that at a privileged customer account and you can read sensitive records. The business impact lives in the combination. Each finding alone would sit in the backlog for a quarter.
Server-side request forgery in a public web tier is a familiar starting point, and the SSRF-to-metadata chain is in every cloud security article for a reason. The version worth writing is the one that explains why each step works and admits where it can stop.
The web app makes server-side requests to a user-supplied URL with no allowlist, so it can be steered at the instance metadata endpoint. That endpoint is reachable because the workload sits on a host whose metadata service was not locked down. It returns temporary credentials tied to the instance role.
Now the question that decides whether this is a breach or a near-miss: what can that role do? This is where you resolve effective permissions, not attached policies. A role can carry a permissive-looking policy and still be boxed in by a permission boundary or an SCP. You check whether the role can read the target storage directly, and whether it can assume a more privileged role to get there. If effective access resolves to the sensitive bucket, the chain completes and you have proven a path from a public web flaw to customer data.
If it does not, the chain stops, and that result is worth recording, because rejecting this path cleanly is as valuable as completing it.
An externally reachable service with a known CVE gives initial access to a low-privilege host. That is the foothold. From there, a connection string sitting in a local config file hands over a service account credential, and that credential becomes the thing that carries forward.
The service account reaches a database host that the first machine could talk to but that was not exposed externally. Lateral movement, enabled by the network position the foothold provided plus the secret it leaked. On that host, the same service account is reused against a second internal system that trusts it, and the chain ends with read and write access to production customer records.
The pattern across all three: the entry point is rarely the prize. The prize is what the entry point lets you carry forward.
Agentic pentesting, sometimes grouped under the broader AI pentesting category, goes beyond listing isolated weaknesses. It runs a reasoning loop that mirrors how a tester builds a chain:
The part that makes this different from running more scanners is the second step. Context has to survive the jump between tests. A scanner that finds the SSRF and a scanner that audits IAM produce two reports. An agent that captures the credential from the SSRF and then asks what that specific credential can reach is testing the chain, because the output of one test became the input to the next.
Skilled human testers are excellent at building exploit chains, often better than any tool at the creative leaps. The limitation is not capability, it is repeatability and coverage across large, frequently changing environments under fixed engagement timelines. Agentic pentesting extends that work by preserving context, testing more branches, and repeating the process across supported assets as the environment changes.
The scope of the machinery depends on the surface. For web and API targets, Strobes runs a WSTG-aligned workflow in which findings are reported only after the system validates exploitability with evidence. For cloud, the work runs against a relationship graph that resolves effective access and role-assumption transitively, which is what lets the SSRF chain above answer "what can this role reach" instead of guessing from attached policies. Those are different mechanisms for different surfaces, not one universal engine.
Testing chains means taking real actions, so the boundaries matter as much as the capability. Use these as evaluation criteria: the questions to ask of any agentic pentest, and the controls a buyer should require.
| Safety question | Required control |
|---|---|
| How much data is accessed? | The minimum evidence needed to validate a transition. Reaching a target proves the path, without copying its contents beyond what is needed as evidence. |
| Are state-changing actions permitted? | Only within approved scope, or after explicit human approval. |
| How are credentials and evidence handled? | Encrypted storage, controlled access, limited retention. |
| When does testing stop? | At the agreed proof threshold or a predefined safety boundary. |
For the longer version of this argument, the question of what counts as valid proof in an agentic pentest deserves its own treatment, and the agentic pentesting complete guide goes deeper on the validation model.
Correlation says these findings might be related. Exploitation says they were used in order to reach a verified outcome. That gap is the value of a pentest.
Plenty of tools correlate, clustering findings by asset, trust boundary, or shared dependency and drawing lines between them. It is useful for triage and hard to do well. It is also not proof. A graph showing that an SSRF and an over-permissive role sit on the same workload tells you a path might exist. It does not tell you the SSRF can reach the metadata endpoint, that the credentials come back usable, or that the role effective access lands on anything worth reaching.
The agentic approach earns the word proven by walking the correlation and validating each edge. Where a correlation tool stops at "related," the test continues to "I captured this credential, resolved its effective access, and read this object."
That difference is easier to manage when every path carries an explicit status:
| Path status | Meaning |
|---|---|
| Hypothesized | A possible route based on relationships |
| Partially validated | Some steps succeeded, but the objective was not reached |
| Proven | Every required transition succeeded and the outcome was demonstrated |
| Rejected | A specific control or technical condition stopped the sequence |
| Not tested | Validation was outside the approved scope |
A pentest that only reports successful breaches is doing half the job, and the missing half is what makes it trustworthy. The central question is whether a chain can be proven or rejected, and rejection is a real outcome, not a failure to find something.
A hypothesized chain gets recorded as not exploitable for concrete reasons:
Take the cloud example from earlier. The SSRF reaches the metadata service and returns a credential, but the role that credential carries lacks any access to sensitive storage, and it cannot assume one that does. The right outcome is to record that path as partially validated, the SSRF and metadata access are real, and report it honestly rather than dressing it up as a proven breach path.
That distinction is what makes a report something a security team can act on. A tool that can tell you a control worked is more credible than one that only ever tells you it failed.
A report that claims a proven attack path has to show its work at every step. At minimum it should contain:
That last item is the one engineering teams use most. A chain with seven steps does not need seven fixes. It needs the one or two that, once closed, make the rest unreachable.
Once you are working from proven paths instead of a severity-sorted list, remediation priority changes shape. You stop asking which finding has the highest CVSS and start asking which fix breaks the most paths to assets that matter.
A Low-severity finding that enables several validated paths to sensitive assets may deserve higher priority than a standalone High-severity issue with limited reachable impact. Severity-first triage cannot make that call, because it does not know which findings are connected.
This is choke-point analysis. Map the proven chains, find the transitions that appear across several of them, and fix those first, since one control change at a shared transition can close multiple paths at once. It is the same logic that drives risk-based vulnerability management and continuous threat exposure management: prioritize by reachable impact, not by score in a vacuum. If you are evaluating tooling for this, the comparison of AI pentesting tools covers which platforms validate chains versus which stop at correlation, and automated pentesting covers how continuous testing keeps proven paths current as the environment shifts.
Pull your last pentest report or scanner export and find three Low or Medium findings on the same asset. Ask one question of them: does the output of any one create the input for another? If the answer is yes on even one pair, you have a chain your severity column never flagged.
Run an agentic pentest against one application to see which findings can be connected into validated attack paths and where existing controls stop the sequence. The result is a report with validated findings, evidence for each transition, the paths that were rejected, and the remediation breakpoints that collapse the most chains.
Start with one application
Run an agentic pentest and see which findings connect into validated attack paths, and where your controls break the sequence.
Validated findings, evidence per transition, rejected paths, and remediation breakpoints.
Vulnerability chaining is using several weaknesses in sequence so that each one enables the next, producing an impact larger than any single finding. A chain can run entirely through Low and Medium findings yet end at a critical outcome like account takeover, because the risk lives in the order the findings are used.
Each low-severity finding produces something the next step needs: information, access, a credential, or a network position. The output of one becomes the input to the next until the combination reaches an asset that matters. An ID leak feeds an IDOR, which feeds a weak reset flow, which ends in account takeover.
Vulnerability chaining is using weaknesses in sequence to increase impact. Attack path analysis identifies possible routes from an entry point to a target. Path analysis maps what could happen; an exploit chain is a specific sequence that has been validated step by step rather than only mapped as possible.
CVSS is designed to score the characteristics of an individual vulnerability. It does not calculate the combined impact of several findings used in sequence against a specific environment, so moderate findings that combine into a critical path keep their moderate scores.
Yes, and it can also reject one. It carries access, identity, and data forward from each step, validates every transition with evidence, and either completes the chain to a demonstrated outcome or records exactly where it broke, such as an insufficient permission or a control that blocked the next hop.
