Overview

The Logto platform contains multiple vulnerabilities affecting the identity‑processing pipeline. These flaws reduce the reliability of authentication and authorization decisions and may allow attackers to bypass account‑ownership checks, skip MFA, replay externally issued SSO responses, or submit identity assertions without proper cryptographic or validity checks. Collectively, the issues create several paths for unauthorized access across both local and federated sign‑in flows.

Description

Developed by Silverhand Inc., Logto is an identity and access management system for software as a service (SaaS) and AI applications. It provides multi‑tenant authentication, single sign-on (SSO), role-based access control (RBAC), support for openId connect (OIDC), open authorization (OAuth) 2.1, and Security Assertion Markup Language (SAML) authentication. Several vulnerabilities have been identified in Logto's authentication and SSO components that weaken core identity‑security protections across these protocols.

CVE-2026-15611
Logto allows unverified email-based SSO account linking. If a new SSO login arrives and no existing (issuer, identityId) account is found, Logto searches for a local user by the email address supplied by the identity provider (IdP) and links the SSO identity to that account. Logto does not require the IdP to confirm email_verified before linking, so an attacker who registers the victim's email at a permissive upstream IdP can take over the victim's existing account on first login.

CVE-2026-15612
Logto stores a nonce in the connector session at authorization request time and expects the returned id_token to echo it back. The validation check is guarded by if (data.nonce), so when an id_token omits the nonce claim entirely, the check is skipped, even when nonceFromSession is set.

CVE-2026-15614
Logto does not atomically handle IdP-initiated SAML sessions. Session lookup and session deletion are two separate steps, and because the lookup response is returned before the deletion finishes, any deletion errors are silently discarded. Two requests presenting the same session identifier in close succession can both pass the lookup before either deletion completes, allowing the same IdP-initiated assertion to authorize two separate sign-ins.

CVE-2026-15615
Logto's SAML implementation relies on the samlify library to validate the Conditions element, but samlify's check is bypassed whenever the Conditions element is absent from the assertion. An attacker who omits Conditions from a forged or replayed assertion bypasses the NotBefore and NotOnOrAfter time window check entirely, and Logto adds no independent validation of its own.

CVE-2026-15616
Logto's authentication process does not enforce locally configured multi-factor authentication (MFA) when a user signs in via SSO. MFA is bypassed when hasVerifiedSsoIdentity is true. As a result, an attacker with a federated identity from a permissive upstream IdP can bypass the local MFA requirement by signing in through SSO.

CVE-2026-15617
Logto performs strict, unnormalized comparisons on identity attributes (email domains, issuer identifiers, and identity IDs) during SSO flows. The absence of case, whitespace, and Unicode normalization leads to inconsistent domain‑rule enforcement and incorrect resolution of linked identities, allowing sessions to bind to unintended local accounts.

Impact

Collectively, the vulnerabilities in Logto's authentication and SSO infrastructure fail to implement core identity protections across the OIDC, OAuth 2.1, and SAML protocols. These flaws can interact in ways that allow attackers to evade account‑ownership checks and MFA, replay federated sessions, and inject unvalidated or unsigned identity assertions.

Solution

Mitigations

Unfortunately, Silverhand Inc. could not be reached for coordination of these vulnerabilities. Until a patch is available, administrators can reduce the attack surface by implementing the following defensive measures:
* Where possible, avoid provisioning local accounts with the same email addresses that will be used for federated sign-in, since Logto does not currently expose a setting to disable automatic email-based account linking.
* Avoid using Logto’s “social SAML” connector entirely.
Require MFA at the upstream IdP for all federated sign‑ins.
Enforce strict domain normalization at the IdP or provisioning layer.
Shorten session lifetimes and aggressively invalidate sessions.
Monitor authentication logs for anomalies.
* Place Logto behind an identity‑aware reverse proxy.

Acknowledgements

Thanks to the reporting team:
Zixu (Jason) Zhou (PhD student), Professor David Lie, Ilya Grishchenko (Postdoc), and Xiangyu Guo (PhD student) of the University of Toronto. This AI-assisted vulnerability note was prepared by Laurie Tyzenhaus.

Vendor Information