Summary
CVE-2026-76835 is a critical authentication bypass vulnerability (CWE-290: Authentication Bypass by Spoofing) affecting oauth2-proxy, an open-source reverse proxy that authenticates requests via OAuth2/OIDC providers. It allows an unauthenticated attacker to reach a protected upstream path by spoofing the X-Forwarded-Uri header so it matches an allow-listed (skip-auth) route. The flaw carries a CVSS score of 9.3 (Critical) and represents an incomplete fix for the earlier advisory GHSA-7×63-xv5r-3p2x (CVE-2026-40575).
Technical details
- Root cause: In
--reverse-proxymode, oauth2-proxy evaluates itsskip_auth_routes/skip_auth_regexallow-list against the client-suppliedX-Forwarded-Uriheader rather than the actual request path, whenever the requesting source is considered a "trusted proxy." - Trigger conditions:
--reverse-proxyis enabled, at least one skip-auth rule is configured, and--trusted-proxy-ipis left unset — in which case oauth2-proxy falls back to a default trusted-proxy set of0.0.0.0/0and::/0, meaning every client is treated as trusted. - Attack vector: Network, unauthenticated, low complexity — an attacker simply sends a request to a protected path while setting
X-Forwarded-Urito a value matching a skip-auth route. - Impact: The auth check passes based on the spoofed header, while the real, protected path is forwarded unchanged to the upstream application, resulting in unauthorized access to protected resources (high confidentiality and integrity impact).
Affected software
- oauth2-proxy versions 7.15.2 through 7.15.4, when deployed with
--reverse-proxyand skip-auth rules, and with--trusted-proxy-ipleft at its default/unset value.
Severity
- CVSS v3.1 Base Score: 9.1 (Critical), consistent with the closely related predecessor issue; the CVE record for this specific issue is rated 9.3 (Critical) under CVSS v4.0 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N).
Mitigation and recommended actions
- Immediate: No dedicated patched release beyond v7.15.4 has been confirmed at this time; monitor the oauth2-proxy GitHub repository/release notes for a fix that hardens the default trusted-proxy behavior and upgrade as soon as it is available.
- Workarounds:
- Explicitly configure
--trusted-proxy-ipto a restrictive set of legitimate proxy IP ranges rather than leaving it unset. - Strip or overwrite any client-supplied
X-Forwarded-Uriheader at the load balancer/edge before it reaches oauth2-proxy. - Minimize or eliminate
--skip-auth-route/--skip-auth-regexrules where feasible. - Restrict direct client access to oauth2-proxy so it is only reachable through trusted reverse proxies.
- Explicitly configure

