Skip to main content

Nginx CVE-2026-40575

CRITICAL
Authentication Bypass by Spoofing (CWE-290)
2026-04-15 https://github.com/oauth2-proxy/oauth2-proxy GHSA-7x63-xv5r-3p2x
9.1
CVSS 3.1 · Vendor: https://github.com/oauth2-proxy/oauth2-proxy
Share

Severity by source

Vendor (https://github.com/oauth2-proxy/oauth2-proxy) PRIMARY
9.1 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Red Hat
8.7 HIGH
qualitative

Primary rating from Vendor (https://github.com/oauth2-proxy/oauth2-proxy).

CVSS VectorVendor: https://github.com/oauth2-proxy/oauth2-proxy

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

2
Patch released
Apr 15, 2026 - 20:30 nvd
Patch available
CVE Published
Apr 15, 2026 - 19:21 nvd
CRITICAL 9.1

DescriptionCVE.org

Impact

A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

  • OAuth2 Proxy is configured with --reverse-proxy
  • and at least one rule is defined with --skip_auth_routes or the legacy --skip-auth-regex

OAuth2 Proxy may trust a client-supplied X-Forwarded-Uri header when --reverse-proxy is enabled and --skip-auth-route or --skip-auth-regex 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.

Patches

This issue is addressed as part of the newly introduced --trusted-proxy-ip flag in v7.15.2. If you leave it unset, OAuth2 Proxy will continue to trust ALL source IPs (0.0.0.0/0) for backwards compatibility, which means a client may still be able to spoof forwarded headers. Therefore after upgrading we urge you to use the new --trusted-proxy-ip flag to set the IPs or CIDR ranges of the reverse proxies that are allowed to send X-Forwarded-* headers and furthermore implement the mitigation steps outlined below to properly configure your load balancer infrastructure.

Mitigation

  • 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

Example nginx mitigation for the auth subrequest:

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

Analysis

Impact

A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

  • OAuth2 Proxy is configured with --reverse-proxy
  • and at least one rule is defined with --skip_auth_routes or the legacy --skip-auth-regex

OAuth2 Proxy may trust a client-supplied X-Forwarded-Uri header when --reverse-proxy is enabled and --skip-auth-route or --skip-auth-regex 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.

Patches

This issue is addressed as part of the newly introduced --trusted-proxy-ip flag in v7.15.2. If you leave it unset, OAuth2 Proxy will continue to trust ALL source IPs (0.0.0.0/0) for backwards compatibility, which means a client may still be able to spoof forwarded headers. Therefore after upgrading we urge you to use the new --trusted-proxy-ip flag to set the IPs or CIDR ranges of the reverse proxies that are allowed to send X-Forwarded-* headers and furthermore implement the mitigation steps outlined below to properly configure your load balancer infrastructure.

Mitigation

  • 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

Example nginx mitigation for the auth subrequest:

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

More in Nginx

View all
CVE-2013-2028 HIGH POC
7.5 Jul 20

The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau

CVE-2025-1974 CRITICAL POC
9.8 Mar 25

A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access

CVE-2013-4547 HIGH POC
7.5 Nov 23

nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap

CVE-2023-50919 CRITICAL POC
9.8 Jan 12

An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability

CVE-2017-7529 HIGH
7.5 Jul 13

Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi

CVE-2016-0742 HIGH
7.5 Feb 15

The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid

CVE-2025-1098 HIGH POC
8.8 Mar 25

Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress

CVE-2025-24514 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres

CVE-2025-1097 HIGH POC
8.8 Mar 25

A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c

CVE-2022-31137 CRITICAL POC
9.8 Jul 08

Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8

CVE-2014-3556 MEDIUM
6.8 Dec 29

The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and

CVE-2026-42945 CRITICAL POC
9.2 May 13

Heap buffer overflow in NGINX Plus and NGINX Open Source ngx_http_rewrite_module allows remote attackers to crash worker

Vendor StatusVendor

Share

CVE-2026-40575 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy