OAuth redirect bypass to full account takeover.
Loose redirect URI matching let a crafted login link hand a user's authorization code to an attacker.
- Discovered (complete)
- Proven (complete)
- Fixed (not yet published)
- Retested (not yet published)
What they were shipping
An AI workflow platform with "Sign in with Google".
What we found
The authorization endpoint matched redirect URIs loosely instead of against an exact allow-list, so a crafted login link could point the callback somewhere the team never registered.
How we proved it
A user following the crafted link and completing "Sign in with Google" sent their one-time authorization code to a server we controlled.
Business impact
Full account takeover, with no password or MFA prompt involved.
Fix
Match redirect URIs exactly against a registered allow-list. No wildcards, no prefix matching.
Retest
Retest status not published for this case.
Why it keeps happening
Almost every early-stage team wildcards its redirect URIs during development and never tightens them. Social login looks like the safe choice, so nobody re-tests it.