CVE-2026-55370: Logto TOTP Auth Bypass Vulnerability

CVE-2026-55370 Overview

CVE-2026-55370 is a TOTP (Time-based One-Time Password) replay vulnerability in Logto, an open-source authentication infrastructure used for SaaS and AI applications. Versions prior to 1.41.0 accept a previously used TOTP code again while it remains valid inside the RFC 6238 acceptance window. The underlying verifier uses otplib's stateless authenticator.check() call with window = 1 and does not persist or compare the accepted TOTP time-step counter. An attacker who already holds the victim's first factor and captures a live TOTP value can replay it to satisfy multi-factor authentication (MFA) during the same acceptance window. The issue is fixed in Logto version 1.41.0 and is classified under [CWE-294: Authentication Bypass by Capture-replay].

Critical Impact
An attacker with a captured TOTP code and knowledge of the victim's first factor can replay the code within its validity window to bypass MFA and gain authenticated access to the victim's account.

Affected Products

Logto versions prior to 1.41.0
Logto self-hosted deployments using TOTP-based MFA
Logto cloud tenants using the vulnerable validateTotpToken verification helper

Discovery Timeline

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

Technical Details for CVE-2026-55370

Vulnerability Analysis

The vulnerability is a capture-replay flaw in Logto's TOTP verification path. RFC 6238 defines TOTP codes as valid for a discrete time step, typically 30 seconds. Verifiers commonly extend acceptance by one step in each direction to tolerate clock drift, which produces a rolling window during which a single code remains valid. Logto's validateTotpToken function in packages/core/src/libraries/verification-helpers/totp-validation.ts invoked authenticator.check(token, secret) with the default window = 1 and returned a boolean. No record of the accepted time step was stored on the user's MFA verification entry. As a result, the same TOTP value could satisfy MFA more than once during its acceptance window.

Root Cause

The root cause is the absence of single-use enforcement for accepted TOTP codes. The verifier was stateless: it only confirmed that the presented code matched the expected value for the current window. Without persisting the counter (time step) of the last successful verification, the server had no basis to reject a repeat submission of the same code. This violates the one-time-use property that gives OTP its security guarantee.

Attack Vector

Exploitation requires that the attacker already possess the victim's first authentication factor (username and password) and can observe a live TOTP value. Capture methods include phishing proxies, browser malware, shoulder surfing, or intercepting authentication requests. Once captured, the attacker submits the same TOTP value to the Logto MFA endpoint while it remains inside the acceptance window. The server accepts the replay and issues an authenticated session. User interaction is required to expose the code, and attack complexity is elevated because the attacker must act within a short time window.

typescript

// Patch: packages/core/src/libraries/verification-helpers/totp-validation.ts
 export const validateTotpToken = (secret: string, token: string) => {
   return authenticator.check(token, secret);
 };
+
+export const getTotpTokenTimeStep = (secret: string, token: string) => {
+  const epoch = Date.now();
+  const authenticatorAtEpoch = authenticator.clone({ epoch });
+  const delta = authenticatorAtEpoch.checkDelta(token, secret);
+
+  if (delta === null) {
+    return;
+  }
+
+  const { step } = authenticatorAtEpoch.allOptions();
+
+  return Math.floor(epoch / step / 1000) + delta;
+};

Source: Logto commit 9118867. The fix introduces getTotpTokenTimeStep, which returns the exact time step of the accepted token so the server can persist it and reject reuse.

Detection Methods for CVE-2026-55370

Indicators of Compromise

Two or more successful MFA verifications for the same user within a 30 to 90 second window using identical TOTP submissions.
MFA success events originating from two distinct IP addresses or user agents within the same TOTP acceptance window.
Session creation events immediately following a failed password-only login from a different source address.

Detection Strategies

Correlate authentication logs to identify repeated MFA verifications tied to the same TOTP time step for a single user account.
Alert on MFA challenges completed from a client fingerprint that differs from the one that initiated the login flow.
Baseline normal MFA cadence per user and flag bursts of successful verifications inside a single RFC 6238 step boundary.

Monitoring Recommendations

Ingest Logto authentication and MFA logs into a centralized SIEM or data lake for cross-session correlation.
Retain full request metadata (source IP, user agent, request ID, timestamp) for MFA endpoints to enable replay analysis.
Enable alerts on Logto version strings below 1.41.0 discovered by asset inventory or software composition scans.

How to Mitigate CVE-2026-55370

Immediate Actions Required

Upgrade Logto to version 1.41.0 or later, which persists lastUsedTimeStep on each MFA verification and rejects reuse of the same step.
Audit recent authentication logs for duplicate MFA success events per user within a single TOTP window and invalidate any suspicious sessions.
Force reauthentication and TOTP re-enrollment for high-value accounts if replay activity is suspected.

Patch Information

The fix is delivered in Logto v1.41.0 via pull request #9109 and commit 9118867. The patch adds getTotpTokenTimeStep to compute the accepted step and updates the user record with lastUsedAt and lastUsedTimeStep. Subsequent verifications reject any token whose time step is less than or equal to the stored value. Full details are available in GHSA-6wj7-c66m-6c82.

Workarounds

Enforce stronger first-factor protections (phishing-resistant passwords, credential stuffing defenses) to reduce the pool of attackers with a valid first factor.
Where feasible, migrate high-value users from TOTP to phishing-resistant factors such as WebAuthn or FIDO2 security keys until the upgrade is applied.
Shorten session lifetimes and require step-up authentication for sensitive operations to limit the value of a replayed MFA event.

bash

# Upgrade Logto to the patched release
# Docker
docker pull svhd/logto:1.41.0

# npm-based self-host
npm install @logto/core@1.41.0

# Verify running version after upgrade
curl -s https://<your-logto-host>/api/status | jq '.version'