Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/dexidp/dex < 0.0.0-20260303131938-204dbb2e3ff7
Fixed in
0.0.0-20260303131938-204dbb2e3ff7· Vendor fix available
Issue
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 connectorid 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…
Recommended action: Upgrade to 0.0.0-20260303131938-204dbb2e3ff7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/dexidp/dex >= 2.37.0, <= 2.37.0; < 0.0.0-20240125115555-5bbdb4420254
Fixed in
0.0.0-20240125115555-5bbdb44202542.38.0· Vendor fix available
Issue
Dex 2.37.0 is serving HTTPS with insecure TLS 1.0 and TLS 1.1. Details While working on https://github.com/dexidp/dex/issues/2848 and implementing configurable TLS support, I noticed my changes did not have any effect in TLS config, so I started investigating. https://github.com/dexidp/dex/blob/70d7a2c7c1bb2646b1a540e49616cbc39622fb83/cmd/dex/serve.go#L425 is seemingly setting TLS 1.2 as minimum version, but the whole tlsConfig is ignored after "TLS cert reloader" was introduced in https://github.com/dexidp/dex/pull/2964. Configured cipher suites are not respected either, as seen on the output. PoC Build Dex, generate certs with gencert.sh, modify config.dev.yaml to run on https, using generated certs. Run dex bin/dex serve config.dev.yaml. Install sslyze, easy to use SSL connection analyzer: In Dex 2.37.0, TLS 1.0 and TLS 1.1 are enabled in addition to expected TLS 1.2 and TLS 1.3. In Dex 2.36.0, TLS 1.0 and TLS 1.1 are disabled as expected. Impact TLS 1.0 and TLS 1.1…
Recommended action: Upgrade to 2.38.0 or 0.0.0-20240125115555-5bbdb4420254 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Dex instances with public clients (and by extension, clients accepting tokens issued by those Dex instances) are affected by this vulnerability. An attacker can exploit this vulnerability by making a victim navigate to a malicious website and guiding them through the OIDC flow, stealing the OAuth authorization code in the process. The authorization code then can be exchanged by the attacker for a token, gaining access to applications accepting that token. Steps to reproduce 1) A victim navigates to a malicious website 2) The webserver initiates a connection with a Dex instance directly - https://dexexample.com/auth/https:%252F%252Faccounts.google.com?accesstype=online&clientid=example&nonce=2AaJAimQU9CbeOFsNra1d7CJTWB&redirecturi=http%3A%2F%2Flocalhost%3A40393%2Fauth%2Fcallback&responsetype=code&scope=openid+email&state=2AaJAjhpUmsB25csCo5muvorMTl. In this example, the Dex instance is hosted on dexexample.com, and the connector is accounts.google.com. 3) Dex returns a 302…
Recommended action: Upgrade to 2.35.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The following vulnerabilities have been disclosed, which impact users leveraging the SAML connector: Signature Validation Bypass (CVE-2020-15216): https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-q547-gmf8-8jr7 encoding/xml instabilities: - Element namespace prefix instability (CVE-2020-29511) - Attribute namespace prefix instability (CVE-2020-29509) - Directive comment instability (CVE-2020-29510) Patches Immediately update to Dex v2.27.0. Workarounds There are no known workarounds.
Recommended action: Upgrade to 2.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability exists in the SAML connector of the github.com/dexidp/dex library used to process SAML Signature Validation. This flaw allows an attacker to bypass SAML authentication. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. This flaw affects dex versions before 2.27.0.
Recommended action: Upgrade to 2.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.