Trust-Through-Defaults

The Hotel Check-in Analogy

Imagine walking into a hotel. Your passport proves who you are in a general sense, but the front desk does not hand you a room key simply because your passport is authentic. Instead, the staff binds your identity to a specific reservation, records your room number, and issues a context-specific credential—the key card—that works only for your room and only for the duration of your stay.

Trust-through-defaults is the equivalent of a hotel front desk looking at your passport and handing you every key in the building. By failing to bind the identity proof to the specific “reservation” (the request or session), the system grants excessive access based on a valid but unscoped credential.

Why This Pattern Recurs

This vulnerability persists due to four structural drivers in modern identity infrastructure:

• Blind trust in external inputs. Many identity stacks ingest tokens or headers from external identity providers (IdPs)—the services that verify your identity—and treat them as absolute ground truth without secondary validation against local state.
• SAML binding gaps. Default IdP-initiated single sign-on (SSO) flows in SAML often lack the InResponseTo binding, so the service provider loses replay and assertion-injection detection.
• OIDC implementation shortcuts. OpenID Connect has no standardized IdP-initiated flow (treated as an anti-pattern), which forces SP-initiated binding when used correctly—but many implementations shortcut to token pass-through.
• Permissive library defaults. Many OAuth 2.1 and OIDC libraries ship with loose default settings—weak audience checks, minimal nonce enforcement, flexible algorithm negotiation—that get hardened only when operators explicitly configure them.

Protocol Failure Modes

The pattern manifests differently across protocols. In SAML, the most common failure is accepting unsolicited assertions through IdP-initiated flows that lack an InResponseTo binding, making replay and assertion injection undetectable. XML Signature Wrapping attacks and pre-authentication XML parsing flaws (as in the Citrix case below) compound the risk.

In OAuth and OIDC, the failure typically involves accepting tokens without verifying the audience (is this token for this application?), the issuer (did this IdP issue it?), or the nonce and state parameters (does this response match the request that started it?). Libraries that accept alg:none or allow HS256/RS256 key confusion widen the attack surface further.

The 2026 Incident Wave

A cluster of vulnerabilities in late 2026 illustrated how trust-through-defaults operates at scale:

• SAP Cloud SDK for Python (CVE-2026-89111, CVSS 10.0). The SDK trusted the tenant_subdomain parameter without validation, using it to construct the OAuth2 token endpoint URL. An attacker controlling that parameter could redirect the token request to an attacker-controlled host, capturing the application’s OAuth2 client credentials. The flaw was disclosed in SAP’s October 2026 security updates.
• Keycloak SAML broker (CVE-2026-16442, Red Hat severity Important / NVD 9.8). The IdP-initiated SSO endpoint failed to verify whether an upstream SAML identity provider was restricted to account-linking only. An attacker controlling a linked upstream identity could bypass that restriction and obtain full login access to the corresponding local user account. Red Hat’s analysis traced the root cause to missing enforcement within the SAML broker component.
• Citrix NetScaler ADC and Gateway (CVE-2026-88779, CVSSv4 8.7). A SAML XML parsing memory overflow allowed unauthenticated remote attackers to trigger denial-of-service on any appliance configured as a SAML Service Provider or Identity Provider. The vulnerability was added to the CISA Known Exploited Vulnerabilities catalog on October 4, 2026, confirming active exploitation.

Mitigation: Binding Assertions to Local Context

The core defense is to stop treating identity assertions as self-proving. Each assertion must be verified against the local security context before it grants access:

• SAML InResponseTo: Match every response to an outstanding authentication request; reject unsolicited assertions.
• OAuth state + OIDC nonce + PKCE: Bind the authorization request to the callback; reject replayed or unsolicited responses.
• Strict audience and issuer validation: Reject tokens issued for a different relying party or by an unexpected IdP.
• Sender-constrained tokens: Use DPoP (RFC 9449) or mTLS (RFC 8705) to bind tokens to the client that requested them.
• Short lifetimes and single-use replay protection: Minimize the window in which a stolen or intercepted assertion remains useful.

The pattern’s persistence is not a knowledge problem—binding mechanisms have existed in the protocol specifications for years. It is a defaults problem. Libraries ship permissive. Documentation emphasizes the happy path. And the result is that most federation layers still accept assertions as pass-through tokens, trusting the identity provider to have done the work that only the relying party can do.