EUVD-2026-43012Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Network-reachable and low-complexity but needs an existing valid bearer token (PR:L); impact is chiefly integrity of MFA/account settings (I:H) with only incidental confidentiality (C:L).
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Authentication step-up bypass in Logto self-hosted auth infrastructure prior to 1.41.0 lets an already-authenticated user manage MFA factors without re-proving their identity. The Account Center accepted any of the user's own verified records - including a self-created WebAuthn passkey-registration record - as proof of identity verification, so an attacker holding only a valid Account API bearer token could forge the logto-verification-id header and satisfy step-up checks. No public exploit identified at time of analysis, and it is not listed in CISA KEV; the flaw is fixed in 1.41.0.
Technical ContextAI
Logto is an open-source OIDC/OAuth identity provider for SaaS and AI applications. The Account Center exposes self-service account routes (including MFA factor management) that require a 'step-up' re-verification: the client obtains a verification record and passes its ID in the logto-verification-id header, and the route treats the request as identityVerified=true. The root cause is CWE-287 (Improper Authentication): the step-up check only confirmed that a verification record belonged to the current user and had isVerified === true, without confirming the record's TYPE proved possession of an existing credential. Because a WebAuthn registration flow for binding a *new* passkey also produces an isVerified record, it could be minted using nothing more than the current session's Account API bearer token, then replayed as if it were a genuine re-authentication.
RemediationAI
Vendor-released patch: upgrade Logto to version 1.41.0 or later, which corrects the step-up check to require a verification record that actually proves possession of an existing credential rather than accepting any isVerified record (see PR #9110 and commit f56255a). Apply the upgrade per the release notes at https://github.com/logto-io/logto/releases/tag/v1.41.0 and advisory GHSA-q4h3-38gc-4p4j. If you cannot upgrade immediately, reduce exposure by restricting or monitoring Account Center MFA-management routes, shortening Account API bearer token lifetimes and tightening session/token protections to limit an attacker's window, and reviewing audit logs for unexpected MFA factor changes; these are stop-gaps that do not close the underlying bypass and the fixed release remains the only complete remediation.
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today