Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-7x63-xv5r-3p2x
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_routesor 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-Uriheader at the reverse proxy or load balancer level -
Explicitly overwrite
X-Forwarded-Uriwith the actual request URI before forwarding requests to OAuth2 ProxyExample 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-regexrules where possible
Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.
Drag and drop some file here, or click to select
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
- CVE-2026-40575
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.
Alias, EPSS 0.73% - EUVD-2026-24557Alias
- EUVD-2026-65061Alias
- CVE-2026-76835
OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.
Alias, EPSS 0.73%
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard