Dex improper authorization in token-exchange endpoint

Severity: high · CVSS 8.7 · Published 2026-06-09

Dex is an identity service that uses 'connectors' to let users log in via different providers like Google or Okta. A security flaw in the token-exchange feature allows a client application to bypass administrator-defined restrictions on which login providers it is allowed to use. If a client's secret is leaked, an attacker could use it to obtain high-privilege identity tokens from unauthorized providers, potentially gaining access to sensitive production systems.

Technologies: github.com/dexidp/dex (Go). Vendors: Go.

Quick answers

Is This vulnerability exploited in the wild?
No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
How severe is This vulnerability?
High severity, with a CVSS score of 8.7, published 9 June 2026.
Which products and versions are affected?
Dexidp Dex < 0.0.0-20260303131938-204dbb2e3ff7; github.com/dexidp/dex (Go) < 0.0.0-20260303131938-204dbb2e3ff7.
Is there a fix for This vulnerability?
A patch was published on 2026-06-09: Fix reviewed and finalized in GitHub Advisory Database Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is This vulnerability attacked?
It is attacked over the network, in a software library.
Am I affected?
Check whether you run Dexidp Dex or github.com/dexidp/dex (Go) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

Technical details

The `handleTokenExchange` function in `server/handlers.go` fails to call `isConnectorAllowed` before issuing tokens, creating an authorization bypass. While other authentication flows correctly enforce the `AllowedConnectors` ACL defined in the client configuration, the token-exchange path only verifies that the connector exists and supports the grant type. An attacker with a leaked client secret and a valid token from a 'forbidden' connector can successfully exchange it for a Dex-signed token for that client. This allows for privilege escalation where a low-trust client can impersonate identities from high-trust connectors (e.g., Okta) that were explicitly restricted by policy. The vulnerability was introduced in the development branch and is fixed in commit 204dbb2.

Affected products

  • dexidp Dex < 0.0.0-20260303131938-204dbb2e3ff7

Timeline

  • 2026-03-03: other: Last unaffected stable release v2.45.1
  • 2026-03-11: other: Vulnerability introduced in master branch via PR #4610
  • 2026-05-20: disclosed: Advisory published by maintainers
  • 2026-06-09: patched: Fix reviewed and finalized in GitHub Advisory Database

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.