EUVD-2026-43011Severity by source
AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N
Agrees with provided vector: network-exploitable but requires captured live TOTP (AC:H), stolen first-factor credentials (PR:L), and victim interaction (UI:R); MFA bypass yields C:H/I:H with no availability impact.
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 existing TOTP verification accepted a successfully used TOTP code again while the code remained inside the RFC 6238 acceptance window because the verifier used otplib's stateless check with window = 1 and did not persist or compare the accepted TOTP time-step counter. An attacker who has the victim's first factor and captures a live TOTP value can replay that value to satisfy MFA during the same acceptance window. This issue is fixed in version 1.41.0.
AnalysisAI
TOTP replay vulnerability in Logto prior to 1.41.0 allows an attacker who holds a victim's first-factor credentials and captures a live TOTP code to replay that code within the same RFC 6238 acceptance window, bypassing multi-factor authentication entirely. The root cause is otplib's stateless verification call with window=1, which validates the time-based OTP cryptographically but does not persist the last-accepted time-step counter - leaving used codes valid for replay until the 30-second window expires. No public exploit or CISA KEV listing exists at time of analysis, but successful exploitation yields full account compromise (C:H, I:H) because MFA is the terminal authentication barrier.
Technical ContextAI
Logto implements TOTP-based MFA using the otplib JavaScript library. RFC 6238 defines time-based OTPs as 30-second rolling codes derived from HMAC-SHA1, with most implementations accepting one adjacent time-step on either side (window=1) to tolerate clock skew. Critically, RFC 6238 also mandates that verifiers MUST NOT accept a previously used OTP within its validity window - enforcing this requires persisting the last-accepted time-step counter server-side. The vulnerable code path calls otplib's stateless check function, which validates the HOTP math against the current clock window but carries no internal state across calls; it cannot distinguish a first-use code from a replay. CWE-294 (Authentication Bypass by Capture-replay) directly names this class of flaw: the verifier lacks the persistent state necessary to invalidate a seen-but-still-valid token. The vulnerability is scoped to the TOTP verification component in all Logto versions below 1.41.0, as confirmed by GitHub security advisory GHSA-6wj7-c66m-6c82 and the associated PR #9109.
RemediationAI
Upgrade Logto to version 1.41.0 or later, available at https://github.com/logto-io/logto/releases/tag/v1.41.0. The patch (commit 9118867f6cbadc7291cf913beb4fede91ed5d374, merged via PR #9109 at https://github.com/logto-io/logto/pull/9109) corrects the TOTP verifier to persist the accepted time-step counter server-side and reject any code whose time-step has already been consumed, as required by RFC 6238. If an immediate upgrade is not operationally feasible, the only viable compensating control is to disable TOTP as a second-factor option and require an inherently single-use alternative (e.g., email magic link, hardware security key via WebAuthn). This eliminates the replay surface entirely but removes TOTP functionality for all users - reassigning users to another second factor may require coordination and user re-enrollment. No partial workaround preserves TOTP while preventing replay without the patch, because the flaw is architectural to the stateless verification call.
Same weakness CWE-294 – Authentication Bypass by Capture-replay
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today