NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹 Go
Not in CISA KEV

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

Also known asBIT-oauth2-proxy-2026-40575BIT-oauth2-proxy-2026-76835CVE-2026-40575GHSA-7x63-xv5r-3p2xGO-2026-5236
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs39th percentile — riskier than 39% of all scored CVEsHighest risk
0.00%0.32%0.64%0.95%0.3%0.5%0.5%0.5%Sep 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐹github.com/oauth2-proxy/oauth2-proxy/v7

Real-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_routes or 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-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

    Example 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-regex rules where possible

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/oauth2-proxy/oauth2-proxy/v7≥ 7.5.0&&< 7.15.27.15.2go get github.com/oauth2-proxy/oauth2-proxy/v7@v7.15.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

Red HatImportant

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…

Workaround published by Red Hat
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)
ProductFixed inAdvisory
Red Hat Hardened Imagesoauth2-proxy-main-7.15.5-0.1.hum1RHSA-2026:74536

Frequently Asked Questions

### 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_routes` or 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 s
O3 Security · Impact-Aware SCA

Is CVE-2026-76835 in your dependencies?

Find it across Go, including transitive dependencies.

CVE-2026-76835: oauth2-proxy — Fixed in 7.15.2