Logto EUVD-2026-86223

Requires all of: (1) the attacker controls an application holding a valid same-user Logto access token that has only the openid scope; (2) federated token-set storage must be enabled in the Logto tenant; and (3) the victim user must have previously authenticated through a supported social or enterprise-SSO connector so that a provider token is actually stored. It affects Logto versions 1.31.0 through 1.41.x (fixed in 1.42.0). Limiting factors: exploitation is authenticated (PR:L - a token must already be granted to the app), and if federated token-set storage is disabled or the user never used a social/SSO connector, there is no stored token to disclose. The impact is bounded by the upstream provider token's granted scopes.

This is a genuine authorization flaw (CWE-862 missing scope enforcement) with real consequences, but its raw CVSS of 7.6 overstates the ease of exploitation. The provided vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N correctly captures network reach and low-privilege access, but PR:L is important: the attacker must already hold a valid same-user access token (i.e., an OAuth client the user authorized with only the openid scope), so this is authenticated abuse, not open internet exposure. There is no EPSS score, no CISA KEV listing, and no public POC in the provided intelligence, so exploitation is theoretical at analysis time - no public exploit identified at time of analysis. Crucially, the description imposes two hard preconditions (federated token-set storage enabled AND the victim previously authenticated through a supported social/enterprise-SSO connector) that substantially narrow the exploitable population versus what AV:N/AC:L alone implies. The S:C/C:H rating is defensible because the disclosed tokens grant access to a separate security authority (the upstream social/SSO provider). Net: a real, patch-worthy issue for Logto operators using federated token storage, but a targeted/conditional risk rather than a wormable mass-exploitation candidate.

A low-trust OAuth application obtains a same-user Logto access token scoped only to openid (normal for a basic sign-in integration). Instead of being limited to identity display, it calls GET /api/my-account/identities/{target}/access-token (or the SSO variant) and, because the identities-scope check was missing, receives the user's stored Google/enterprise-SSO provider access token - which it then replays against upstream provider APIs within that token's granted scopes. No public exploit code is identified at time of analysis.