# Vulnerability Chaining

> Use when you have multiple findings and need to combine them into realistic end-to-end attack paths — turning several low/medium issues into a single critical-impact exploit chain. The red-team-lead skill that ties the specialists' findings together into business impact.

- Skill: `mn-youssef/vulnerability-chaining` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mn-youssef/vulnerability-chaining`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mn-youssef/vulnerability-chaining/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: mn-youssef (https://skillmd.com/u/mn-youssef)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mn-youssef/vulnerability-chaining

---


# Vulnerability Chaining (the team lead)

## Overview
Individual findings undersell real risk. Attackers don't stop at one bug — they *chain* them:
an info leak feeds an enumeration, which feeds an auth bypass, which reaches admin. This skill
takes the register from all FIND/EXPLOIT specialists and assembles attack **paths**.

**Core principle:** Chain impact is *multiplicative, not additive*. Three "Mediums" that connect
can equal one "Critical." Severity belongs to the *path*, not the isolated bug.

## ⚠️ Authorization
Demonstrate chains only on your own/authorized non-prod instance. Prove the path with the
*minimum* steps; stop at proof of impact — no persistence, no real-data exfiltration, no pivoting
to systems out of scope.

## Method
1. **Inventory primitives** — re-read every finding as a *capability*, not a label:
   - *Info* (enumeration, verbose errors, leaked ids/secrets, source maps)
   - *Foothold* (any auth bypass, XSS, SSRF, upload)
   - *Escalation* (IDOR→admin, privesc, mass assignment)
   - *Pivot* (SSRF→metadata, leaked key→cloud, token reuse)
2. **Find adjacencies** — output of one bug = precondition of another? (leaked email →
   no-rate-limit login → ATO; reflected XSS → steals admin session → admin IDOR).
3. **Build the path** — order primitives start→goal (unauth → user → admin → data/RCE).
4. **Demonstrate safely** — walk the chain end-to-end on staging, capturing each hop's PoC.
5. **Score the chain** — rate by the *final* impact, then list the constituent bugs.

See `references/attack-paths.md` for canonical chain templates.

## Quick reference — high-value chains
| Chain | Path |
|-------|------|
| Full account takeover | user enumeration → no rate limit → weak reset/JWT → ATO |
| XSS → admin compromise | stored XSS → steal admin cookie → admin BFLA → mass data |
| SSRF → cloud takeover | SSRF → `169.254.169.254` metadata → IAM creds → cloud API |
| IDOR → privesc | IDOR leaks admin id/email → password reset on admin → admin access |
| Upload → RCE | unrestricted upload → web-accessible path → execute → shell |
| Logic → fraud | coupon race → negative balance → withdraw → financial loss |

## Output
One narrative per chain: the **attack path** (numbered hops), the constituent finding IDs, the
**end impact** in business terms, and the single point where breaking the chain stops it (the
cheapest fix). This is what makes leadership act.

## Hand-off
Findings come from all specialists; chains go to **`pentest-reporting`** as your top criticals,
and to **`security-hardening`** highlighting the cheapest chain-breaking fix.

## Common mistakes
- Reporting bugs in isolation — you'll under-rate the real risk and the chain gets ignored.
- Building theoretical chains — each hop must be *demonstrated*, not assumed.
- Over-running the chain — stop at proven impact; don't persist or pivot out of scope.
- Missing the cheapest break — often one mid-chain fix kills several paths at once.