CVE-2026-76835: OAuth2 Proxy 7.15.2 through 7.15.4 Authentication Bypass via X-Forwarded-Uri Under the Default Trusted Proxy Set
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.
Security readout for executives and security teams
Plain-English summary
OAuth2 Proxy can be tricked into treating a protected request as publicly allowed. In affected reverse-proxy deployments, an unauthenticated internet user may bypass login and reach sensitive upstream functions or data. The stated impact is loss of confidentiality and integrity, making exposed deployments an immediate business risk.
Executive priority
Treat as an immediate remediation priority where affected OAuth2 Proxy instances protect sensitive services. Quickly identify internet-facing deployments, constrain trusted proxies, sanitize forwarding headers, and follow the vendor advisory for a supported fix. Prioritize systems exposing administrative, customer, financial, or regulated data.
Technical view
Versions 7.15.2 through 7.15.4 may trust a client-supplied X-Forwarded-Uri when reverse-proxy mode uses the default trusted-proxy set. That default covers all IPv4 and IPv6 addresses. Authentication exemptions are evaluated against the spoofable URI, while the upstream receives the original protected path.
Likely exposure
Exposure requires OAuth2 Proxy 7.15.2 through 7.15.4, reverse-proxy mode without trusted_proxy_ip configured, and relevant skip_auth_routes or skip_auth_regex rules. Risk is greatest when untrusted clients can send X-Forwarded-Uri through the network edge to OAuth2 Proxy.
Exploitation context
The bypass is remotely reachable, requires no account or user interaction, and has low stated complexity. The bundle reports CVSS 4.0 score 9.3. It does not identify CISA KEV listing or provide evidence of active exploitation, so exploitation in the wild should not be claimed.
Researcher notes
The bypass spans URI selection, skip-auth matching, and an allow-all default trusted-proxy set. The bundle title and description state versions 7.15.2 through 7.15.4, but its structured affected entry lists only 7.15.2. Confirm the authoritative version range and fixed release with the vendor advisory before closing remediation.
Mitigation direction
Check the vendor advisory immediately for the supported fixed release or official remediation.
Configure trusted_proxy_ip to include only actual, controlled reverse proxies.
Have the trusted edge remove or overwrite client-supplied X-Forwarded-Uri headers.
Review and minimize skip_auth_routes and skip_auth_regex entries until remediation is complete.
Validation and detection
Inventory every OAuth2 Proxy instance and confirm its exact deployed version.
Identify instances using reverse-proxy mode without an explicit trusted_proxy_ip setting.
Review skip-auth route and regular-expression rules for paths that could authorize protected requests.
Verify each ingress layer removes or replaces untrusted X-Forwarded-Uri values before forwarding.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-290: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
3Timeline events
1ADP providers
6Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: yesTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.