CVE-2026-63203 in Logto
Summary
by MITRE • 09/24/2026
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. From 1.31.0 until 1.42.0, the Account API handlers in packages/core/src/routes/account/third-party-tokens.ts allow a caller holding a same-user access token with only the openid scope to retrieve stored social or enterprise SSO provider access tokens through GET /api/my-account/identities/{target}/access-token or GET /api/my-account/sso-identities/{connectorId}/access-token. The handlers authenticate the user but do not require the identities scope that protects neighboring identity-detail operations, bypassing the intended Account API consent boundary. Exploitation requires federated token-set storage to be enabled and the affected user to have authenticated through a supported connector. A low-trust application can use the disclosed provider token against upstream APIs within that token's granted scopes. This issue is fixed in version 1.42.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in Logto versions ranging from 1.31.0 to 1.42.0 represents a critical authorization bypass within the Account API infrastructure, specifically affecting how third-party and single sign-on tokens are managed. This flaw stems from an insufficient access control mechanism where the system fails to enforce strict scope-based permissions for retrieving sensitive authentication artifacts. In modern identity management systems like Logto, which serves as auth infrastructure for SaaS and AI applications, the separation of concerns between different types of user data is paramount. The Account API handlers located in packages/core/src/routes/account/third-party-tokens.ts were designed to manage tokens obtained through federated login providers such as social logins or enterprise identity connectors. However, the implementation allowed any authenticated user holding a valid access token with only the openid scope to retrieve stored provider access tokens via specific endpoints: GET /api/my-account/identities/{target}/access-token and GET /api/my-account/sso-identities/{connectorId}/access-token. This behavior contradicts standard security practices where retrieval of sensitive credential material should require explicit, high-trust scopes such as identities or profile management permissions that are typically required for neighboring identity-detail operations.
From a technical perspective, the core issue is an authorization logic error rather than a code injection or memory corruption flaw. The server-side handlers correctly authenticate the user by validating their access token but fail to verify whether the scope of that token permits the specific action of retrieving stored third-party tokens. By allowing retrieval with just the openid scope, which is generally intended for basic profile information and not sensitive credential storage, the system effectively bypasses its own consent boundaries. This misconfiguration means that a low-trust application, one that has been granted minimal permissions by the user during an OAuth or OIDC flow, can exploit this endpoint to extract access tokens issued by upstream identity providers like Google, GitHub, Microsoft Azure AD, or Okta. The exploitation requires two conditions: first, federated token-set storage must be enabled in the Logto configuration, and second, the target victim user must have previously authenticated through one of these supported connectors. Once obtained, an attacker can use these disclosed provider tokens to impersonate the user against upstream APIs within the scopes granted by those providers, potentially leading to unauthorized access to email accounts, cloud storage, enterprise directories, or other integrated services linked to that identity provider.
The operational impact of this vulnerability is severe due to its potential for account takeover and lateral movement across trusted ecosystems. An attacker leveraging a compromised low-trust application can pivot from the initial point of entry into Logto to access high-value resources protected by external identity providers. This aligns with common attack patterns described in industry frameworks, specifically mapping to CWE-269: Improper Privilege Management, as the system grants privileges beyond what is necessary for the requested operation based on insufficient scope validation. Furthermore, this behavior facilitates unauthorized data access and can be categorized under ATT&CK technique T1550: Use Alternate Authentication Credentials, where an adversary uses stolen or forged credentials to gain initial access or maintain persistence. The ability to extract these tokens allows for session hijacking-like scenarios without needing the user's password, as the attacker possesses a valid bearer token that upstream services trust implicitly. This undermines the principle of least privilege and compromises the integrity of federated identity chains, potentially exposing sensitive personal data or corporate secrets depending on which SSO provider was used.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary and most effective mitigation is to upgrade Logto to version 1.42.0 or later, where this authorization bypass has been patched by enforcing stricter scope requirements for token retrieval endpoints. For organizations unable to immediately patch, implementing a Web Application Firewall rule to block requests to the affected API paths with low-trust scopes can provide temporary relief, though this is not a substitute for code-level fixes. Additionally, administrators should review their Logto configuration to ensure that federated token storage is only enabled when strictly necessary and consider rotating all stored third-party tokens after patching to invalidate any potentially compromised credentials issued during the vulnerable window. Future development efforts should focus on implementing granular scope validation at every API endpoint level, ensuring that sensitive operations like credential retrieval are explicitly gated behind high-privilege scopes such as identities or admin-level permissions, thereby preventing similar authorization bypasses in other parts of the application logic.