The Twitter Open Redirect Nobody Patched

In the previous post we tested every major trusted-domain redirect technique and found that most have been hardened with signature requirements. That research started from the assumption that platforms had patched the obvious open redirect endpoints. So we ran a separate hunt — through 80+ commonly-used trusted domains, testing redirect parameters across login pages, logout flows, OAuth endpoints, and search redirect URLs.

We expected to find nothing. We found one. It's been sitting there for years, on a domain that has every email gateway's trust.

The endpoint

https://twitter.com/logout?redirect_after_logout=https://example.com

That URL responds with HTTP 302 and a Location: header pointing at whatever you put in redirect_after_logout. No signature required. No authentication required — works with zero cookies, no Twitter session, nothing. The same endpoint works on x.com (the rebranded domain), giving two trusted domains for the price of one.

We tested it with our destination set to lexlabtools.com:

That's lexlabtools.com rendered fully, with no intermediate page. The browser's address bar showed twitter.com briefly, then flipped directly to the destination. No "you are leaving Twitter" warning. No click-through. The 302 fires and the browser follows it.

How we found it

The hunt was systematic. We tested redirect parameters across every category of trusted-domain endpoint we could think of: login flows (?next=, ?redirect=, ?return_to=), logout flows (?redirect_after_logout=, ?wreply=, ?post_logout_redirect_uri=), search engines (?u=, ?adurl=), OAuth flows (redirect_uri=), and SSO callbacks. We checked Google, Microsoft, Meta, LinkedIn, GitHub, GitLab, Atlassian, Salesforce, Zoom, Slack, Stripe, PayPal, Apple, Dropbox, all major SaaS, all major cloud providers, and every social network we could remember.

The script was simple: hit each URL, follow up to 8 redirects, check if the final landing URL was on our destination domain (not just containing it as a parameter — actually landing there).

Every endpoint on Google was patched. Every endpoint on Microsoft was patched. Facebook's l.php returns 400 without a valid h= signature. LinkedIn's redir/redirect shows the "Link Error" page we documented in the last post. GitHub holds the parameter in the URL but doesn't act on it without login. PayPal returns 403. Atlassian, Salesforce, Zoom, Slack — all returned the login form with the redirect parameter preserved but never fired the redirect.

Twitter's logout endpoint was the only one that processed the parameter unauthenticated.

What's actually happening

Looking at the request:

GET /logout?redirect_after_logout=https://example.com HTTP/2chr(10)Host: twitter.comchr(10)User-Agent: Mozilla/5.0 ... Chrome/138.0.0.0chr(10)chr(10)< HTTP/2 302chr(10)< location: https://example.com

Clean 302, no validation that example.com is on any allowlist. Twitter's intent was probably to make the logout flow nice — after you log out, take you wherever you came from. They didn't validate the destination. That's the bug.

The catch — UA-based conditional behavior

Twitter does NOT serve the redirect to every client. We tested a range of User-Agents:

| User-Agent | Response | |---|---| | Chrome (real browser) | HTTP 302 → destination | | Windows Chrome (Defender Safe Links style) | HTTP 302 → destination | | Linux Chrome (Proofpoint style) | HTTP 302 → destination | | MSIE 9.0 (Mimecast style) | HTTP 302 → destination | | python-requests | HTTP 302 → destination | | curl (default UA) | HTTP 302 → destination | | Empty User-Agent | HTTP 302 → destination | | Slackbot-LinkExpanding | Redirected to twitter.com/i/flow/login | | Googlebot | HTTP 404 |

Twitter blocks Slackbot and Googlebot specifically. Slack link preview crawlers don't see the destination — they get sent to the Twitter login page instead. Googlebot gets a 404. Every other UA — including every email security scanner UA we know of — gets the 302.

That means the technique has two characteristics worth understanding:

