Exploit chaining & impact amplification

When it applies

You have bugs that are individually "meh" (self-XSS, an info leak, an open redirect, a weak CSRF) and need to turn them into something a program pays for — or a pentest foothold that needs several bugs stacked.

Why it works

Impact is compositional. One bug supplies a precondition another needs: a leak provides the id IDOR needs; an open redirect makes OAuth leak a token; SSRF reaches the metadata service that yields cloud creds. The chain's severity is the end impact, not the weakest link.

Method

1. Inventory every finding with what it gives and what it needs (primitive in / out).
2. Look for matches: does bug A's output satisfy bug B's precondition? Common chains:
   • self-XSS + login-CSRF / cookie-fixation → land XSS in the victim's session.
   • open redirect + OAuth redirect_uri → steal the authorization code → ATO.
   • IDOR/info-leak → user id/UUID → BOLA on another endpoint.
   • SSRF → cloud-imds-ssrf → IAM creds → cloud impact.
   • file upload (stored) → XSS/SSRF/RCE depending on how it's served.
3. Build the shortest reliable path to the highest impact; script the PoC end-to-end.
4. Write the narrative: state the end impact first, then each link with its role, so a triager sees severity immediately (see reporting-bug-bounty-writeup).

Gotchas

• Don't over-chain — the simplest path to real impact is more credible and reproducible.
• Each link must be reliable; a flaky step sinks the whole chain in triage.
• Keep every step in scope and within RoE — a chain that steps out of scope is unreportable.

Verify success

A single reproducible PoC that starts from attacker-controlled input and ends at concrete high impact (ATO, data access, RCE, cloud takeover).

References

Bug-bounty disclosed chains (HackerOne Hacktivity); PortSwigger chained-attack labs.