CVE-2026-55377 in logto
Summary
by MITRE • 07/10/2026
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in Logto prior to version 1.41.0 represents a critical authentication bypass flaw that undermines the security of multi-factor authentication mechanisms within the platform's Account Center functionality. This weakness stems from an overly permissive verification check implementation where the system accepted any active verification record belonging to the current user with the isVerified flag set to true, regardless of the verification method or context. The flaw specifically affected the step-up authentication process that should have required proof of possession of existing credentials before allowing users to manage their MFA factors.
The technical exploitation of this vulnerability relies on the WebAuthn registration verification mechanism, which allows attackers to create and verify new passkey registrations using only an existing Account API bearer token. This token serves as the sole credential for generating a verification record that can be submitted through the logto-verification-id header. The system's failure to properly validate the origin and context of verification records means that any valid verification record, regardless of how it was obtained, could be used to elevate privileges within the Account Center routes, effectively bypassing the need for legitimate authentication proof.
This vulnerability creates significant operational impact by allowing unauthorized access to MFA factor management capabilities without proper authentication proof. An attacker who has obtained a valid bearer token can essentially perform account takeovers or privilege escalation attacks by adding new passkeys to an account without demonstrating possession of existing credentials such as passwords, identifiers, or current MFA factors. The implications extend beyond simple account compromise to potential broader access within the SaaS and AI application ecosystem that Logto protects.
The security flaw aligns with CWE-287 (Improper Authentication) and represents a violation of the principle of least privilege in authentication systems. From an ATT&CK framework perspective, this vulnerability maps to T1566 (Phishing) and T1078 (Valid Accounts) where attackers can leverage stolen tokens to bypass multi-factor authentication requirements. The issue specifically demonstrates poor input validation and insufficient verification context checking, which are fundamental security controls that should prevent such authentication bypass scenarios. Organizations using Logto versions prior to 1.41.0 should immediately implement mitigation strategies including immediate token revocation for affected users, enforcement of stronger verification context checks, and implementation of additional authentication layers before allowing MFA factor management operations. The fix in version 1.41.0 addresses this by implementing proper verification record validation that considers the origin and context of verification requests rather than accepting any active verified record.