Summary
| Parameter | Value |
|---|---|
| CVE ID | CVE-2026-76835 |
| Alert Source | GitHub Advisory - critical vulnerability (CNA: VulnCheck) |
| CVE Publication Year | 2026 |
| Date Published | 2026-08-24 |
| Vendor | OAuth2 Proxy (open source project) |
| Product | oauth2-proxy |
| Affected versions | every release left with the default --trusted-proxy-ip, including the current 7.15.4 |
| Fixed version | none — configuration change required |
| CVSS Score | 9.3 (Critical, CVSS v4); 9.1 under CVSS v3.1 |
| EPSS Score | No data (CVE published 2026-08-24) |
| CISA KEV | No |
| Ransomware | Not confirmed |
Vulnerability Description
OAuth2 Proxy is a widely used authentication layer placed in front of applications that cannot
authenticate users themselves — most often as nginx auth_request or via the auth-url
annotation in Kubernetes ingress-nginx. It is the component that decides whether a request
reaches the application at all.
With --reverse-proxy enabled, GetRequestURI (pkg/requests/util/util.go) prefers the
X-Forwarded-Uri header over the real request URI. isAllowedPath in oauthproxy.go then
matches that header against the --skip_auth_routes and --skip-auth-regex allow list. The
result: an attacker supplies a header path that is on the allow list while the actual request
targets a protected resource — and passes through with no session.
The same mechanism was already published as CVE-2026-40575, fixed in release 7.15.2 by
introducing the --trusted-proxy-ip flag. The point of CVE-2026-76835 is that the fix is
inert in the default configuration: CanTrustForwardedHeaders
(pkg/apis/middleware/scope.go) trusts forwarded headers when the caller’s address is in the
trusted proxy list, and that list, left unset, defaults to 0.0.0.0/0 — everyone. The
behaviour was kept deliberately, for backwards compatibility.
Consequently an installation upgraded to 7.15.2, 7.15.3 or 7.15.4 remains vulnerable until an administrator explicitly sets the trusted addresses. No release resolves this — the only remediation is a configuration change.
Preconditions (all must hold):
- OAuth2 Proxy running with
--reverse-proxy, - at least one
--skip_auth_routesor--skip-auth-regexrule defined, --trusted-proxy-ipunset or too broad,- no overwrite of
X-Forwarded-Uriat the load balancer layer.
Required Actions
- Set
--trusted-proxy-ipexplicitly to the addresses or CIDR ranges of the reverse proxies and load balancers permitted to sendX-Forwarded-*headers. This is the primary mitigation. - Strip any client-supplied
X-Forwarded-Uriheader at the edge — in the load balancer or reverse proxy — and overwrite it with the actual request URI before forwarding to OAuth2 Proxy. - Review your
--skip_auth_routesand--skip-auth-regexrules. Every exemption is a potential bypass path; broad patterns (^/api/.*) are far more dangerous than specific paths. - Upgrade to at least 7.15.2 so that the
--trusted-proxy-ipflag exists at all — but the upgrade alone does not remove the vulnerability without step 1. - Check logs for requests carrying a client-set
X-Forwarded-Uriwhose path diverges from the actual request target.
Who Is Affected?
Organisations protecting internal applications with an OAuth2 Proxy layer — in practice teams running Kubernetes clusters and exposing tools that have no login of their own through ingress: Grafana, Kibana, Prometheus, Argo CD, admin consoles and internal applications. This is a standard pattern in SaaS companies, fintechs and e-commerce, and increasingly in the internal platforms of large organisations.
The impact is out of proportion to the simplicity of the attack: bypassing the authentication layer means direct access to tools usually considered “internal, therefore safe” — tools that hold metrics, logs, secrets and deployment pipelines.
Pay particular attention to installations that were already patched in April 2026 because of CVE-2026-40575. Teams that closed the ticket then are still vulnerable, because the fix requires a deliberate configuration change, not just a version bump.
Sources
- NVD - CVE-2026-76835
- OAuth2 Proxy - GHSA-7x63-xv5r-3p2x (CVE-2026-40575)
- OAuth2 Proxy - issue #3506
- OAuth2 Proxy - repository
Need help securing your systems? nFlo team offers vulnerability management and 24/7 SOC services. Contact us.
