CVE-2026-33495: ORY Oathkeeper Auth Bypass Vulnerability

CVE-2026-33495 Overview

ORY Oathkeeper, an Identity & Access Proxy (IAP) and Access Control Decision API, contains an authorization bypass vulnerability related to improper handling of the X-Forwarded-Proto header. The vulnerability exists because Oathkeeper did not properly respect the serve.proxy.trust_forwarded_headers configuration option (which defaults to false) and would always consider the X-Forwarded-Proto header when evaluating access rules, regardless of configuration settings.

Oathkeeper is commonly deployed behind other components like CDNs, WAFs, or reverse proxies. In such configurations, upstream components might forward requests with a different protocol (HTTP vs. HTTPS) than the original request. The X-Forwarded-Proto header is used to communicate the original protocol, but prior to version 26.2.0, this header was trusted unconditionally.

Critical Impact

An attacker can manipulate the X-Forwarded-Proto header to bypass access control rules by triggering a different rule than intended, potentially gaining unauthorized access to protected resources.

Affected Products

• ORY Oathkeeper versions prior to 26.2.0

Discovery Timeline

• 2026-03-26 - CVE CVE-2026-33495 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33495

Vulnerability Analysis

This vulnerability is classified as CWE-862 (Missing Authorization). The core issue lies in how ORY Oathkeeper handles the X-Forwarded-Proto header during access rule evaluation. Despite having a configuration option serve.proxy.trust_forwarded_headers that should control whether forwarded headers are trusted, the application unconditionally processed the X-Forwarded-Proto header regardless of this setting.

When Oathkeeper is deployed behind reverse proxies, CDNs, or WAFs, these upstream components may forward requests with protocol information in the X-Forwarded-Proto header. Oathkeeper uses this header value to match requests against configured access rules. The failure to respect the trust configuration means an attacker can inject or manipulate this header to influence which access rule gets applied.

For exploitation to be successful, the target installation must have distinct access rules configured for HTTP and HTTPS requests, and the attacker must be able to trigger one rule but not the other. While these preconditions may limit widespread exploitability, the vulnerability represents a significant deviation from expected security behavior.

Root Cause

The root cause is an implementation flaw in the proxy request enrichment logic. The EnrichRequestedURL() function was called without passing the trust configuration parameter, causing it to always process the X-Forwarded-Proto header regardless of the serve.proxy.trust_forwarded_headers setting. This resulted in the trust configuration being effectively ignored during rule matching.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Identifying an Oathkeeper deployment with separate access rules for HTTP and HTTPS
2. Crafting HTTP requests with a manipulated X-Forwarded-Proto header
3. Bypassing intended access controls by causing a different rule to be evaluated

For example, if a sensitive endpoint is protected under HTTPS rules but accessible via HTTP rules, an attacker could add X-Forwarded-Proto: http to their HTTPS request to trigger the less restrictive HTTP rule evaluation path.

 		}
 	}
 
-	EnrichRequestedURL(r)
+	EnrichRequestedURL(r, d.c.ProxyTrustForwardedHeaders())
 	rl, err := d.r.RuleMatcher().Match(r.Out.Context(), r.Out.Method, r.Out.URL, rule.ProtocolHTTP)
 	if err != nil {
 		*r.Out = *r.Out.WithContext(context.WithValue(r.Out.Context(), director, err))

Source: GitHub Commit Details

The patch modifies the proxy handler to pass the ProxyTrustForwardedHeaders() configuration value to the EnrichRequestedURL() function, ensuring the trust setting is properly respected during request processing.

Detection Methods for CVE-2026-33495

Indicators of Compromise

• Unusual or unexpected X-Forwarded-Proto headers in requests that did not originate from trusted reverse proxies
• Access log entries showing protocol mismatches between actual connection protocol and header-indicated protocol
• Authentication or authorization anomalies where users access resources via unexpected rule paths

Detection Strategies

• Monitor incoming HTTP requests for X-Forwarded-Proto headers that contradict the actual connection protocol
• Implement logging at the Oathkeeper level to capture which access rules are being matched for each request
• Review access patterns for resources that have different HTTP and HTTPS access rules to identify potential bypass attempts

Monitoring Recommendations

• Configure upstream WAF or reverse proxy to log and alert on unexpected X-Forwarded-Proto header manipulation attempts
• Enable detailed access logging in Oathkeeper to track rule evaluation and matching behavior
• Set up alerts for access control decisions that don't align with expected patterns based on source protocol

How to Mitigate CVE-2026-33495

Immediate Actions Required

• Upgrade ORY Oathkeeper to version 26.2.0 or later immediately
• Review and audit existing access rules that differentiate between HTTP and HTTPS requests
• Configure upstream components (WAF, CDN, reverse proxy) to strip or normalize X-Forwarded-* headers before forwarding to Oathkeeper
• Verify that the serve.proxy.trust_forwarded_headers configuration is set appropriately for your deployment

Patch Information

ORY has released version 26.2.0 which contains the security fix. The patch ensures that Oathkeeper correctly respects the serve.proxy.trust_forwarded_headers configuration when processing the X-Forwarded-Proto header. Additional technical details are available in the GitHub Security Advisory GHSA-vhr5-ggp3-qq85.

Workarounds

• Drop unexpected X-Forwarded-* headers at the edge of your network (e.g., in your WAF or reverse proxy) before requests reach Oathkeeper
• Consolidate HTTP and HTTPS access rules where possible to eliminate rule differentiation that could be exploited
• Implement additional header validation at upstream components to reject requests with suspicious header combinations

# Configuration example for nginx to strip X-Forwarded-Proto from untrusted sources
# Add to nginx location block before proxying to Oathkeeper
proxy_set_header X-Forwarded-Proto $scheme;
# This overwrites any client-provided X-Forwarded-Proto with the actual scheme