☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Leantime logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N 🐛 CWE-862
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-54418

CVE-2026-54418 Vulnerability in Leantime
📅 PUBLISHED: 2026-08-05 00:00 UTC 🔄 UPDATED: 2026-09-23 20:16 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: Public
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.25%
👁️
0.25% probability
6.2× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Country: Germany License: Open Source
Patch available — upgrade to latest release
CVSS VECTOR BREAKDOWN 8.1
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: H Integrity High
A: N Availability None
8.1
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-54418 is an authorization bypass vulnerability in Leantime, a popular open-source project management and productivity platform, affecting all versions up to and including 3.6.2. The flaw resides in the JSON-RPC dispatcher, specifically within the leantime.rpc.TwoFA.TwoFA service methods (getSetupData, saveSecret, verifyAndEnable, disable2FA), which improperly trust a caller-supplied userId parameter without performing ownership checks, session pinning, or permission-attribute gating. Any authenticated low-privileged user can invoke these methods to read another user's live TOTP secret or completely disable two-factor authentication on a target account, resulting in full account compromise with a High severity CVSS score of 8.1. The vulnerability is currently unpatched in any stable release, and exploitation requires only a valid session, making it a critical risk for enterprise deployments relying on 2FA for privileged accounts.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

The vulnerability is rooted in Leantime's JSON-RPC (Remote Procedure Call) architecture, which exposes application services to authenticated web clients. The platform uses a centralized dispatcher that routes incoming RPC calls to registered service and method combinations. While the dispatcher typically enforces a granular permission model — requiring specific rights like project.management or users.edit for sensitive operations — the TwoFA service methods were registered without these attribute gates.

The affected methods are:

  1. leantime.rpc.TwoFA.TwoFA.getSetupData — Returns the TOTP provisioning URI and the live base32 secret for the account identified by the userId parameter. No check is performed to ensure the requesting session maps to that userId.

  2. leantime.rpc.TwoFA.TwoFA.saveSecret and verifyAndEnable — Allow setting/activating a TOTP secret for a specified userId, enabling an attacker to bind their own shared secret to a victim's account.

  3. leantime.rpc.TwoFA.TwoFA.disable2FA — Accepts a userId and disables 2FA for that account. Since no ownership check exists, an attacker can strip the victim's 2FA protection without knowing their TOTP codes.

The attack surface is the authenticated JSON-RPC endpoint, typically /api/jsonrpc or similar, reachable over HTTP/HTTPS. All methods operate under the authenticated user's session, but the lack of a user_id == session.user.id comparison is the core enabler. This pattern is similar to CVE-2026-15509 (role assignment via editUser/addUser), but the TwoFA methods are distinct and independently fixable.

An attacker with a low-privilege account (e.g., a standard "Viewer" role) can enumerate valid userId integers (often sequential) and call getSetupData to exfiltrate TOTP secrets. Alternatively, simply calling disable2FA on a target user completes the attack in a single request, logging the attacker into the victim's account on the next authentication attempt with only the password.

The vulnerability is classified under CWE-862 (Missing Authorization), reflecting the absence of an authorization check for a function that requires elevated privilege. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) indicates a network-exploitable flaw requiring low privileges, with no user interaction, and high impact to confidentiality and integrity but no direct availability impact.

Exploitation Scenarios

Scenario 1: One-Request 2FA Disable + Account Takeover

  1. Reconnaissance: The attacker logs in with a low-privilege account (e.g., user / standard password) and identifies the JSON-RPC endpoint by inspecting the web application's JavaScript bundle for TwoFA service references. They note the session cookie name (e.g., leantime_session) and the base URL.
  2. Trigger: The attacker sends the following HTTP request to the JSON-RPC endpoint:
    POST /api/jsonrpc HTTP/1.1
    Host: target.leantime.com
    Cookie: leantime_session=<attacker-session>
    Content-Type: application/json
    
    {"jsonrpc":"2.0","method":"leantime.rpc.TwoFA.TwoFA.disable2FA","params":{"userId":1},"id":1}
    
    Here, userId: 1 targets the default admin account. The server returns a success response without any ownership verification.
  3. Payload/Execution: The attacker repeats the request for additional privileged accounts (userId=2, 3, etc.) to strip 2FA from all admins.
  4. Post-Exploitation: The attacker logs in as the admin user using a known password (gained via phishing or credential stuffing) — bypassing the removed 2FA — and gains full project/workspace access, exfiltrates data, or plants persistent backdoors.

