CVE-2026-76647 in Leantime
Summary
by MITRE • 08/20/2026
Leantime JSON-RPC API through version 3.9.0 contains a missing authorization vulnerability in the JSON-RPC dispatcher in app/Domain/Api/Controllers/Jsonrpc.php. The dispatcher does not enforce authorization before invoking service-layer methods, allowing an authenticated user to call methods or act on resources outside their intended permissions. For example, the editOwn method accepts a user-supplied user ID without verifying that it belongs to the caller, allowing an attacker to modify another user's account and set a new password, resulting in account takeover. This vulnerability is distinct from CVE-2026-59712 and CVE-2026-15509 because the root cause is the lack of centralized authorization enforcement in the JSON-RPC dispatcher rather than the behavior of an individual exposed method.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
Leantime, a project management software solution widely used for agile workflows and team collaboration, contains a critical security flaw within its JSON-RPC API implementation up to version 3.9.0. The vulnerability resides in the core dispatcher logic located at app/Domain/Api/Controllers/Jsonrpc.php. This component serves as the entry point for remote procedure calls made by authenticated users interacting with the application's backend services. While Leantime implements authentication mechanisms to verify user identity, it fails to implement robust authorization checks within this specific API layer before executing service-layer methods. This architectural oversight creates a significant gap in access control enforcement, allowing authenticated actors to bypass intended permission boundaries and interact with system resources beyond their assigned roles or privileges.
The technical root cause of this vulnerability is the absence of centralized authorization logic in the JSON-RPC dispatcher. In many modern web applications, API endpoints are designed to delegate business logic to service layers that handle data manipulation. Ideally, each method invocation should be preceded by a check verifying whether the current user has permission to perform the requested action on the specified resource. However, in this instance, the dispatcher invokes these methods directly without validating if the caller is authorized for the specific operation or target entity. This design flaw means that any authenticated user can potentially manipulate internal state variables and invoke privileged functions as long as they know the method signature and parameters, regardless of their actual role within the application hierarchy.
A concrete manifestation of this vulnerability occurs in the editOwn method, which is intended to allow a user to update their own profile information. The implementation accepts a user-supplied identifier for the target account without verifying that this ID matches the identity of the authenticated caller. Consequently, an attacker can supply the unique identifier of another legitimate user and modify critical account details, such as email addresses or passwords. By successfully changing the password associated with another user's account through this API endpoint, the attacker achieves a complete account takeover. This capability effectively neutralizes the security model of the application for any targeted individual, granting the attacker full control over their projects, tasks, and personal data without requiring additional exploitation steps like session hijacking or credential stuffing.
The operational impact of this vulnerability is severe, as it directly compromises the confidentiality, integrity, and availability of user accounts within the Leantime environment. Beyond simple account takeover, an attacker with sufficient knowledge of internal API structures could potentially escalate privileges to administrative levels if other methods lack similar checks. This leads to unauthorized access to sensitive project data, potential modification or deletion of critical business information, and the ability to impersonate legitimate users for social engineering attacks against colleagues. The distinction from related vulnerabilities such as CVE-2026-59712 and CVE-2026-15509 highlights that this is not an isolated bug in a single function but a systemic architectural weakness where the foundational API layer fails to enforce security policies consistently across all exposed methods.
From a classification perspective, this vulnerability aligns with CWE-862, which denotes Missing Authorization, and specifically reflects patterns associated with CWE-285 Improper Authorization. In terms of offensive cybersecurity frameworks like MITRE ATT&CK, this behavior corresponds to T1078 Valid Accounts, where an attacker uses legitimate credentials to gain access, followed by T1098 Account Manipulation or T1136 Create Account depending on the specific actions taken post-exploitation. The lack of centralized enforcement suggests a failure in implementing Principle 4 from the OWASP API Security Top Ten, which emphasizes broken object level authorization and insufficient control over resource access controls at the application layer.
To mitigate this vulnerability, immediate action is required to patch the JSON-RPC dispatcher logic. Developers must implement explicit authorization checks before any service-layer method is invoked. This involves verifying that the authenticated user's identity matches the target entity ID for operations affecting individual accounts or ensuring role-based access control policies are enforced for broader resource modifications. Additionally, adopting a centralized middleware approach where all API requests pass through an authentication and authorization filter can prevent such oversights in future development cycles. Organizations currently running Leantime versions prior to 3.9.1 should upgrade immediately upon the release of the patched version or apply manual code fixes if upgrading is not feasible. Regular security audits focusing on API endpoint permissions are also recommended to ensure that no other endpoints suffer from similar authorization gaps, thereby maintaining a robust defense-in-depth posture against internal threats and compromised credentials.