Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

redhat логотип

CVE-2026-40575

Опубликовано: 21 апр. 2026
Источник: redhat
CVSS3: 8.7

Описание

OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 may trust a client-supplied X-Forwarded-Uri header when --reverse-proxy is enabled and --skip-auth-regex or --skip-auth-route is configured. An attacker can spoof this header so OAuth2 Proxy evaluates authentication and skip-auth rules against a different path than the one actually sent to the upstream application. This can result in an unauthenticated remote attacker bypassing authentication and accessing protected routes without a valid session. Impacted users are deployments that run oauth2-proxy with --reverse-proxy enabled and configure at least one --skip-auth-regex or --skip-auth-route rule. This issue is patched in v7.15.2. Some workarounds are available for those who cannot upgrade immediately. Strip any client-provided X-Forwarded-Uri header at the reverse proxy or load balancer level; explicitly overwrite X-Forwarded-Uri with the actual request URI before forwarding requests to OAuth2 Proxy; restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy; and/or remove or narrow --skip-auth-regex / --skip-auth-route rules where possible. For nginx-based deployments, ensure X-Forwarded-Uri is set by nginx and not passed through from the client.

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.

Отчет

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.

Меры по смягчению последствий

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/; }
  1. Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy;
  2. Remove or narrow --skip-auth-route / --skip-auth-regex rules where possible;

Затронутые пакеты

ПлатформаПакетСостояниеРекомендацияРелиз
Red Hat Ceph Storage 9rhceph/oauth2-proxy-rhel9Affected

Показывать по

Дополнительная информация

Статус:

Important
Дефект:
CWE-290
https://bugzilla.redhat.com/show_bug.cgi?id=2460449oauth2-proxy: github.com/oauth2-proxy/oauth2-proxy: OAuth2 Proxy: Authentication bypass due to spoofed X-Forwarded-Uri header

8.7 High

CVSS3

Связанные уязвимости

CVSS3: 9.1
nvd
4 месяца назад

OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 may trust a client-supplied `X-Forwarded-Uri` header when `--reverse-proxy` is enabled and `--skip-auth-regex` or `--skip-auth-route` is configured. An attacker can spoof this header so OAuth2 Proxy evaluates authentication and skip-auth rules against a different path than the one actually sent to the upstream application. This can result in an unauthenticated remote attacker bypassing authentication and accessing protected routes without a valid session. Impacted users are deployments that run oauth2-proxy with `--reverse-proxy` enabled and configure at least one `--skip-auth-regex` or `--skip-auth-route` rule. This issue is patched in `v7.15.2`. Some workarounds are available for those who cannot upgrade immediately. Strip any client-provided `X-Forwarded-Uri` header at the reverse proxy or load balancer level; explicitly overwrite `X-Forwarded-Uri` with the actual reque

CVSS3: 9.1
debian
4 месяца назад

OAuth2 Proxy is a reverse proxy that provides authentication using OAu ...

CVSS3: 9.1
github
4 месяца назад

OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing

8.7 High

CVSS3