• Slack and other chat-app previews are blocked. If you paste a twitter.com/logout?... link into Slack, you won't get a preview card showing the destination's content. The link preview will show a Twitter login screen instead. This actually limits the social engineering value — you can't show a fake Microsoft document preview under a Twitter URL.

• Email security scanners are not blocked. Microsoft Defender Safe Links, Proofpoint TAP, Mimecast, and every other scanner that uses a Chrome-based UA follows the redirect to the destination. They see whatever is at the destination URL and evaluate it.

That second point matters a lot for the next conversation.

Why the open redirect alone isn't enough

If the scanner follows the redirect and reaches the destination, what protection has the Twitter URL actually given you?

Three things, but none of them are the scanner-defeat people assume:

1. First-hop domain trust. The email gateway scans the URL before delivery. Many gateways do a domain reputation check on the visible URL host. The visible host is twitter.com, which has 19 years of clean reputation. The email passes the initial reputation check on that basis.

2. Multi-hop chain credibility. Most legitimate emails don't contain redirect chains. An email gateway that flags chained redirects sees twitter.com → ? as a one-hop chain through a major brand — much harder to flag than bit.ly → ? which is a known abuse pattern.

3. User trust. When a user hovers over the link in their email client, they see twitter.com/logout?.... They click because they trust Twitter, not because they understand redirect chains.

What the Twitter redirect does NOT do:

• It does not hide the destination from automated link scanning. The scanner follows the 302 and sees the destination URL plainly.
• It does not prevent the destination from being evaluated for content (Defender's detonation sandbox renders it).
• It does not prevent the destination's domain reputation from being checked at scan time.

So if the destination is a known-bad phishing domain, the scanner catches it regardless of how trusted the first hop was. The Twitter URL is a trust badge attached to the email, not a cloak around the destination.

The compound chain

The Twitter open redirect becomes powerful only when paired with a destination that's also designed to defeat scanners. In practice, that means:

Phishing emailchr(10)│chr(10)▼chr(10)twitter.com/logout?redirect_after_logout=https://[lure-domain]/[random-path]chr(10)│chr(10)│  HTTP 302 (scanner follows)chr(10)▼chr(10)Lure page protected by Cloudflare Turnstilechr(10)│chr(10)├── Scanner: fails Turnstile silently, sees "verifying..."chr(10)│   → logged as clean / inconclusivechr(10)│chr(10)└── Real user: passes Turnstile invisiblychr(10)→ redirected into phishletchr(10)→ credentials captured

The Turnstile gate at the destination does the actual scanner-defeat work. Cloudflare Turnstile is designed to detect headless browsers, automated traffic, and known scanner ASNs. When Defender Safe Links follows the 302 and reaches the Turnstile gate, its headless Chrome fails the challenge — it doesn't have real browser behavioral signals, real mouse movement history, or a residential ISP origin. The scanner sees a generic "verifying you are human" page and logs the page as not-clearly-malicious.

The real user clicks from their real browser on their real home network. Turnstile passes them invisibly. They get the phishlet. The attacker gets the session cookie.

The Twitter URL is what convinces the email gateway to deliver. The Turnstile is what makes sure the scanner never sees the actual phishing content. Neither alone is sufficient. Together they cover every automated scanning layer we know of.

What this means

Anyone arguing that "trusted-domain redirects defeat email scanners" is half-right. They convince scanners that the email is from a reputable source. They don't hide the destination from the scanner that follows the chain. The destination needs its own defenses — Turnstile or equivalent challenge-page protection — for the chain to be complete.

For defenders: don't focus on the Twitter URL. Focus on the redirect destination's properties. A redirect from twitter.com/logout to a domain registered three days ago, hosting a TLS cert issued yesterday, on a single-VPS hosting provider's ASN, gated behind Turnstile — that's the phishing chain. Each property individually has some legitimate use. The combination is the signal.

In the next post we look at the other half — how attackers build their own redirect infrastructure when they don't want to rely on platform bugs.