Attack Chains: Why Three Low-Severity Findings Can Add Up to a Critical

Open any vulnerability backlog and you will find the same shape: a handful of criticals that get fixed quickly, and a long tail of lows and mediums that does not. The tail is where most real-world compromises quietly start, because severity is scored one finding at a time and attackers do not work one finding at a time.

Severity scores describe findings, not paths

A CVSS-style score answers a narrow question: how bad is this issue, in isolation, assuming nothing else is true? That is the right question for a patch advisory. It is the wrong question for a production environment, where every finding sits next to a dozen others and the useful question is what an attacker can reach by combining them.

Two issues that each score as "low" can compose into something with no low-severity equivalent. The score for the chain is not the sum of its parts; it is the score of whatever the last link unlocks.

Anatomy of a chain

Take three findings that would each be deferred in most triage meetings:

• An IDOR on an admin lookup endpoint. It leaks a user's profile fields, nothing sensitive on its own, so it scores low.
• A guessable JWT signing key. Exploiting it requires a valid token to start from, which is hard to get cold, so it scores low.
• No rate limit on the session endpoint. Brute force is "possible but slow," so it scores low.

Together they read differently. The IDOR hands over identifiers and the token format, the unlimited session endpoint makes the weak signing key practical to recover, and the recovered key lets an attacker mint a token for any account. Three backlog items became account takeover.

Why scanners and annual pentests miss them

A scanner reports each issue independently, so the chain never appears in the output. It is spread across three rows of a spreadsheet, each with its own owner and its own "fix in 90 days."

A point-in-time pentest can find chains, but only the ones a tester had time to try, against the build that existed that week. A new endpoint next month can complete a chain that was incomplete when the report was written. We cover that cadence problem in more detail in our piece on continuous attack surface management.

A backlog sorted by severity tells you which findings are bad. It does not tell you which findings are connected.

Triage by path, not by score

You do not need a new tool to start changing how you triage. Three habits get most of the way there:

• Ask what each finding gives an attacker, not how bad it is. Record what a finding unlocks: identifiers, tokens, internal hostnames, a foothold. Findings that unlock inputs for other findings deserve a second look.
• Group findings by asset and trust boundary. Chains form among issues that live near each other: the same service, the same auth system, the same admin surface. Review lows together per asset, not across the whole backlog.
• Fix the cheapest link in the chain. Once a chain is known, you do not need to fix all three issues to break it. The rate limit is often a one-line change that makes the whole path impractical.

Proving the chain is real

Hypothesising a chain is easy; showing that it works is what gets it fixed. A chain that is only a diagram in a slide deck turns into a debate about likelihood. A chain that comes with a reproducible exploit and request logs turns into a ticket. That is why agentic pentesting validates every candidate path against a sandboxed replica before it is reported, rather than reporting the theory.

If you want to see what a validated chain looks like in a report, with the evidence, the reproduction steps and the order to fix things in, the interactive demo walks through one end to end.