OAuth host poisoning enables cross-tenant account takeover

Summary

OAuth state signed an attacker-selected origin and the token endpoint trusted an unsigned session cookie

An attacker could start OAuth with a poisoned Host, receive the victim's still-unused provider code at an attacker origin, and redeem it on a chosen tenant by matching an unsigned user_session_id cookie.

Root cause. SignInByOAuth derived its continuation from raw Host/X-Forwarded-Host and signed that origin into state. The callback redirected the provider code and identifier there, while OAuthToken neither revalidated the state nor consumed a server-side transaction and accepted a caller-set session cookie as the binding.

Remediation evidence. Fider responded to the disclosure and merged exact PR #1626 on 27 July 2026. It replaces request-host authority with canonical tenant origins and a signed handoff bound to the provider, origin, and browser session.

CVSS Score

VectorN

ComplexityL

PrivilegesN

User InteractionR

ScopeU

ConfidentialityH

IntegrityH

AvailabilityH

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Vulnerability Location

SourceLine 33

app/pkg/web/request.go

WrapRequest()

SinkLine 183

app/handlers/oauth.go

OAuthToken()

Source-to-Sink Analysis

app/pkg/web/request.go:33

An unauthenticated request selected the externally visible host from direct or forwarded request headers.

host := request.Host
if forwarded := request.Header.Get("X-Forwarded-Host"); forwarded != "" {
  host = forwarded
}

app/handlers/oauth.go:SignInByOAuth()

The OAuth start handler placed that attacker origin and a session identifier into signed state.

redirect := c.BaseURL()
state := jwt.EncodeOAuthState(redirect, c.SessionID())

app/handlers/oauth.go:183

The tenant token endpoint redeemed the captured provider code after comparing only a caller-controlled cookie to the disclosed identifier.

if c.Cookie("user_session_id") == state.Identifier {
  profile := provider.Exchange(code)
  SetAuthCookie(c, profile)
}

Impact Analysis

Critical Impact

The attacker takes over the consenting victim's account in the selected tenant; if that victim is an administrator, the attacker gains tenant data export, settings, integration, user-management, and destructive content authority.

Attack Surface

Built-in OAuth sign-in on multi-host Fider deployments that accepted arbitrary Host or untrusted forwarded-host values.

Preconditions

The attacker controls a public HTTPS origin and knows the target tenant host. A victim with an existing Fider account must approve the legitimate provider application; the attacker needs no OAuth client secret or Fider credential.

Proof of Concept

Environment Setup

Use an isolated vulnerable multi-host Fider deployment, a victim test account, and an attacker-controlled HTTPS callback collector.

Target Configuration

Enable a built-in global OAuth provider and allow the application to receive an arbitrary Host or client-supplied X-Forwarded-Host.

Exploit Delivery

Start OAuth through the poisoned authority, complete consent as the victim, capture the redirected code/identifier, and replay them to the victim tenant with the matching unsigned cookie.

Outcome

PR #1626 accepts only a canonical tenant origin and a cryptographically bound, single-purpose handoff, so the captured values cannot be redirected or replayed into another tenant.

Expected Response: The vulnerable tenant endpoint sets a valid Fider auth cookie for the victim account.

Run this level of analysis on your repo.

Winfunc traces source-to-sink paths, validates exploitability, and gives your team patch-ready remediation.

Vulnerability Detection

View Patch PRVerify fix on GitHub