Suse
CVE-2026-33495
MEDIUM
GHSA-vhr5-ggp3-qq85
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Description
Ory Oathkeeper is often deployed behind other components like CDNs, WAFs, or reverse proxies. Depending on the setup, another component might forward the request to the Oathkeeper proxy with a different protocol (http vs. https) than the original request. In order to properly match the request against the configured rules, Oathkeeper considers the X-Forwarded-Proto header when evaluating rules. The configuration option serve.proxy.trust_forwarded_headers (defaults to false) governs whether this and other X-Forwarded-* headers should be trusted. Oathkeeper did not properly respect this configuration, and would always consider the X-Forwarded-Proto header.
Preconditions
In order for an attacker to abuse this, an installation of Ory Oathkeeper needs to have distinct rules for HTTP and HTTPS requests. Also, the attacker needs to be able to trigger one but not the other rule. In this scenario, the attacker can send the same request but with the X-Forwarded-Proto header in order to trigger the other rule. We do not expect many configurations to meet these preconditions.
Mitigation
It is generally recommended to drop any unexpected headers as early as possible when a request is handled, e.g. in the WAF.
Ory Oathkeeper will correctly respect the serve.proxy.trust_forwarded_headers configuration going forward, thereby eliminating the attack scenario. We recommend upgrading to a fixed version even if the preconditions are not met.
AnalysisAI
Ory Oathkeeper improperly trusts the X-Forwarded-Proto header regardless of the serve.proxy.trust_forwarded_headers configuration setting, allowing attackers to bypass protocol-based access controls. This affects deployments of pkg:go/github.com_ory_oathkeeper where distinct HTTP and HTTPS rules are configured, enabling an attacker to craft requests with spoofed X-Forwarded-Proto headers to trigger unintended authorization rules. A vendor patch is available and exploitation requires specific preconditions (protocol-differentiated rules and ability to trigger one rule but not the other), limiting real-world impact despite the CVSS 6.5 score.
Technical ContextAI
Ory Oathkeeper is a reverse proxy and API gateway written in Go (CPE: pkg:go/github.com_ory_oathkeeper) that enforces authorization rules on incoming HTTP requests. The vulnerability stems from improper implementation of the X-Forwarded-Proto header handling—a standard header used when requests pass through intermediate proxies (CDNs, WAFs, load balancers) that may terminate TLS and forward traffic over HTTP internally. The root cause is classified under CWE-862 (Missing Authorization), as the proxy failed to enforce its explicit configuration parameter governing trust in forwarded headers. The bug causes Oathkeeper to always evaluate the X-Forwarded-Proto header when matching rules against request attributes, bypassing the intended access control decision that should only occur when trust_forwarded_headers is explicitly enabled. This creates an inconsistency between configuration intent and runtime behavior in the rule-matching engine.
RemediationAI
Upgrade Ory Oathkeeper to a version that includes the fix from commit e9acca14a04d246250557550065e4b4576525bd5 or later; consult the GitHub repository at https://github.com/ory/oathkeeper/security/advisories/GHSA-vhr5-ggp3-qq85 for the specific patched release version. As an immediate mitigation before patching is feasible, configure upstream WAFs, load balancers, or reverse proxies to explicitly drop the X-Forwarded-Proto header (and other X-Forwarded-* headers) if they are not legitimately required, following the vendor's guidance to strip unexpected headers as early as possible in the request handling pipeline. If protocol-differentiated rules are not in use, the preconditions for exploitation are not met, but upgrading is still recommended for defense-in-depth. Verify that serve.proxy.trust_forwarded_headers is set to false in Oathkeeper configuration unless explicit trust in forwarded headers is operationally necessary.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Medium| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today