GHSA-C5C4-8R6X-56W3

Vulnerability from github – Published: 2026-04-15 19:23 – Updated: 2026-04-15 19:23
VLAI?
Summary
OAuth2 Proxy has an Authorization Bypass in Email Domain Validation via Malformed Multi-@ Email Claims
Details

Impact

An authorization bypass exists in OAuth2 Proxy as part of the email_domain enforcement option. An attacker may be able to authenticate with an email claim such as attacker@evil.com@company.com and satisfy an allowed domain check for company.com, even though the claim is not a valid email address.

The issue ONLY affects deployments that rely on email_domain restrictions and accept email claim values from identity providers or claim mappings that do not strictly enforce normal email syntax. The practical risk ONLY exists in self-hosted or custom OIDC environments and federated setups where unexpected claim values can reach oauth2-proxy. Standard hosted providers that enforce valid email formatting ARE NOT effected.

Patches

Users should upgrade to v7.15.2 or later once available.

Workarounds

The most effective workaround is to ensure the configured identity provider cannot emit malformed or attacker-controlled email claim values.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/oauth2-proxy/oauth2-proxy/v7"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.15.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-15T19:23:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn authorization bypass exists in OAuth2 Proxy as part of the `email_domain` enforcement option. An attacker may be able to authenticate with an email claim such as `attacker@evil.com@company.com` and satisfy an allowed domain check for `company.com`, even though the claim is not a valid email address.\n\nThe issue **ONLY** affects deployments that rely on `email_domain` restrictions and accept email claim values from identity providers or claim mappings that do not strictly enforce normal email syntax. The practical risk ONLY exists in self-hosted or custom OIDC environments and federated setups where unexpected claim values can reach oauth2-proxy. Standard hosted providers that enforce valid email formatting ARE NOT effected.\n\n### Patches\nUsers should upgrade to `v7.15.2` or later once available.\n\n### Workarounds\nThe most effective workaround is to ensure the configured identity provider cannot emit malformed or attacker-controlled email claim values.",
  "id": "GHSA-c5c4-8r6x-56w3",
  "modified": "2026-04-15T19:23:54Z",
  "published": "2026-04-15T19:23:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-c5c4-8r6x-56w3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OAuth2 Proxy has an Authorization Bypass in Email Domain Validation via Malformed Multi-@ Email Claims"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…