NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
CRITICAL severity

CVE-2026-40575 — oauth2-proxy

CRITICAL

CVE-2026-40575 is a critical-severity (CVSS 9.1) CWE-290 vulnerability in github.com/oauth2-proxy/oauth2-proxy/v7. A fix is available for github.com/oauth2-proxy/oauth2-proxy/v7 — see the affected versions and patch details below.

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

Also known asBIT-oauth2-proxy-2026-40575BIT-oauth2-proxy-2026-76835CVE-2026-76835GHSA-7x63-xv5r-3p2xGO-2026-5236
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40575.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs41th percentile — riskier than 41% of all scored CVEsHighest risk
0.00%0.41%0.82%1.23%0.1%0.5%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐹github.com/oauth2-proxy/oauth2-proxy/v7

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/oauth2-proxy/oauth2-proxy/v7≥ 7.5.0&&< 7.15.27.15.2go get github.com/oauth2-proxy/oauth2-proxy/v7@v7.15.2

Affected Products

1 product · 1 configurations
Application
oauth2 proxyoauth2_proxy_project
≥ 7.5.0 && < 7.15.2
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/oauth2-proxy/oauth2-proxy/v7, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/oauth2-proxy/oauth2-proxy/v7 to 7.15.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40575 is resolved across your whole dependency graph.

  3. Workarounds

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

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…

Workaround published by Red Hat
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…
Source: Red Hat security advisory for CVE-2026-40575 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Hardened Imagesoauth2-proxy-main-7.15.4-0.1.hum1RHSA-2026:58471

Frequently Asked Questions

### 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 s
O3 Security · Impact-Aware SCA

Is CVE-2026-40575 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-40575: oauth2-proxy — Fixed in 7.15.2