ORY Oathkeeper is an Identity & Access Proxy that authorizes HTTP requests based on configured access rules, often deployed behind CDNs, WAFs, or reverse proxies. It relies on the X-Forwarded-Proto header to determine the original request protocol when requests are forwarded through intermediaries. The configuration option serve.proxy.trust_forwarded_headers controls whether Oathkeeper should trust this and other X-Forwarded-* headers, defaulting to false for security. However, versions prior to 26.2.0 contained a vulnerability (CVE-2026-33495) where Oathkeeper always trusted the X-Forwarded-Proto header regardless of this setting. This flaw could be exploited if an attacker can send requests with manipulated X-Forwarded-Proto headers and if the deployment has distinct access rules for HTTP versus HTTPS requests. By spoofing this header, an attacker might bypass authorization checks by triggering a less restrictive rule. The vulnerability is classified under CWE-862 (Missing Authorization). Exploitation does not require authentication or user interaction, but the attack surface is limited by the need for specific configuration and rule sets. The patch in version 26.2.0 ensures Oathkeeper respects the trust_forwarded_headers setting, preventing unauthorized header trust. It is recommended to upgrade even if the preconditions are not met, as a best practice. Additionally, dropping unexpected or untrusted headers early in the request processing chain (e.g., via WAF or reverse proxy) can further reduce risk.

If exploited, this vulnerability could allow unauthorized users to bypass access control rules in ORY Oathkeeper by manipulating the X-Forwarded-Proto header, potentially gaining access to resources that should be restricted. The impact on confidentiality and integrity is limited to the scope of the affected access rules, which must be distinct for HTTP and HTTPS. There is no direct impact on availability. Since the vulnerability requires specific configurations and attacker capabilities, the overall risk is moderate. However, in environments where Oathkeeper protects sensitive APIs or services with differentiated rules, unauthorized access could lead to data exposure or privilege escalation. Organizations relying on Oathkeeper for critical access control should consider this a significant risk until patched. The absence of known exploits in the wild reduces immediate threat but does not eliminate the risk of future attacks.

1. Upgrade ORY Oathkeeper to version 26.2.0 or later immediately to ensure the vulnerability is patched and the trust_forwarded_headers configuration is respected. 2. Review and simplify access rules to avoid distinct rules based solely on HTTP vs HTTPS protocol, reducing the attack surface. 3. Configure upstream components such as CDNs, WAFs, and reverse proxies to drop or sanitize unexpected or untrusted X-Forwarded-* headers early in the request processing pipeline. 4. Implement strict validation and normalization of incoming headers before they reach Oathkeeper. 5. Monitor logs for unusual or suspicious usage of the X-Forwarded-Proto header or access patterns that could indicate attempts to exploit this vulnerability. 6. Conduct security reviews of proxy and header trust configurations regularly to ensure they align with best practices. 7. Educate DevOps and security teams about the risks of trusting forwarded headers without proper validation.