CVE-2026-55377: Logto Authentication Bypass Vulnerability

CVE-2026-55377 Overview

CVE-2026-55377 is an authentication bypass vulnerability in Logto, an open-source authentication infrastructure for SaaS and AI applications. Versions prior to 1.41.0 improperly validate step-up verification records in the Account Center. Any active verification record belonging to the current user with isVerified === true was accepted as proof of identity. Attackers holding an Account API bearer token could create a WebAuthn passkey registration verification record, submit it via the logto-verification-id header, and manage multi-factor authentication (MFA) factors without proving possession of a password, identifier, or existing MFA factor. The flaw maps to [CWE-287: Improper Authentication].

Critical Impact
Attackers with a valid bearer token can bind new passkeys and manipulate MFA factors, achieving full account takeover without existing credential proof.

Affected Products

Logto versions prior to 1.41.0
Logto Account Center step-up verification component
Logto Account API endpoints handling logto-verification-id

Discovery Timeline

2026-07-10 - CVE-2026-55377 published to NVD
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-55377

Vulnerability Analysis

The vulnerability resides in Logto's Account Center step-up verification logic. The step-up check evaluated verification records solely on two conditions: the record belonged to the authenticated user, and isVerified === true. It did not enforce the verification record's type against the requested sensitive operation. This allowed a WebAuthn registration verification created for binding a new passkey to satisfy identity verification for unrelated privileged operations, including MFA factor management.

An authenticated user with only an Account API bearer token could initiate a WebAuthn registration flow, complete it, and then reuse the resulting verification identifier via the logto-verification-id header. Account Center routes treated the request as identityVerified=true, granting access to sensitive MFA management routes.

Root Cause

The root cause is missing verification-type enforcement within the step-up middleware. The middleware trusted the existence of any verified record instead of matching the record's verification type (password, MFA factor, or identifier proof) against the operation's required assurance level. Passkey registration records were never intended to serve as identity proof.

Attack Vector

An attacker requires an active Account API bearer token, obtainable through a stolen session, leaked token, or compromised OAuth client. Using the token, the attacker registers a new WebAuthn credential and captures the verification record identifier. Submitting that identifier in the logto-verification-id header on Account Center MFA endpoints bypasses step-up authentication, enabling passkey binding and MFA factor removal or replacement.

typescript

+import { TemplateType } from '@logto/connector-kit';
+import { VerificationType } from '@logto/schemas';
 import type { MiddlewareType } from 'koa';
 import type { IRouterParamContext } from 'koa-router';
 
 import RequestError from '#src/errors/RequestError/index.js';
 import {
   verificationRecordDataGuard,
   buildVerificationRecord,
+  type VerificationRecord,
 } from '#src/routes/experience/classes/verifications/index.js';
 import type Libraries from '#src/tenants/Libraries.js';
 import type Queries from '#src/tenants/Queries.js';
// Source: https://github.com/logto-io/logto/commit/f56255a7edf3b22b0ec2fdb814814ce6b0123b74

The patch introduces VerificationType imports so the middleware can restrict which verification record types satisfy step-up checks.

Detection Methods for CVE-2026-55377

Indicators of Compromise

Unexpected WebAuthn registration verification records immediately followed by requests to MFA management endpoints under the same session.
Account Center requests containing a logto-verification-id header where the referenced record's type is a passkey registration rather than an identity-proof verification.
New passkey bindings or MFA factor changes without preceding password or existing MFA challenge events in audit logs.
Rapid sequences of POST /api/verifications followed by POST /api/my-account/mfa-verifications from the same bearer token.

Detection Strategies

Correlate verification record creation events with subsequent Account Center privileged actions and alert when record type does not match the sensitivity of the target endpoint.
Baseline normal MFA management activity per user and flag actions performed without preceding interactive re-authentication.
Ingest Logto audit logs into a centralized data lake and apply detection rules that inspect verification record type transitions.

Monitoring Recommendations

Enable verbose audit logging for koa-oidc-auth middleware decisions and Account Center routes in Logto core.
Monitor for anomalous bearer token usage patterns, including tokens performing MFA factor changes from new IP addresses or user agents.
Track failure and success rates of step-up verification post-upgrade to confirm the patched logic operates as expected.

How to Mitigate CVE-2026-55377

Immediate Actions Required

Upgrade Logto to version 1.41.0 or later without delay across all tenants and self-hosted deployments.
Rotate all active Account API bearer tokens and OAuth client secrets that could have been used to invoke Account Center endpoints.
Audit recent MFA factor changes and passkey registrations, revoking any unauthorized bindings.
Force re-authentication for all user sessions and require existing MFA factor proof before allowing new factor enrollment.

Patch Information

The fix is included in Logto 1.41.0. The change restricts Account Center step-up verification to records whose VerificationType matches an approved identity-proof set, rejecting WebAuthn registration verifications as step-up proof. See the GitHub Security Advisory GHSA-q4h3-38gc-4p4j, the pull request #9110, the remediation commit, and the v1.41.0 release notes.

Workarounds

Restrict issuance of Account API bearer tokens to trusted first-party clients until the upgrade is complete.
Disable self-service MFA factor management in the Account Center where operationally feasible.
Apply reverse-proxy rules that reject requests carrying logto-verification-id headers on MFA management routes pending patching.

bash

# Upgrade Logto to the fixed release
npm install @logto/core@1.41.0
# or, for Docker deployments
docker pull svhd/logto:1.41.0
docker compose up -d