[CVE-2025-54576] OAuth2-Proxy skip_auth_routes Lets Attackers Walk Straight Past the Login Screen

TL;DR
OAuth2-Proxy’s skip_auth_routes directive was supposed to exempt only a handful of public endpoints from authentication. In versions up to 7.10.0 the regular expression is evaluated against the entire request URI, including query strings. Attackers can simply append a matching parameter to any protected route and the proxy believes the user is already authenticated. Upgrading to 7.11.0 or anchoring your regular expressions fixes the issue.

1. Summary

The flaw lets unauthenticated clients hit internal dashboards, APIs and admin consoles simply by adding a query parameter that matches the configured regular expression. Impact depends on what sits behind the proxy but ranges from data exfiltration to complete account takeover.

2. Context – Why a proxy misconfiguration ripples through entire clusters

OAuth2-Proxy is the de-facto standard side-car that upgrades insecure legacy applications with single sign-on capabilities. Helm charts for Argocd, Grafana, Prometheus and dozens of in-house services enable the proxy with one line of YAML. Administrators often add a skip_auth_routes regex so that health checks and static assets load unauthenticated, for instance:

skip_auth_routes: [ "^/public/.*", "^/metrics$", "^/healthz$" ]

Until now many operators assumed the proxy would test the pattern against the request path only. In reality the earlier versions compare it to the full URI including the query string. That means a URL such as:

https://example.com/admin?metrics

matches the second pattern above even though the path in question is /admin. Any back-end that ignores the superfluous metrics parameter happily serves its most sensitive content.

3. Technical Details – How the regular expression check went wrong

The affected code lives in oauthproxy.go:

if util.StringAtLeastOneMatchesRegex(req.URL.String(), o.SkipAuthRegex) {
    middleware.Next(ctx)
    return
}

req.URL.String() returns the entire URI, scheme excluded. When a request like /admin?metrics arrives, the string handed to the matcher is /admin?metrics. The proxy therefore thinks the request refers to /metrics, because the regex engine sees the substring metrics and declares a match.

The patched release replaces the call with req.URL.Path, ensuring only /admin is evaluated:

if util.StringAtLeastOneMatchesRegex(req.URL.Path, o.SkipAuthRegex) {
    middleware.Next(ctx)
    return
}

The maintainers also recommend anchoring every pattern with ^ and $ so that even future mistakes cannot widen the match window.

Proof-of-concept request

No special tooling is needed. Replace /protected with any route that requires authentication and /healthz with a skip_auth_routes entry:

curl -k "https://proxy.example.com/protected?healthz"

On a vulnerable setup the proxy returns HTTP 200 without issuing any OAuth redirect, proving that the check short-circuited.

4. Impact – From stolen dashboards to compromised production data

Most deployments sit in front of Prometheus, Grafana, Kibana or bespoke APIs that expect the proxy to enforce user identity. By bypassing the proxy, an attacker can read or modify monitoring metrics, extract application secrets, trigger destructive operations or promote themselves to cluster admin roles depending on the back-end. Confidentiality and integrity are rated High under CVSS, availability is untouched because the bug does not enable DoS.

5. Remediation – Upgrade or harden your patterns

Upgrade to OAuth2-Proxy 7.11.0 or newer. Container images are available on the project’s Docker Hub and Go modules have been tagged.

If an immediate upgrade is impossible, review every skip_auth_routes value:

• Anchor paths with ^ at the beginning and $ at the end, for example ^/metrics$ rather than /metrics.
• Remove wildcard constructs such as .* unless strictly necessary.
• Consider stripping query parameters before you run custom route validation logic.

Firewalling the proxy so that only a bastion host can reach it offers an extra safety net but is rarely feasible for public-facing services.

6. Timeline

7. References

• GitHub advisory: https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7rh7-c77v-6434
• Patch commit: https://github.com/oauth2-proxy/oauth2-proxy/commit/9ffafad4b2d2f9f7668e5504565f356a7c047b77
• Release notes v7.11.0: https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v7.11.0
• Source code showing vulnerable logic: https://github.com/oauth2-proxy/oauth2-proxy/blob/f4b33b64bd66ad28e9b0d63bea51837b83c00ca1/oauthproxy.go#L582-L584

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the traditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score Fits With CVSS, EPSS and KEV

At the time of writing:

• This CVE is scored at 9.1 using CVSS 3.1, reflecting the ease of exploitation and high confidentiality and integrity impact. CVSS offers a precise technical severity assessment but does not weigh exploit availability or business context.
• EPSS has not yet published a probability score for this vulnerability, which is common during the first 24 hours of disclosure.
• CISA’s KEV catalogue does not list the CVE, meaning US federal agencies are not under a binding directive to patch within a fixed window.

The Volerion Risk Score blends these factors with additional signals such as product popularity, threat actor chatter and patch effort. For CVE-2025-54576 the score stands at 7.5, placing it in our high-risk band.