CVE-2026-76835 — oauth2-proxy
CVE-2026-76835 is a 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 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- 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.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-76835.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
github.com/oauth2-proxy/oauth2-proxy/v7Real-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_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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/oauth2-proxy/oauth2-proxy/v7 | ≥ 7.5.0&&< 7.15.2 | 7.15.2go get github.com/oauth2-proxy/oauth2-proxy/v7@v7.15.2 |
Detection & mitigation playbook
Open-source dependencyDetect
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.
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-76835 is resolved across your whole dependency graph.
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.
This vulnerability is rated as Important severity as an unauthenticated remote attacker can bypass authentication checks to access protected upstream services without authorization. The issue occurs when OAuth2 Proxy operates in reverse proxy mode with route-skipping rules enabled and lacks an explicitly restricted…
To mitigate this issue without patching, apply one of the following configuration controls: 1. Restrict trusted proxy IP addresses in OAuth2 Proxy: Explicitly set the `--trusted-proxy-ip` command-line argument (or the `trusted_proxy_ip` configuration file parameter) to the specific IP address or CIDR range of authorized upstream reverse proxies or load balancers rather than relying on the default: ``` --trusted-proxy-ip=<TRUSTED_PROXY_IP_OR_CIDR> ``` 2. Sanitize forwarded headers at the perimeter reverse proxy: Configure intermediate ingress controllers or front-facing reverse proxies (such as NGINX) to strip client-supplied `X-Forwarded-Uri` headers or overwrite them with the actual…Source: Red Hat security advisory for CVE-2026-76835 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | oauth2-proxy-main-7.15.5-0.1.hum1 | RHSA-2026:74536 |
Frequently Asked Questions
Is CVE-2026-76835 in your dependencies?
Find it across Go, including transitive dependencies.