CVE-2026-33495

Ory Oathkeeper has an authentication bypass by usage of untrusted header

MEDIUM
6.5
CVSS Score
Published: March 26, 2026 at 05:26 PM UTC
Updated: June 17, 2026 at 10:37 AM UTC
1 product affected across 1 vendorOathkeeper

Using oathkeeper by ory?

Get instant alerts when new vulnerabilities affect oathkeeper - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM6.5
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

ORY Oathkeeper is an Identity & Access Proxy (IAP) and Access Control Decision API that authorizes HTTP requests based on sets of Access Rules. 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. Prior to version 26.2.0, Oathkeeper did not properly respect this configuration, and would always consider the `X-Forwarded-Proto` header. 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. Version 26.2.0 contains a patch. 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. As an additional mitigation, it is generally recommended to drop any unexpected headers as early as possible when a request is handled, e.g. in the WAF.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 26.2.0
Affected range stops below 26.2.0, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

References (2)

SSVC — Action Prioritization

SSVCNo known exploitAutomatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

6.5MEDIUMGitHub_M
Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
LOW
Integrity
LOW
Availability
NONE
Vector?

Quick Info

StatusANALYZED
CWE
CWE-862

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card