GHSA-5HVV-M4W4-GF6V

Vulnerability from github – Published: 2026-04-14 22:31 – Updated: 2026-04-15 21:06
VLAI?
Summary
OAuth2 Proxy's Health Check User-Agent Matching Bypasses Authentication in auth_request Mode
Details

Impact

A configuration-dependent authentication bypass exists in OAuth2 Proxy.

Deployments are affected when all of the following are true:

  • OAuth2 Proxy is used with an auth_request-style integration (for example, nginx auth_request)
  • --ping-user-agent is set or --gcp-healthchecks is enabled

In affected configurations, OAuth2 Proxy will treat a request with the configured health check User-Agent value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.

This issue does not affect deployments that do not use auth_request-style subrequests, or that do not enable --ping-user-agent/--gcp-healthchecks.

Patches

Users should upgrade to v7.15.2 or later once available. Deployments running versions prior to v7.15.2 should be considered affected if they use auth_request-style authentication together with --ping-user-agent or --gcp-healthchecks.

Workarounds

Users can mitigate this issue by:

  • disabling --gcp-healthchecks
  • removing any configured --ping-user-agent
  • ensuring the reverse proxy does not forward client-controlled User-Agent headers to the OAuth2 Proxy auth subrequest
  • using path-based health checks only, on dedicated health check endpoints

Example nginx mitigation for the auth subrequest:

location = /oauth2/auth {
    internal;
    proxy_pass http://127.0.0.1:4180;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header Host $host;
    # set to value that isn't the same as your configured PingUserAgent or GCPs "GoogleHC/1.0"
    proxy_set_header User-Agent "oauth2-proxy-auth-request";
}
Severity ?
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oauth2-proxy/oauth2-proxy/v7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oauth2-proxy/oauth2-proxy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34457"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T22:31:19Z",
    "nvd_published_at": "2026-04-14T23:16:28Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\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 used with an `auth_request`-style integration   (for example, nginx `auth_request`)\n- `--ping-user-agent` is set or `--gcp-healthchecks` is enabled\n\nIn affected configurations, OAuth2 Proxy will treat a request with the configured health check `User-Agent` value as a successful health check regardless of the requested path. This allows an unauthenticated remote attacker to bypass authentication and access protected upstream resources without completing the normal login flow.\n\nThis issue does not affect deployments that do not use `auth_request`-style subrequests, or that do not enable  `--ping-user-agent`/`--gcp-healthchecks`.\n\n### Patches\nUsers should upgrade to `v7.15.2` or later once available. Deployments running versions prior to `v7.15.2` should be considered affected if they use `auth_request`-style authentication together with `--ping-user-agent` or  `--gcp-healthchecks`.\n\n### Workarounds\nUsers can mitigate this issue by:\n\n- disabling `--gcp-healthchecks`\n- removing any configured `--ping-user-agent`\n- ensuring the reverse proxy does not forward client-controlled `User-Agent`  headers to the OAuth2 Proxy auth subrequest\n- using path-based health checks only, on dedicated health check endpoints\n\nExample nginx mitigation for the auth subrequest:\n\n```nginx\nlocation = /oauth2/auth {\n    internal;\n    proxy_pass http://127.0.0.1:4180;\n    proxy_pass_request_body off;\n    proxy_set_header Content-Length \"\";\n    proxy_set_header Host $host;\n    # set to value that isn\u0027t the same as your configured PingUserAgent or GCPs \"GoogleHC/1.0\"\n    proxy_set_header User-Agent \"oauth2-proxy-auth-request\";\n}\n```",
  "id": "GHSA-5hvv-m4w4-gf6v",
  "modified": "2026-04-15T21:06:37Z",
  "published": "2026-04-14T22:31:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-5hvv-m4w4-gf6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34457"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/releases/tag/v7.15.2"
    }
  ],
  "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\u0027s Health Check User-Agent Matching Bypasses Authentication in auth_request Mode"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.



Detection rules are retrieved from Rulezet.