GHSA-7X63-XV5R-3P2X

Vulnerability from github – Published: 2026-04-15 19:21 – Updated: 2026-07-21 13:50
VLAI
Summary
OAuth2 Proxy has an Authentication Bypass via X-Forwarded-Uri Header Spoofing
Details

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

Show details on source website

{
  "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": "2026-04-22T00:16:27Z",
    "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-07-21T13:50:15Z",
  "published": "2026-04-15T19:21:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40575"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-40575"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2460449"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-40575.json"
    }
  ],
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.

Loading…

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…