Logto CVE-2026-55377: WebAuthn Flaw Lets Hackers Bypass MFA Step-Up Security
Potheeswaran 
A newly disclosed vulnerability in Logto’s open-source identity platform shows how a single conflated boolean can undo an entire authentication safeguard.
Tracked as CVE-2026-55377 and rated High severity (CVSS 3.1: 8.1), the flaw lets an attacker who already holds a valid Account API bearer token bypass step-up re-authentication and take full control of a victim’s MFA settings without ever proving they know the account password or possess an existing MFA factor.
The issue was published on GitHub Security Advisories as GHSA-q4h3-38gc-4p4j by researcher wangsijie and affects @logto/core versions up to and including 1.40.1. A patch shipped in version 1.41.0.
Logto WebAuthn Flaw
Logto’s Account Center requires “step-up” verification before allowing users to change sensitive settings, such as MFA factors. In theory, this means proving fresh possession of a password, identifier, or existing authenticator a standard defense against session hijacking.
The system tracks this via a header, logto-verification-id, which points to a verification record the client claims satisfies that requirement.
The vulnerability lives in koaOidcAuththe middleware responsible for determining whether a request counts as identity-verified. Rather than checking why a verification record was created, it only checks two things: does the record belong to the authenticated user, and is isVerified set to true. That’s it.
The problem is that “verified” means different things depending on context. A WebAuthn registration record being marked verified simply confirms the browser completed a new passkey-binding ceremony; it says nothing about whether the actor re-authenticated with something they already owned.
Logto’s middleware treated that signal as equivalent to genuine re-authentication proof, collapsing distinct verification purposes into a single flat boolean.
With a stolen or hijacked bearer token carrying the identities scope, an attacker can:
- Call
POST /api/verifications/web-authn/registrationto spin up a new WebAuthn registration record tied to the victim’s account - Complete
POST /api/verifications/web-authn/registration/verifyusing their own attacker-controlled passkey, flippingverifiedtotrue - Submit that record’s ID via the
logto-verification-idheader on Account Center requests - Watch
ctx.auth.identityVerifiedget set totrue, unlocking/api/my-account/mfa-verifications - Delete the victim’s real MFA factors and bind their own, entrenching persistent access
No user interaction is required beyond the initial token compromise, and the attack complexity is low; hence the CVSS vector reflects network-based access with high confidentiality and integrity impact.
Remediation
The fix, landed via commit 9fa5296b1 on branch wangsijie-fix-account-center-step-up, whitelists which verification record types can satisfy the step-up gate. Only records tied to genuine user-permission validation now qualify:
- Verified password verification records
- Email/phone verification-code records created specifically with
TemplateType.UserPermissionValidation
New MFA-binding records, WebAuthn registration records, sign-in passkey records, and other purpose-mismatched verifications are explicitly rejected. Regression tests now cover both the accepted password/code paths and the rejected WebAuthn/BindMfa scenarios.
Organizations running self-hosted Logto deployments should upgrade to v1.41.0 or later immediately. Since exploitation only requires a compromised bearer token, not additional credential theft, this flaw meaningfully lowers the bar for attackers to convert session hijacking into permanent account takeover.
Any incident response plans treating MFA changes as a strong recovery signal should be reviewed in light of this bypass.
About the Author
