How to Chain Low Bugs into Critical Findings
Triagers see dozens of “open redirect (low)” and “XSS on rare page (medium)” reports. Chains change the story: the same bugs become password-reset theft, OAuth token leakage, or one-click account takeover.
Chaining is a skill of mapping trust boundaries — not inventing fantasy attacks.
Build a chain map
For your target, list:
- Auth entry points (login, OAuth, magic links, SSO)
- Token delivery channels (email links, SMS, in-app)
- Redirectors and postMessage bridges
- XSS sinks on authenticated origins
- CSRF defenses and cookie flags
Ask: which low issue moves a secret or an origin across a boundary?
Classic high-value chains
- Open redirect + OAuth → steal authorization codes
- XSS + missing HttpOnly → session theft (or XSS + CSRF if cookies are HttpOnly)
- Host header / reset poisoning + weak token → inbox takeover path
- CSRF + state-changing admin action after a click
- Subdomain takeover + XSS/cookie scope → parent origin impact
Only claim the chain you fully demonstrated on accounts you own.
How to prove without drama
- Demonstrate each link separately with screenshots.
- Show the combined flow end to end once.
- Stop at clear account compromise of your test user.
- Label residual requirements (victim click, email access) honestly.
Severity that survives triage
Programs pay for demonstrated impact. “Could be chained with unknown XSS” is not a chain. “Here is XSS on app.example reading the OAuth redirect” is.
Defensive checklist
- Harden each link: strict redirect allowlists, HttpOnly+Secure+SameSite cookies, exact OAuth redirect URIs.
- Threat-model email links and deep links as bearer tokens.
- Review subdomain cookie scopes.
- Add regression tests for known chain patterns.
Chain thinking turns scattered lows into a narrative attackers actually use. Map the path of the secret — then walk it carefully.
Original Bugflare guide informed by common chain patterns discussed in PortSwigger research culture.