CVE-2026-40575

Description

A flaw was found in OAuth2 Proxy. When configured with --reverse-proxy and either --skip-auth-regex or --skip-auth-route, the proxy may trust a client-supplied X-Forwarded-Uri header. An unauthenticated remote attacker can exploit this by spoofing the header, leading to an authentication bypass. This allows unauthorized access to protected routes without a valid session.

Statement

There's an Important flaw in oauth2-proxy software where it trusts a client supplied X-Forwarded-Uri request header. This header is used by oauth2-proxy to identify the original URI from the incoming request it's currently handling. An attacker which manages to spoof the requests sent to it when it's running behind a reverse-proxy may change this header field to match the routes or the regular expressions configured to have authentication skipped, as a consequence the attacker may manage to have access to protected resources or internal routes without any kind of authentication being required resulting in a high impact for data confidentiality and integrity for the services positioned behind the reverse proxy.

Red Hat Product Security team has rated this vulnerability as having a impact of Important as for a oauth2-proxy being considered vulnerable it should be being executed with the following specific configuration options enabled:

  1. --reverse-proxy
  2. --skip-auth-regex or --skip-auth-route

Additionally to exploit this vulnerability the attacker should be able to change the headers in the request being sent (either via a local proxy or by performing a Man-In-The-Middle attack before) and should have previous knowledge about the routes or patterns of URI which the authentication are being skipped by the oauth2-proxy deployment.

Mitigation

This issue can be mitigated by one of the options bellow:

1) Strip any client-provided `X-Forwarded-Uri` header at any layer before it reaches `oauth2-proxy`;
2) Overwrite the `X-Forwarded-Uri` header with the actual request URI before the request reaches `oauth2-proxy`. If you are using NGINX you can use the following example to create your tailored mitigation:

  location /internal-auth/ {
internal; # Ensure external users can't access this path

# Make sure the OAuth2 Proxy knows where the original request came from.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# set the value to the actual $request_uri and therefore strip any user provided X-Forwarded-Uri
proxy_set_header X-Forwarded-Uri $request_uri;

proxy_pass http://oauth2-proxy:4180/;
}

3) Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy;
4) Remove or narrow --skip-auth-route / --skip-auth-regex rules where possible;

Common Vulnerability Scoring System (CVSS) Score Details

Info alert:Important note

CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).

The following CVSS metrics and score provided are preliminary and subject to review.

CVSS v3 Score Breakdown

Red HatNVDcve.org
Base Score8.7N/A8.7
Attack VectorNetworkN/ANetwork
Attack ComplexityHighN/AHigh
Privileges RequiredNoneN/ANone
User InteractionNoneN/ANone
ScopeChangedN/AChanged
ConfidentialityHighN/AHigh
Integrity ImpactHighN/AHigh
Availability ImpactNoneN/ANone

Vector

Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

cve.org: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

Understanding the Weakness (CWE)

Access Control

Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity

This weakness can allow an attacker to access resources which are not otherwise accessible without proper authentication.

Frequently Asked Questions

Want to get errata notifications? Sign up here.