Bug Chaining: IDOR + Auth Bypass + SSRF to Full Account Compromise

Cybersecurity

Individually, three medium bugs get medium bounties. Chained, they become a critical that takes over the platform. This is a walkthrough of a real-shape chain, IDOR plus auth bypass plus SSRF, and the reporting structure that captures full impact.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 8, 2023 · 11 min read

Why chains pay more

A chain converts three theoretical bugs into one demonstrated full-impact attack. Triagers cannot argue the impact when the PoC ends with read-write access to the admin console.

The shape of this chain

1. IDOR on a profile endpoint leaks internal user identifiers
2. Auth bypass on an internal admin route accepts the leaked identifier as a session signal
3. SSRF on a webhook tester reaches the internal admin route from the trusted network
4. Result, full admin takeover from an unauthenticated attacker

Step one, the IDOR

The endpoint /api/v2/profile/{user_id} returned the requesting user's data regardless of which user_id was supplied, but only revealed internal_id, email, and role. Looks like a low. Note the internal_id, that is the pivot.

Step two, the auth bypass

An internal admin route at /admin/users accepted an X-Internal-User header in addition to session cookies. The header was meant for service-to-service calls inside the cluster. From the public internet the route required cookies, so on its own it looked safe.

Step three, the SSRF

A webhook tester let users enter any URL and the server fetched it to verify reachability. There was an allowlist of public domains, but the URL parser accepted user@internal.svc.cluster.local style payloads that the validator missed. Classic parser differential.

Wiring it together

1. Use the IDOR to enumerate admin internal_ids
2. Use the SSRF to fetch /admin/users from the trusted network with X-Internal-User set to the admin's internal_id
3. Receive the admin's session token or an authenticated response
4. Replay the session against the public admin console

Reporting a chain

File one report titled by the final impact, not the individual bugs. Inside, walk through each link with its own subsection, but make the title and the summary about the end state, full admin takeover from unauthenticated.

Severity for chains

CVSS the chain as a whole using the worst attack vector and the final impact. Note the individual bug scores too, programs sometimes pay per bug, but lead with the chain score.

What programs sometimes get wrong

• Splitting your chain into three reports and paying three lows
• Closing the IDOR as informational because it only leaks internal IDs
• Treating the trusted header as out of scope because it is internal

Push back politely with the chain PoC. If your script demonstrates admin takeover end to end, the chain is the bug, not the parts.

The script that wins

One file, one command, three steps with comments, a final line that prints the stolen admin session. Triagers see one terminal output that ends with you in the admin panel. That is what a critical looks like.

Three mediums in three reports earn medium money. One critical chain in one report earns critical money. Same bugs, different framing.

How to find chains

• Catalogue every low and informational you find, do not throw them away
• Look for any endpoint that trusts internal headers or IPs
• Map every input that reaches a URL fetcher, file reader, or DNS resolver
• Ask what each leaked identifier or token could unlock elsewhere

Chains live in your notes. Hunters who report bugs the moment they find them rarely find chains. Hunters who sit with their findings for a week often do.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.