{"vuid":"VU#492466","idnumber":"492466","name":"Logto Identity Platform has authentication and authorization failures in core protocol handling","keywords":null,"overview":"### Overview\r\nThe 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.\r\n\r\n### Description\r\nDeveloped 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.\r\n\r\n**CVE-2026-15611**\r\nLogto 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.  \r\n\r\n**CVE-2026-15612**\r\nLogto 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.\r\n\r\n**CVE-2026-15614**\r\nLogto 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. \r\n\r\n**CVE-2026-15615**\r\nLogto'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. \r\n\t\r\n**CVE-2026-15616**\r\nLogto'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. \r\n\t\r\n**CVE-2026-15617**\r\nLogto 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. \r\n\r\n### Impact\r\nCollectively, 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.\r\n\r\n### Solution\r\n\r\n#### Mitigations \r\nUnfortunately, 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:\r\n* \tWhere 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.\r\n* \tAvoid using Logto’s “social SAML” connector entirely.  \r\n* \tRequire MFA at the upstream IdP for all federated sign‑ins.  \r\n* \tEnforce strict domain normalization at the IdP or provisioning layer.  \r\n* \tShorten session lifetimes and aggressively invalidate sessions.  \r\n* \tMonitor authentication logs for anomalies.  \r\n* \tPlace Logto behind an identity‑aware reverse proxy.  \r\n\r\n### Acknowledgements\r\nThanks to the reporting team:\r\nZixu (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.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/libraries/verification-helpers/single-sign-on-guard.ts#L23-L33","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/routes/experience/classes/experience-interaction.ts#L538-L540","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/sso/SamlConnector/utils.ts#L175-L205","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/connectors/connector-saml/src/utils.ts#L46-L110","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/libraries/verification-helpers/single-sign-on.ts#L81-L99","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/sso/OidcConnector/utils.ts#L175-L182","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/libraries/verification-helpers/single-sign-on.ts#L274","https://github.com/logto-io/logto/blob/ea3ede35028dfd0bbb6d7b239623ce0e7f6cdff8/packages/core/src/routes/experience/classes/verifications/enterprise-sso-verification.ts#L284-L297"],"cveids":["CVE-2026-15617","CVE-2026-15616","CVE-2026-15615","CVE-2026-15614","CVE-2026-15612","CVE-2026-15611"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-07-23T15:40:37.189275Z","publicdate":"2026-07-23T15:40:36.972328Z","datefirstpublished":"2026-07-23T15:40:37.211938Z","dateupdated":"2026-07-23T15:40:36.972324Z","revision":1,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":224}