GHSA-7X63-XV5R-3P2X
Vulnerability from github – Published: 2026-04-15 19:21 – Updated: 2026-04-15 19:21Impact
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_routesor 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-Uriheader at the reverse proxy or load balancer level - Explicitly overwrite
X-Forwarded-Uriwith 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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/oauth2-proxy/oauth2-proxy/v7"
},
"ranges": [
{
"events": [
{
"introduced": "7.5.0"
},
{
"fixed": "7.15.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40575"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-15T19:21:06Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\n\nA configuration-dependent authentication bypass exists in OAuth2 Proxy.\n\nDeployments are affected when all of the following are true:\n\n* OAuth2 Proxy is configured with `--reverse-proxy`\n* and at least one rule is defined with `--skip_auth_routes` or the legacy `--skip-auth-regex`\n\nOAuth2 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.\n\nThis can result in an unauthenticated remote attacker bypassing authentication and accessing protected routes without a valid session.\n\n\n### Patches\nThis 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.\n\n### Mitigation\n\n- Strip any client-provided `X-Forwarded-Uri` header at the reverse proxy or load balancer level\n- Explicitly overwrite `X-Forwarded-Uri` with the actual request URI before forwarding requests to OAuth2 Proxy\n\n Example nginx mitigation for the auth subrequest:\n ```\n location /internal-auth/ {\n internal; # Ensure external users can\u0027t access this path\n \n # Make sure the OAuth2 Proxy knows where the original request came from.\n proxy_set_header Host $host;\n proxy_set_header X-Real-IP $remote_addr;\n # set the value to the actual $request_uri and therefore strip any user provided X-Forwarded-Uri\n proxy_set_header X-Forwarded-Uri $request_uri;\n \n proxy_pass http://oauth2-proxy:4180/;\n }\n ```\n- Restrict direct client access to OAuth2 Proxy so it can only be reached through a trusted reverse proxy\n- Remove or narrow `--skip-auth-route` / `--skip-auth-regex` rules where possible",
"id": "GHSA-7x63-xv5r-3p2x",
"modified": "2026-04-15T19:21:06Z",
"published": "2026-04-15T19:21:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x"
},
{
"type": "PACKAGE",
"url": "https://github.com/oauth2-proxy/oauth2-proxy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.