ANT-2026-BVDWY3J9: Redirect allow-list ignores URL scheme and port

In supabase/auth, IsRedirectURLValid (internal/utilities/request.go:104) short-circuits to allow a redirect when base.Hostname() == refurl.Hostname() for SITE_URL, without checking scheme or port, and before consulting the glob allow-list. If SITE_URL is https://app.example.com, targets like http://app.example.com, evilapp://app.example.com, or https://app.example.com:8443 are accepted. The /authorize, /verify, /callback and related flows then redirect with the access token in the URL fragment. An attacker who controls a handler for an alternate scheme or port on that hostname can capture the victim's session tokens.

Target

Project: supabase/auth
Location: internal/utilities/request.go:104
Discovery: static analysis — not yet dynamically reproduced

Technical Details

The root cause is a same-origin check implemented as a hostname-only string comparison: base.Hostname() == refurl.Hostname() returns true and bypasses the explicit allow-list entirely. Because scheme and port are omitted from the comparison, any URI whose host label matches SITE_URL's host is treated as a trusted redirect target, violating the same-origin assumption the allow-list is meant to enforce.

Reproduction

1. Determine the deployment's SITE_URL hostname (e.g. app.example.com)
2. Obtain control of a same-hostname endpoint on a different scheme/port (e.g. register evilapp:// on the victim's mobile OS, or bind app.example.com:8443 in a shared environment)
3. Craft a supabase/auth link (/authorize, /verify, etc.) with redirect_to set to that alternate-scheme/port URI
4. Deliver the link to the victim and have them complete the flow
5. Receive the redirect containing #access_token=... at the attacker-controlled handler and use it to hijack the session

[No reproducer or sanitizer output attached — request from security-cvd@anthropic.com if needed.]

Suggested Fix

Only treat a redirect as same-origin when scheme, host, and port all match SITE_URL; otherwise fall through to the explicit glob allow-list.

Acknowledgement

This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research. Please direct questions to security-cvd@anthropic.com and reference ANT-2026-BVDWY3J9.

---

Reference: ANT-2026-BVDWY3J9
Anthropic CVD Policy: https://www.anthropic.com/coordinated-vulnerability-disclosure

{
  "ant_id": "ANT-2026-BVDWY3J9",
  "bug_class": "open-redirect",
  "claude_severity": "medium",
  "commit_sha": null,
  "created_at": "2026-05-14T22:01:17+00:00",
  "description": "In supabase/auth, IsRedirectURLValid (internal/utilities/request.go:104) short-circuits to allow a redirect when base.Hostname() == refurl.Hostname() for SITE_URL, without checking scheme or port, and before consulting the glob allow-list. If SITE_URL is https://app.example.com, targets like http://app.example.com, evilapp://app.example.com, or https://app.example.com:8443 are accepted. The /authorize, /verify, /callback and related flows then redirect with the access token in the URL fragment. An attacker who controls a handler for an alternate scheme or port on that hostname can capture the victim's session tokens.",
  "discovered_at": "2026-05-10T00:00:00+00:00",
  "location": "internal/utilities/request.go:104",
  "poc_sha256": null,
  "preimage_version": 1,
  "project": "supabase/auth",
  "reproduction": [
    "Determine the deployment's SITE_URL hostname (e.g. app.example.com)",
    "Obtain control of a same-hostname endpoint on a different scheme/port (e.g. register evilapp:// on the victim's mobile OS, or bind app.example.com:8443 in a shared environment)",
    "Craft a supabase/auth link (/authorize, /verify, etc.) with redirect_to set to that alternate-scheme/port URI",
    "Deliver the link to the victim and have them complete the flow",
    "Receive the redirect containing #access_token=... at the attacker-controlled handler and use it to hijack the session"
  ],
  "technical_details": "The root cause is a same-origin check implemented as a hostname-only string comparison: base.Hostname() == refurl.Hostname() returns true and bypasses the explicit allow-list entirely. Because scheme and port are omitted from the comparison, any URI whose host label matches SITE_URL's host is treated as a trusted redirect target, violating the same-origin assumption the allow-list is meant to enforce.",
  "title": "Redirect allow-list ignores URL scheme and port",
  "vendor_severity": null
}