Scenario 2: TOTP Secret Exfiltration for Silent Hijack

  1. Reconnaissance: The attacker authenticates and obtains the session cookie.
  2. Trigger: They send:
    POST /api/jsonrpc HTTP/1.1
    Host: target.leantime.com
    Cookie: leantime_session=<attacker-session>
    
    {"jsonrpc":"2.0","method":"leantime.rpc.TwoFA.TwoFA.getSetupData","params":{"userId":5},"id":1}
    
    The response contains {"secret":"JBSWY3DPEHPK3PXP","url":"otpauth://totp/Leantime:admin@corp.com?secret=..."}.
  3. Payload/Execution: The attacker imports the secret into an authenticator app, producing valid live TOTP codes for the victim.
  4. Post-Exploitation: The attacker waits for the victim to sign out or uses the code during the next login attempt (e.g., after a forced password reset), silently authenticating without triggering any 2FA prompt or alert.

Impact Assessment

The vulnerability has a CVSS base score of 8.1, driven by high confidentiality (C:H) and integrity (I:H) impacts, an attack vector of network (AV:N), and low attack complexity (AC:L). The exploit requires only low privileges (PR:L) and no user interaction (UI:N), with no scope change (S:U).

Affected Systems: All Leantime deployments running version 3.6.2 or earlier, self-hosted or in private clouds, where user accounts have heterogeneous privilege levels.

Business Impact: For organizations using Leantime to manage sensitive projects, client data, or internal workflows, this flaw allows any authenticated user to bypass 2FA on any other account, including global administrators. This undermines the entire authentication trust model, enabling lateral movement, data exfiltration, and unauthorized configuration changes.

Blast Radius: The lack of ownership checks affects all users in the system, but the primary targets are high-privilege accounts (admins, project managers, finance users). The vulnerability is trivial to exploit (a single curl command), does not require specialized tooling, and leaves no trace in application logs unless RPC calls are deliberately audited. The confidentiality impact is severe because the getSetupData method leaks raw TOTP secrets, enabling offline generation of valid codes — a worse outcome than merely bypassing 2FA via disable2FA, as it leaves the victim unaware of the compromise.

Detection Guidance

All detection rules below target the JSON-RPC request patterns that invoke the vulnerable methods or the resulting unauthorized account modifications. Combine these with authentication logs that record user IDs and IP addresses for full coverage.

Sigma Rule

title: Leantime CVE-2026-54418 - Unauthorized TwoFA Disable/Setup
id: 9f2f7d3e-5c1a-4b8e-9d2f-1a4b7c8e9f0a
status: experimental
description: Detects JSON-RPC requests to Leantime TwoFA methods with a userId parameter that may not match the authenticated session user.
logsource:
    category: application
    product: leantime
    service: jsonrpc
detection:
    selection_method:
        - method|startswith: 'leantime.rpc.TwoFA.TwoFA.'
    selection_params:
        - params.userId|exists: true
    condition: selection_method and selection_params
level: high
falsepositives:
    - Legitimate 2FA setup by an admin on behalf of a user (if such a feature is intended)
    - Automated provisioning workflows
fields:
    - method
    - params.userId
    - session.userId
    - src_ip
tags:
    - attack.t1190
    - cve.2026-54418
    - cwe.862

YARA Rule

rule Leantime_TwoFA_Authorization_Bypass
{
    meta:
        author = "Valter Security"
        description = "Detects strings related to Leantime TwoFA JSON-RPC endpoint abuse"
        cve = "CVE-2026-54418"
        date = "2026-05-20"
    strings:
        $method1 = "leantime.rpc.TwoFA.TwoFA.getSetupData"
        $method2 = "leantime.rpc.TwoFA.TwoFA.saveSecret"
        $method3 = "leantime.rpc.TwoFA.TwoFA.verifyAndEnable"
        $method4 = "leantime.rpc.TwoFA.TwoFA.disable2FA"
        $user_param = "userId"
    condition:
        any of ($method*) and $user_param
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"Leantime CVE-2026-54418 - TwoFA RPC Abuse"; flow:to_server,established; content:"POST"; http_method; content:"/api/jsonrpc"; http_uri; content:"leantime.rpc.TwoFA.TwoFA."; http_client_body; content:"userId"; http_client_body; sid:202654418; rev:1; classtype:attempted-user; reference:cve,2026-54418;)

