Dex Flaw Bypasses Connector ACLs on Token Exchange Endpoint

A high-severity vulnerability has been discovered in Dex, a widely used open-source identity service. The flaw allows an attacker to bypass access control lists that restrict which identity providers a client application can use. This enables privilege escalation by exchanging a token from one provider for a new token with claims from another, unauthorized provider [1]. The issue was identified by security researcher Matteo Panzeri.

The Threat to Agentic Systems

Dex often serves as the central authentication hub in Kubernetes and other cloud-native environments. These same environments increasingly host automated and agentic systems, from CI/CD pipelines to complex AI workloads. These agents are frequently configured as OAuth clients within Dex, each with its own credentials and defined permissions.

This vulnerability directly undermines the security boundaries designed to contain such agents. The `AllowedConnectors` feature in Dex is a critical tool for enforcing the principle of least privilege. It ensures an application, or an agent acting as one, can only authenticate users from specific, trusted identity sources. When this control fails, it creates a dangerous path for privilege escalation.

A compromised agent, holding a leaked client secret, could exploit this flaw. An attacker could use the agent's identity to mint tokens associated with a high-privilege human user. This blurs the lines between machine and human identity, breaking the trust model that secures the entire system. For autonomous systems, which operate without direct human oversight, such a flaw can lead to a complete security breakdown.

Attack Scenario Explained

The attack requires two preconditions. First, the attacker must obtain the client secret of a confidential OAuth client in Dex. Second, the attacker must possess a valid identity token for themselves from an identity provider that the target client is forbidden from using.

Consider a setup with two identity connectors. A low-trust `dev-google` connector is for developer sandboxes, while a high-trust `corp-okta` connector gates access to production systems. An administrator configures a `dev-app` client with `allowedConnectors: ["dev-google"]`, explicitly forbidding it from using Okta identities.

If the `dev-app` client secret leaks, an attacker can initiate the token exchange grant type. They send a request to the Dex token endpoint, providing the leaked secret for `dev-app`. Critically, they also specify `connector_id=corp-okta` and provide their own personal Okta token as the `subject_token`.

Because of the vulnerability, Dex fails to check if `dev-app` is allowed to use the `corp-okta` connector. It validates the attacker's Okta token and issues a new Dex token. This new token is for the `dev-app` audience but contains the group claims and identity information from the attacker's high-privilege Okta profile. Any downstream service that trusts tokens for `dev-app` will now grant the attacker access based on their powerful, but forbidden, Okta identity [2].

A Missing Validation Check

The root cause is a missing line of code in a single function. The `handleTokenExchange` function in the `server/handlers.go` file does not call the `isConnectorAllowed` validator before issuing a token. This function is responsible for ensuring the client application is permitted to use the requested identity connector.

Other code paths in Dex that handle authentication, such as the standard login flow, correctly perform this check. The presence of the check in sibling handlers demonstrates that its absence in the token exchange flow was an oversight. This type of logic bug, a missing security check, is often difficult for automated static analysis tools to detect.

The fix involves adding the `isConnectorAllowed` check to the `handleTokenExchange` function. This ensures the client's configured connector restrictions are enforced across all authentication grant types. The patch was merged into the master branch, closing the security gap for future builds [3].

Limited Impact on Production Systems

The vulnerability's impact is fortunately limited by its history. The flaw was introduced in a commit to the master branch and has not been included in any stable, tagged release of Dex. Organizations running official releases like v2.45.1 are not affected by this specific issue [1].

The only affected deployments are those pulling directly from Dex's master branch or using nightly builds created after March 11, 2026. While this is not a common production practice, development and staging environments may be vulnerable. Administrators of such environments should apply the patch immediately to prevent potential misuse.