Cracked shield icon with the OAuth2 Proxy logo, a "protection disabled" badge, and a stalled patch progress bar, illustrating the unresolved authentication bypass vulnerability CVE-2026-76835

OAuth2 Proxy’s April Auth-Bypass Fix Didn’t Work: And Nobody’s Patched It Yet

A newly disclosed critical flaw shows an April fix for OAuth2 Proxy’s login-bypass bug didn’t stick.

A critical bug in OAuth2 Proxy, an open-source authentication tool believed to be patched in April, is still open to authentication bypass attacks. On Monday, a second critical warning, tracked as CVE-2026-76835, confirmed that for over four months anyone who followed patching advice for the original bug CVE-2026-40575, has been vulnerable to attack.

A workaround fix is available, a proof-of-concept attack has been published and there are no reports of active exploitation of the bug in the wild.  As of publication, there is no dedicated patch for this specific issue.

Beyond the Break weekly cybersecurity newsletter — Subscribe

The bug affecting OAuth2 Proxy, an open-source tool used to add authentication in front of internal dashboards, admin panels, and APIs across the cloud-native world, still allows an adversary to bypass login entirely by spoofing a trusted header.

The attack vector is low. The adversary does not need credentials, an account, insider access, or special tooling beyond a single crafted HTTP header. Crafting the attack takes one extra line in a common command-line tool, as demonstrated in the proof-of-concept researcher George Chen published alongside his August disclosure of CVE-2026-76835.

A researcher with a user name of iamnoooob is credited for the initial April discovery (CVE-2026-40575).

What OAuth2 Proxy Is and Is Not

OAuth2 Proxy isn’t the login system behind a bank’s website or your email. Those run their own dedicated authentication. It’s a lightweight tool companies use internally, to add a login requirement to tools that don’t come with one built in, like an engineering dashboard or an admin panel.

A successful exploit doesn’t just open a dashboard — it opens whatever that dashboard was built to control. Depending on the tool behind the gate, that could mean customer data, internal infrastructure, or even the controls used to deploy and manage production systems. And because OAuth2 Proxy is often the only thing standing between the public internet and these tools, bypassing it isn’t a partial compromise — it’s the whole gate coming off its hinges.

OAuth2 Proxy sits in front of an application and decides who gets through. Some paths — like a health check or a public status page — are allowed to skip login entirely, using a setting called skip_auth_routes.

The bug lets an attacker fake the path OAuth2 Proxy checks. By sending a request for a protected page (say, /admin) while attaching a header claiming the request is actually for a public page, an attacker tricks OAuth2 Proxy into approving it. Meanwhile, the real, protected request goes through to the backend untouched.

In a working proof-of-concept published alongside the report, a request for /admin returns access denied normally. The identical request with one spoofed header returns the protected page in full, no login required.

Timeline

In April, OAuth2 Proxy believed it fixed the critical bug, CVE-2026-40575. The fix included upgrading to OAuth2 Proxy v. 7.15.2 and also added a new setting, “–trusted-proxy-ip”. That was meant to stop the software from trusting a header unless it came from a known, trusted source.

A new critical warning (CVE-2026-76835) was issued Monday confirming Chen’s research that the April patch never protected most users. The same attack still works today, on the current version, four months and two releases after the ‘fix’ shipped.

The workaround

Because there’s no patch yet, the fix is a configuration change, not an upgrade:

  1. Set –trusted-proxy-ip to the actual IP address or address range of your load balancer or reverse proxy — never leave it blank.
  2. Strip the X-Forwarded-Uri header at the edge, before it reaches OAuth2 Proxy, so nothing a client sends can be trusted directly. The maintainers’ own example for the nginx web server does this by overwriting the header with the real request path.
  3. Don’t expose OAuth2 Proxy directly to the internet — only through the trusted proxy in front of it.
  4. Review skip_auth_routes rules and tighten any broad, wildcard-style patterns.

This applies regardless of which version you’re running. The setting has existed since April, and the fix is the same whether you’re on the newest release or not.

Total
0
Shares
Previous Article
Illustration of Pi Security turning a flood of software vulnerabilities into organized security knowledge for a human analyst.

Pi Security Wants to Teach AI How Security Experts Think

Related Posts

Discover more from Security Point Break

Subscribe now to keep reading and get access to the full archive.

Continue reading