Elastic Detection

sequence by process.entity_id with maxspan=1m
  [http where request.method == "POST" and url.path == "/api/jsonrpc" and request.body.text contains "leantime.rpc.TwoFA.TwoFA."]
  [http where request.body.text contains "userId" and not request.body.text contains "\"userId\":" + "{{user.id}}"] // heuristic: parameter does not match bound user

Splunk SPL Query

index=main sourcetype=leantime:jsonrpc
| where match(method, "leantime\\.rpc\\.TwoFA\\.TwoFA\\.")
| where isnotnull(userId)
| eval potential_compromise = if(userId != session_user_id, "HIGH", "LOW")
| table _time, src_ip, session_user_id, userId, method
| sort - _time
| where potential_compromise == "HIGH"

Wazuh OSSEC Rule

<group name="leantime,">
  <rule id="100544" level="12">
    <decoded_as>json</decoded_as>
    <field name="method">leantime\.rpc\.TwoFA\.TwoFA\..+</field>
    <description>Leantime JSON-RPC TwoFA method invoked: $(method)</description>
    <group>cve-2026-54418,wazuh,leantime,</group>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED — as of this report, no official patch exists in any stable Leantime release (<= 3.6.2). The vendor has acknowledged the issue (related to CVE-2026-15509 pattern) and is working on a fix in the development branch, but no specific commit hash or release version has been published.

  1. Immediate Mitigations (compensating controls):

    • Restrict access to the JSON-RPC endpoint at the network layer: apply a reverse-proxy rule to block POST /api/jsonrpc calls originating from non-admin IP ranges or all external sources.
    • Disable the TwoFA service methods via a custom middleware or monkey-patch that rejects calls where userId != session.user.id; this can be deployed as a temporary hotfix by intercepting the RPC dispatcher.
    • Enforce an application-level firewall (WAF) rule that inspects application/json bodies and blocks any requests containing the string leantime.rpc.TwoFA.TwoFA. when the request originates from a user whose session role is not "admin".
    • Audit all user sessions immediately. If any disabled 2FA flags are detected for accounts, re-enable 2FA and reset passwords.
  2. Patch/Upgrade Steps:

    • Monitor the official Leantime GitHub repository (github.com/Leantime/leantime) for a release > 3.6.2. When available, upgrade immediately using:
      git pull origin master
      composer install --no-dev
      
      (PHP package manager, per security team rules.)
    • Until the fix, prohibit access to the affected endpoint for all users except a few trusted administrators.
  3. Long-Term Hardening:

    • Implement a strict IDOR (Insecure Direct Object Reference) review process for all RPC methods during CI/CD, specifically checking that userId parameters are always compared against the authenticated session's user ID.
    • Add server-side validation middleware that automatically rejects methods with a userId parameter when the user lacks the users.edit or twofa.manage permission.
    • Deploy session pinning: bind RPC calls to the exact session identifier, and log any mismatch for SIEM alerting.
    • Require hardware keys (WebAuthn) for administrative accounts instead of TOTP, which is susceptible to secret exfiltration.

References

  1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-54418 — Official CVE record with current NVD description and CVSS metrics.
  2. Related CVE (CVE-2026-15509): https://nvd.nist.gov/vuln/detail/CVE-2026-15509 — Same authorization-bypass pattern in Leantime's editUser/addUser role-assignment path.
  3. Leantime Official Repository: https://github.com/Leantime/leantime — Monitor releases tab for patched version > 3.6.2.
  4. CWE-862 Reference: https://cwe.mitre.org/data/definitions/862.html — Missing Authorization weakness class.
  5. No known threat-actor campaigns or exploitation-in-the-wild evidence have been observed for this CVE as of this writing. However, given the trivial exploitability of a similar flaw (CVE-2026-15509), we assess a high likelihood of imminent weaponization. The vulnerability does not appear in the CISA Known Exploited Vulnerabilities (KEV) catalog.
👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

http.title:"Leantime"
http.component:"Leantime"
http.title:"Login // Leantime"

💣 PoC CODE AVAILABLE

Exploit code for this CVE is tracked in our database. Access poc_code via API Pro.

[ API_PRO ] →
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-54418/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.