Combine low/medium findings into one high-impact exploit chain, and amplify demonstrated impact. Load when you have several small bugs, a "so what?" finding, on "chain", "escalate impact", or building the narrative for a report. Signals: self-XSS + CSRF, open-redirect + OAuth, IDOR + info-leak, SSRF + metadata.
Installs into .claude/skills of the current project.
Are you the author of Exploit Chaining?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/noorqureshi-exploit-chaining)
---
name: exploit-chaining
description: >
Combine low/medium findings into one high-impact exploit chain, and amplify demonstrated
impact. Load when you have several small bugs, a "so what?" finding, on "chain", "escalate
impact", or building the narrative for a report. Signals: self-XSS + CSRF, open-redirect +
OAuth, IDOR + info-leak, SSRF + metadata.
domain: exploit-dev
type: methodology
stability: learning
modes: [pentest, bugbounty]
severity: high
schema_version: 1
tools: []
---
# 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.