CVE-2026-54418: Leantime Auth Bypass Vulnerability

CVE-2026-54418 Overview

CVE-2026-54418 is a missing authorization vulnerability in Leantime through version 3.6.2. The application exposes JSON-RPC methods leantime.rpc.TwoFA.TwoFA.getSetupData, saveSecret, verifyAndEnable, and disable2FA that accept a caller-supplied userId parameter. The dispatcher performs no ownership check, session pinning, or permission-attribute gate on these calls. Any authenticated user can invoke getSetupData with an arbitrary userId to read another user's live Time-based One-Time Password (TOTP) secret. The same actor can call disable2FA to strip two-factor authentication from any target account. This weakness is tracked under CWE-862.

Critical Impact
Any authenticated Leantime user can read arbitrary users' TOTP secrets or disable their 2FA, defeating account-level multi-factor authentication protection.

Affected Products

Leantime through version 3.6.2
JSON-RPC TwoFA service endpoints (getSetupData, saveSecret, verifyAndEnable, disable2FA)
Deployments relying on Leantime's built-in TOTP-based two-factor authentication

Discovery Timeline

2026-08-05 - CVE-2026-54418 published to the National Vulnerability Database (NVD)
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-54418

Vulnerability Analysis

Leantime exposes its two-factor authentication management functions over a JSON-RPC dispatcher. The methods TwoFA.getSetupData, TwoFA.saveSecret, TwoFA.verifyAndEnable, and TwoFA.disable2FA accept a userId argument directly from the caller. Other RPC methods in the same dispatcher enforce ownership checks or permission attributes. The TwoFA methods do not. The result is a horizontal privilege escalation across every account with 2FA configured.

An authenticated attacker with a low-privileged account calls getSetupData and supplies the userId of an administrator. The server returns the TOTP shared secret used to generate one-time codes. The attacker seeds a TOTP application with that secret and can now produce valid second-factor codes for the target account. Alternatively, the attacker invokes disable2FA with the target userId and removes the second factor entirely, reducing the account to single-factor authentication.

This issue is related to CVE-2026-15509, which covers a similar missing-authorization pattern in the editUser/addUser role-assignment path within the same JSON-RPC dispatcher. The TwoFA methods are a distinct, independently fixable set of endpoints.

Root Cause

The root cause is missing authorization enforcement [CWE-862]. The TwoFA RPC handlers trust the userId parameter supplied by the client and operate on it without validating that the parameter matches the authenticated session identity or that the caller holds an administrative permission attribute.

Attack Vector

Exploitation requires a valid authenticated session but no elevated privileges. The attacker sends a JSON-RPC request over the network to the Leantime application, invokes leantime.rpc.TwoFA.TwoFA.getSetupData or disable2FA, and supplies the target userId in the request parameters. No user interaction from the victim is required. The server returns the sensitive TOTP material or removes the 2FA binding without additional challenge.

See the Leantime project repository on GitHub for the affected JSON-RPC dispatcher implementation.

Detection Methods for CVE-2026-54418

Indicators of Compromise

HTTP requests to the JSON-RPC endpoint invoking leantime.rpc.TwoFA.TwoFA.getSetupData, saveSecret, verifyAndEnable, or disable2FA where the userId parameter differs from the authenticated session's user identifier.
Unexpected 2FA state transitions in the Leantime user database, particularly disable2FA events initiated by non-administrative accounts.
TOTP secret retrieval calls originating from low-privileged user sessions.
Subsequent successful logins to privileged accounts from new source addresses shortly after TwoFA RPC activity.

Detection Strategies

Parse Leantime application and web-server access logs for JSON-RPC method names matching the TwoFA service and correlate the userId parameter against the session owner.
Alert on any invocation of disable2FA that is not preceded by a matching self-service 2FA setup flow for the same user.
Baseline normal 2FA management activity per account and flag cross-account TwoFA RPC calls.

Monitoring Recommendations

Forward Leantime application logs and reverse-proxy access logs to a centralized logging platform for retention and query.
Monitor for authentication anomalies such as a user account whose 2FA state changes without a corresponding administrative action or user-initiated setting change.
Track authentication events for accounts whose TOTP secrets may have been exposed and require re-enrollment.

How to Mitigate CVE-2026-54418

Immediate Actions Required

Upgrade Leantime to a version later than 3.6.2 that addresses the missing authorization checks in the TwoFA JSON-RPC handlers.
Rotate TOTP secrets for all Leantime accounts, since existing secrets may have been read by any authenticated user.
Audit the Leantime user table for accounts whose 2FA status was disabled without a legitimate administrative record and re-enable enrollment.
Review recent authentication logs for logins to privileged accounts that may have been aided by a stolen TOTP secret or a stripped second factor.

Patch Information

Refer to the Leantime project repository on GitHub for the fixed release and commit history addressing the TwoFA RPC authorization checks. Apply the vendor-supplied patch that enforces ownership validation on the userId parameter and gates administrative TwoFA operations behind a permission attribute.

Workarounds

Restrict network access to the Leantime application to trusted users only while a patched release is deployed.
Place the JSON-RPC endpoint behind a reverse-proxy rule that blocks or logs TwoFA method calls pending remediation.
Reduce the number of authenticated user accounts on the instance until the patched version is installed.
Force all users to re-enroll their TOTP devices after upgrading to invalidate any secrets that may have been exfiltrated.

bash

# Example reverse-proxy rule (nginx) to block TwoFA RPC calls until patched
# Adjust the location and match pattern to fit your Leantime deployment
location /api/jsonrpc {
    if ($request_body ~* "leantime\.rpc\.TwoFA\.TwoFA\.(getSetupData|saveSecret|verifyAndEnable|disable2FA)") {
        return 403;
    }
    proxy_pass http://leantime_backend;
}