IT
InstaTunnel Team
Published by our engineering team
The OAuth Tunnel Trap: Preventing Subdomain Hijacking in Local Development
The OAuth Tunnel Trap: Preventing Subdomain Hijacking in Local Development
Your local tunnel is closed, but your OAuth redirect is still active. Here’s how attackers hijack free-tier tunnel subdomains to steal authorization codes — and how to lock down your local auth flows before they do.
In the fast-paced ecosystem of modern software development, speed is everything. Developers are constantly spinning up ephemeral preview environments, testing webhook integrations, and configuring complex third-party authentication flows. To bridge the gap between isolated local environments and the public internet, developers rely heavily on localhost tunneling services. Platforms like ngrok, Localtunnel, and Cloudflare Tunnels have become absolute necessities.
However, as we move through 2026, the intersection of ephemeral infrastructure and rigid authentication protocols has birthed a highly exploitable blind spot. Security researchers are increasingly tracking a subtle but devastating vulnerability known as OAuth redirect hijacking. This attack doesn’t rely on zero-day exploits in the OAuth protocol itself — it preys on developer habits, the lifecycle of free-tier tunnel subdomains, and the lingering trust embedded in identity providers like Google, GitHub, and Stripe.
This is the OAuth Subdomain Trap — a critical localhost tunnel security failure that occurs when the convenience of temporary URLs collides with permanent access privileges.
The Anatomy of Localhost Tunneling
To understand the trap, we first must understand the tool.
When a developer is building an application on their laptop, it typically runs on a local port (e.g., http://localhost:3000). This is fine for isolated UI work, but the moment the application needs to interact with the outside world — receiving a Stripe payment webhook or completing a “Login with Google” OAuth flow — the public internet needs a way to route traffic back to that developer’s specific machine.
Tunneling services solve this by creating a secure connection between the local machine and a cloud gateway. When a developer runs a command like ngrok http 3000, the tunneling service provisions a public, publicly accessible URL (e.g., https://random-string-123.ngrok-free.app). Any traffic hitting that public URL is routed through the provider’s infrastructure, down the tunnel, and directly into the developer’s local port.
The problem lies in the ephemeral nature of these free-tier subdomains. They are designed to be temporary. The moment the developer terminates the process or closes their laptop, the tunnel collapses. Shortly after, the provider returns that random string back to the pool of available subdomains, ready to be issued to the next user who requests a tunnel.
The Eroding Free Tier Landscape
The tunneling market has matured significantly and the risk landscape has shifted alongside it. As of 2026, ngrok’s free tier offers 1 GB bandwidth/month, a single endpoint, and random (non-persistent) URLs. A paid personal plan starts at $8–10/month and unlocks custom subdomains — a critical security feature, not just a convenience. In February 2026, the DDEV open-source project publicly opened an issue to consider dropping ngrok as its default sharing provider entirely, citing increasingly restrictive free-tier constraints.
Meanwhile, Localtunnel — long the open-source darling — has suffered from classic maintenance neglect: no sustainable funding model, slowing updates, and frequent server downtime. Professional developers have largely moved on. This fragmentation matters because it pushes more teams toward unvetted free-tier alternatives with opaque subdomain recycling policies, widening the attack surface.
The OAuth 2.0 Authorization Code Flow
The second component of the trap is the OAuth 2.0 protocol itself, specifically the widely used Authorization Code grant flow.
When a user clicks “Login with Google” on your application, your app redirects the user’s browser to Google’s authentication servers. Included in this redirect is a parameter called the redirect_uri. This tells Google: “Once the user has successfully logged in and granted permission, send them back to this specific web address with an authorization code.”
To prevent attackers from arbitrarily changing the redirect_uri and stealing the authorization code, OAuth providers require developers to strictly pre-register their allowed callback URLs in a developer console. If the requested redirect_uri doesn’t match the pre-approved list, the provider throws an error and halts the flow.
During local development, a developer building a login system will spin up a tunnel, get their temporary URL (https://dev-app-abc.ngrok-free.app), and paste https://dev-app-abc.ngrok-free.app/api/auth/callback into their Google Cloud Console, Stripe Dashboard, or Slack API settings.
The application works perfectly. The developer tests the login, the identity provider sends the code to the tunnel, the tunnel routes it to localhost, and the developer successfully logs in.
Then, Friday afternoon arrives. The developer shuts down their tunnel and goes home.
But the redirect_uri remains whitelisted in the identity provider’s dashboard.
The Mechanics of the Trap: Subdomain Hijacking
The moment the developer closes their tunnel, a ticking time bomb is armed. The local endpoint is dead, but the cloud configuration still fully trusts the dead URL.
Threat actors understand that developers frequently abandon ephemeral subdomains while leaving them fully authorized in high-value third-party platforms. Exploiting this requires a methodical, automated approach.
Step 1: Reconnaissance and Scraping
Attackers do not blindly guess ngrok or Localtunnel subdomains. Instead, they run continuous, automated scraping operations across public data sources:
Public GitHub/GitLab Repositories: Developers often accidentally commit .env files or README.md documentation containing their temporary tunnel URLs.
Developer Forums and Issue Trackers: StackOverflow posts, GitHub issues, and Discord servers are goldmines where developers paste error logs containing their OAuth configuration details.
Certificate Transparency Logs: Depending on how the tunneling service provisions SSL/TLS certificates, the issuance of new subdomains can sometimes be tracked in real-time.
Step 2: The Squatting Phase
Once an attacker identifies an ephemeral tunnel URL associated with a target project, they periodically attempt to claim that exact subdomain. Some open-source tunneling services allow users to explicitly request a specific subdomain (e.g., lt --port 8000 --subdomain dev-app-abc). If the developer has released the subdomain, the attacker’s script successfully claims it. The attacker now controls the very endpoint that the victim’s identity provider explicitly trusts.
Step 3: Triggering the Exploit
With the subdomain secured, the attacker simply needs the victim — or a user of the victim’s application — to initiate an OAuth flow. If the application is still actively used in a staging environment, or if the attacker can trick a user into clicking a crafted login link, the OAuth provider will authenticate the user and faithfully redirect the browser — along with the highly sensitive authorization code — straight to the attacker’s squatted tunnel.
This attack pattern has been confirmed in real-world scenarios. In March 2026, Microsoft researchers revealed an active phishing campaign abusing OAuth authentication redirects to target government and public-sector organizations, redirecting users from trusted login pages to attacker-controlled infrastructure to serve malware or capture credentials. The OAuth authentication redirection mechanism — trusted and built into Microsoft, Google, and others — was the delivery vehicle.
Step 4: Code Interception and Token Exchange
The attacker’s listening server receives the HTTP request containing the ?code=XYZ123 parameter. Because OAuth authorization codes are short-lived, the attacker’s automated script immediately takes that code and exchanges it with the identity provider for a permanent Access Token.
The attacker now has full, authenticated access to the victim’s account — Google Workspace, GitHub repositories, Stripe financial data — without ever needing their username, password, or bypassing Two-Factor Authentication (2FA).
The 2026 Threat Landscape: AI Agents and CI/CD Compromise
While OAuth redirect hijacking has existed theoretically for years, 2026 has seen a massive escalation in its practical exploitation, driven by the explosion of Agentic AI workflows and automated CI pipelines.
The MCP + OAuth Attack Surface: CVE-2025-6514
The intersection of OAuth and AI agents is no longer theoretical. In July 2025, JFrog Security Research disclosed CVE-2025-6514 — a critical vulnerability (CVSS score 9.6–9.7) in mcp-remote, a widely used npm proxy that enables LLM hosts like Claude Desktop, Cursor, and Windsurf to communicate with remote MCP servers. The vulnerability affected versions 0.0.5 through 0.1.15 and had been downloaded nearly 559,000 times before disclosure.
The attack vector exploited a pattern baked into OAuth’s own design: dynamic discovery of authorization endpoints. When mcp-remote connected to a remote MCP server, it would ask: “Server, tell me where to authenticate.” A malicious server could respond with a crafted authorization_endpoint URL containing a PowerShell subexpression payload. Because mcp-remote passed this value unsanitized to an OS-level command (a browser launcher), the result was arbitrary OS command execution on the developer’s machine — the first documented case of full remote code execution achieved through the MCP infrastructure.
Exploitation required only one action from the victim: connecting to a malicious MCP server. No further interaction was needed. Organizations affected included those using Cloudflare, Hugging Face, and Auth0 integrations. The fix was released in mcp-remote v0.1.16, but the architectural lesson is stark: every OAuth integration in an agent system is a potential attack vector — not because OAuth is broken, but because its trust assumptions don’t match the autonomous nature of agentic AI.
AI Hallucination Squatting
Beyond CVE-2025-6514, the broader pattern of AI agent + tunnel + OAuth is dangerous. Developers routinely use ephemeral tunnels to expose local agent interfaces to cloud-based LLMs. If a developer abandons an OAuth-gated tunnel used by an AI agent, an attacker who squats the domain can serve malicious instructions. When the agent attempts to authenticate or fetch context from what it believes is its trusted local endpoint, the attacker can inject prompt-injection payloads or intercept the agent’s OAuth tokens, effectively gaining autonomous control over the developer’s environment.
The CI/CD Preview Environment Risk
Modern CI/CD platforms automatically spin up “Preview Environments” for every pull request, often utilizing free-tier tunnel services to expose the preview to the internet. These environments are frequently hooked into staging databases and OAuth providers for testing purposes.
When the pull request is merged, the tunnel is destroyed — but the OAuth whitelist entries are rarely scrubbed automatically. This is compounded by real-world supply chain risk: in January 2025, the largest known SaaS OAuth breach of that year began with a compromised third-party app. Attackers then exploited Salesloft-Drift OAuth tokens, gaining access to hundreds of downstream environments. Obsidian Security researchers noted the blast radius was ten times greater than previous incidents where attackers had targeted Salesforce directly.
The Business Impact of Localhost Vulnerabilities
The business impact of this class of localhost tunnel security failure cannot be overstated. Because OAuth is fundamentally a protocol of delegated authorization, the blast radius depends entirely on the scopes granted by the compromised application:
Source Code Theft: A hijacked redirect for a GitHub OAuth application with repo scope lets the attacker silently clone all private repositories of the authenticated user.
Financial Fraud: A compromised Stripe OAuth connection allows the attacker to view customer data, manipulate subscription plans, or initiate unauthorized refunds.
Shadow IT Persistence: Unlike a compromised password that can be reset, a stolen OAuth access token — or a newly minted refresh token — can provide attackers with persistent, silent access to cloud applications for months before being detected.
Furthermore, these attacks are incredibly difficult to detect in standard server logs. Because the identity provider sent the traffic to a legitimate, whitelisted domain, the transaction looks perfectly normal to Google or GitHub. Because the traffic hit the attacker’s tunnel instead of the developer’s local machine, the victim has no logs indicating a breach occurred.
An important real-world parallel comes from Azure. Secureworks researchers documented a class of redirect URI takeover vulnerabilities where an organization had lost control of a subdomain (because the underlying Azure resource group was deleted), yet the OAuth redirect URI remained registered. Threat actors could re-register the subdomain in their own Azure tenant and use it to steal authorization codes and ID tokens — all while appearing to be the legitimate application.
How to Lock Down Your Local Auth Flows
Preventing the OAuth Subdomain Trap requires a fundamental shift in how engineering teams view local development. The traditional mindset that “localhost is a safe sandbox” is obsolete. Local environments must be treated as hostile edge networks.
- Mandate Persistent, Custom Subdomains The root cause of this vulnerability is the high turnover of ephemeral subdomains. The most effective mitigation is to stop using randomized free-tier URLs for any flow involving authentication.
If your team uses ngrok or Cloudflare Tunnels, invest in plans that allow you to reserve permanent, custom subdomains or connect a subdomain on a domain your organization controls (e.g., alice-dev.yourcompany.com). Because your organization owns the root domain and controls the DNS, an attacker can never squat or claim the subdomain after the developer logs off.
- Implement PKCE (Proof Key for Code Exchange) Originally designed for mobile applications that couldn’t securely store client secrets, PKCE (RFC 7636) is now an industry-standard requirement — not a mere recommendation — for all OAuth 2.0 implementations.
In January 2025, the IETF published RFC 9700: Best Current Practice for OAuth 2.0 Security, updating and extending the threat model from the original OAuth 2.0 specifications first published in 2012. RFC 9700 explicitly recommends PKCE for all client types and codifies lessons learned from real-world breaches including Booking.com’s open redirect vulnerability and Google’s domain inheritance flaw. The forthcoming OAuth 2.1 draft goes further: it makes PKCE mandatory for all flows and deprecates the implicit grant entirely.
PKCE completely neuters the subdomain hijacking attack. The client application generates a cryptographically random code_verifier and sends a hashed version (code_challenge) with the initial authorization request. Even if an attacker hijacks the ephemeral tunnel and intercepts the authorization code, they cannot exchange it for an Access Token without the original code_verifier, which never left the developer’s local machine.
[Client] → code_challenge (hashed) → [Identity Provider]
[Identity Provider] → authorization_code → [Attacker's squatted tunnel]
[Attacker] → tries to exchange code → [Identity Provider REJECTS: no code_verifier]
- Strict State Parameter Validation The OAuth state parameter is designed to prevent Cross-Site Request Forgery (CSRF), but it also serves as a critical defense-in-depth layer against hijacked redirects.
Before initiating the OAuth flow, the local application must generate a secure, unguessable state token and store it in a local session cookie. When the identity provider redirects the user back, it includes this state parameter. The application must verify that the state returned exactly matches the state stored in the cookie. RFC 9700 explicitly mandates this: clients must either rely on PKCE for CSRF protection (when the authorization server supports it) or use one-time CSRF tokens carried in the state parameter.
- Zero Trust and Edge Authentication In 2026, relying solely on secret URLs or IP whitelisting is insufficient. Modern localhost tunnel security requires enforcing identity at the edge, before traffic ever reaches the local machine.
Platforms like Cloudflare Access and the ngrok Traffic Policy engine allow developers to place an OpenID Connect (OIDC) or SAML authentication layer directly on the tunnel’s public endpoint. With edge authentication, even if an attacker successfully squats an abandoned tunnel URL, they cannot receive HTTP requests. The tunnel’s edge gateway intercepts any request and demands corporate IdP authentication. Because the attacker does not possess corporate credentials, the gateway drops the request — and the stolen authorization code never reaches the attacker’s server.
- Automated Hygiene and Cleanup Programs Organizations must treat third-party developer consoles as critical infrastructure. Security teams should use API integrations to periodically audit redirect_uri whitelists across all corporate OAuth applications — Google Workspace, GitHub, Slack, Stripe, and others.
Any URI pointing to a known ephemeral tunneling service (*.ngrok.io, *.ngrok-free.app, *.loca.lt, *.trycloudflare.com) should be flagged and automatically purged if it has not been actively justified within a defined timeframe (e.g., 7 days). Automation prevents the accumulation of “ghost” URIs that serve as permanent backdoors for opportunistic attackers.
- Enforce HTTPS-Only and Trusted Server Policies for AI Agents Given the lessons from CVE-2025-6514, any development workflow involving MCP agents or AI tool integrations must enforce a strict HTTPS-only, trusted-server connection policy. Teams should:
Audit all MCP server configurations and remove any insecure HTTP connections.
Maintain an allowlist of approved MCP server origins.
Update mcp-remote to v0.1.16 or later immediately if any prior version is in use.
Treat MCP server metadata (including authorization_endpoint responses) as untrusted input — never pass it directly to OS-level system calls.
A Summary of Controls
Threat Mitigation
Ephemeral subdomain squatting Persistent custom subdomains (paid tier / own domain)
Authorization code interception PKCE (RFC 7636), mandated by RFC 9700
CSRF and state forgery Strict state parameter validation
Attacker receives traffic on squatted URL Zero Trust edge authentication (OIDC/SAML)
Ghost redirect_uri in OAuth consoles Automated audit and cleanup pipelines
MCP agent OAuth endpoint injection (CVE-2025-6514) HTTPS-only MCP connections; mcp-remote ≥ v0.1.16
Conclusion: Securing the New Developer Edge
The era of trusting temporary infrastructure with permanent credentials is over. The OAuth Subdomain Trap perfectly illustrates how a minor convenience — using a free, randomized URL to test a login flow — can inadvertently expose an entire organization to catastrophic data breaches.
The attack surface has expanded dramatically. Microsoft documented active OAuth redirect abuse campaigns targeting government organizations in early 2026. JFrog disclosed a critical CVSS 9.6 RCE vulnerability in a tool used by nearly 560,000 developers, rooted entirely in how OAuth dynamic discovery was trusted. And the IETF codified a decade of hard-won lessons in RFC 9700, effectively declaring that the relaxed, flexible OAuth patterns of 2012 are no longer acceptable in 2025 and beyond.
An abandoned tunnel can be squatted and weaponized in minutes. To survive in this environment, engineering teams must abandon the illusion of the localhost sandbox. By enforcing persistent custom domains, mandating PKCE across all OAuth flows, deploying Zero Trust authentication at the tunnel edge, and treating AI agent OAuth discovery as untrusted input, organizations can confidently build and test complex integrations — without leaving the door wide open for the next wave of subdomain hijackers.
The security bar has moved. Development workflows must move with it.
Further reading: RFC 9700 – Best Current Practice for OAuth 2.0 Security · CVE-2025-6514 JFrog Advisory · Microsoft: OAuth Redirection Abuse · Secureworks: Azure Redirect URI Takeover
Related Topics