Executive brief
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.
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