8.7

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-7qjx-gp9h-65qj

GHSA-7qjx-gp9h-65qj: Dex: Token-exchange endpoint is missing AllowedConnectors enforcement

Summary

server/handlers.go::handleTokenExchange (lines 1804-1893) does not call isConnectorAllowed(client.AllowedConnectors, connID) before issuing tokens, while sibling handlers do. This is a per-client connector ACL gap on the token-exchange endpoint; the redirect-flow paths enforce the same field correctly.

Affected code path

handleTokenExchange reads connector_id from the request body at server/handlers.go:1822. Validators called between read and token issuance:

s.getConnector(ctx, connID) at line 1836 - confirms connector exists
GrantTypeAllowed(conn.GrantTypes, grantTypeTokenExchange) at line 1842 - confirms connector permits this grant
(missing) isConnectorAllowed(client.AllowedConnectors, connID) - never called

Tokens are issued at lines 1887 / 1889, bound to client.ID carrying claims derived from connID.

Sibling handlers DO enforce the check:

server/handlers.go::handleConnectorLogin:377 - calls isConnectorAllowed, returns HTTP 403 "Connector not allowed for this client." (line 380).
server/oauth2.go::parseAuthorizationRequest:535 - same enforcement for the authorization-code flow.

The doc-string at storage/storage.go:192-194 reads:

AllowedConnectors is a list of connector IDs that the client is allowed to use for authentication. If empty, all connectors are allowed.

The phrasing is unconditional - a permission ACL, not a UX filter.

Impact (concrete scenario)

Connector corp-okta - high-trust, gates production access
Connector dev-google - low-trust, internal Gmail
Client dev-app configured with (admin intent: dev-app only sees dev-google identities)

Miggo Vulnerability Database

→

GHSA-7qjx-gp9h-65qj

GHSA-7qjx-gp9h-65qj:

8.7

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/dexidp/dex	go	< 0.0.0-20260303131938-204dbb2e3ff7	0.0.0-20260303131938-204dbb2e3ff7

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability lies in the handleTokenExchange function, which is part of the token exchange flow in Dex. This function is supposed to validate that a client is authorized to use a specific identity connector before issuing a new token. However, a crucial check is missing. While other authentication flows in Dex correctly verify the allowed connectors for a client using the isConnectorAllowed function, handleTokenExchange does not. This allows an attacker who has compromised a client's secret to bypass the intended security policy. By sending a crafted token exchange request with a connector_id for a high-privilege connector, the attacker can obtain a token with elevated permissions. The vulnerable function was identified directly from the detailed vulnerability description, which pinpointed the exact function and the missing security check. Although the provided commit patch was incorrect, the description was sufficient to determine the vulnerable function with high confidence.

Vulnerable functions

handleTokenExchange

server/handlers.go

The function `handleTokenExchange` is responsible for handling OAuth 2.0 token exchanges. It receives a `connector_id` from the client but fails to verify if the client is authorized to use the specified connector. This allows an attacker with a leaked client secret to use any connector, even those not allowed for the client, to mint new tokens. This can lead to privilege escalation if a high-trust connector is used.