CVE-2026-63203: Logto Authentication Bypass Vulnerability

CVE-2026-63203 Overview

Logto is an open-source authentication infrastructure platform used by SaaS and AI applications. CVE-2026-63203 is a missing authorization flaw [CWE-862] in the Logto Account API that affects versions 1.31.0 through 1.41.x. The 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. The affected endpoints are GET /api/my-account/identities/{target}/access-token and GET /api/my-account/sso-identities/{connectorId}/access-token. The handlers authenticate the user but fail to enforce the identities scope that protects neighboring identity-detail operations, bypassing the Account API consent boundary.

Critical Impact
A low-trust application holding only an openid-scoped token can retrieve upstream social or SSO provider access tokens and reuse them against third-party APIs within the granted scopes.

Affected Products

Logto versions 1.31.0 through 1.41.x
Deployments with federated token-set storage enabled
Tenants where users authenticated through supported social or enterprise SSO connectors

Discovery Timeline

2026-09-24 - CVE CVE-2026-63203 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-63203

Vulnerability Analysis

The Account API in Logto exposes endpoints that return stored provider tokens issued by upstream identity providers. These endpoints require the caller to present a user access token. Neighboring identity-detail routes enforce the identities scope as part of the Account API consent model. The third-party token handlers did not perform the same scope check. A client application that only requested the baseline openid scope during authorization could call these endpoints and receive provider access tokens belonging to the authenticated user. The attacker then uses the retrieved token against the original provider's APIs within whatever scopes the user previously granted during federation. Exploitation requires federated token-set storage to be enabled and the targeted user to have authenticated through a supported connector.

Root Cause

The root cause is a missing authorization check [CWE-862] in the third-party token route handlers. The code paths validated the user session but did not require the identities scope on the presented access token. This broke the intended Account API consent boundary, where sensitive identity data should only be released to callers that explicitly requested identity-level consent.

Attack Vector

An attacker registers or controls a Logto client application that only requests the openid scope. A victim authenticates to that application and has previously federated through a social or enterprise SSO connector. The attacker's application calls GET /api/my-account/identities/{target}/access-token or the SSO variant using the same-user token. The response contains a provider access token that the attacker can replay against the upstream provider's APIs.

typescript

// Security patch excerpt - packages/core/src/routes/account/third-party-tokens.ts
+import { UserScope } from '@logto/core-kit';
 import {
   type EnterpriseSsoTokenSetSecret,
   getThirdPartyAccessTokenResponseGuard,
// Source: https://github.com/logto-io/logto/commit/b560d17a4da4c25da95e3c73af4485d18ab7c224
// The fix imports UserScope and enforces the identities scope on third-party token routes.

Detection Methods for CVE-2026-63203

Indicators of Compromise

Requests to /api/my-account/identities/{target}/access-token or /api/my-account/sso-identities/{connectorId}/access-token originating from client applications that only requested openid during authorization.
Unexpected upstream provider API calls using tokens that were issued through Logto-federated flows.
Client applications issuing access-token requests at a rate inconsistent with their declared functionality.

Detection Strategies

Review Logto access logs for calls to the two affected routes and correlate the caller's token scopes with the requested resource.
Flag any token issuance where the authorized scope set does not include identities but the client subsequently reaches third-party token endpoints.
Compare provider-side audit logs with Logto federation events to identify provider token usage that did not originate from an interactive upstream session.

Monitoring Recommendations

Enable structured logging on the Account API and forward events to a SIEM for scope-aware alerting.
Monitor connector-specific provider APIs (for example, Google, Microsoft, Okta) for token reuse patterns associated with federated users.
Track creation of new OIDC client applications and alert when a client with minimal scopes queries identity endpoints.

How to Mitigate CVE-2026-63203

Immediate Actions Required

Upgrade Logto to version 1.42.0 or later, which enforces the identities scope on the affected routes.
Rotate or revoke upstream provider access tokens stored by Logto for users whose accounts may have been exposed to untrusted client applications.
Audit registered OIDC client applications and remove any that are not required or that were granted broader trust than intended.

Patch Information

The fix is included in Logto v1.42.0. The code change is tracked in GitHub Pull Request #9116 and committed in commit b560d17. Full details are published in GHSA-6g9q-qrx7-3jxf.

Workarounds

Disable federated token-set storage until the upgrade can be deployed, which removes the provider tokens that the vulnerable endpoints return.
Restrict which client applications are allowed to authenticate users who have federated through sensitive SSO connectors.
Require the identities scope at the authorization server for any client that legitimately needs third-party token retrieval, and reject requests without it at a proxy layer.

bash

# Upgrade Logto to the patched release
npm install @logto/core@1.42.0
# Or, for container deployments:
docker pull svhd/logto:1.42.0
docker compose up -d