CVE-2026-52826 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.57.0, GET or POST requests to /en/admin/project/{id}/rate/{rate}, /en/admin/customer/{id}/rate/{rate}, and /en/admin/activity/{id}/rate/{rate} independently resolve the authorized parent identifier and the attacker-selected child rate identifier without confirming that the ProjectRate, CustomerRate, or ActivityRate belongs to that parent. An authenticated user who can edit one parent object can pair it with a rate record from an unauthorized project, customer, or activity and persist changes to billing configuration in kimai2_projects_rates, kimai2_customers_rates, or kimai2_activities_rates. This issue is fixed in version 2.57.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Kimai versions prior to 2.57.0 represents a critical failure in server-side object reference validation within the application's administrative billing configuration modules. As an open-source time tracking platform, Kimai relies on strict hierarchical relationships between parent entities such as projects, customers, and activities, and their associated child entities like rates. The core technical flaw lies in how the backend handles HTTP GET or POST requests directed at specific endpoints for managing these rate associations. When a request is made to update a rate configuration, the application correctly identifies the authorized parent identifier from the URL path but fails to verify that the provided child rate identifier actually belongs to that specific parent object within the database schema. This lack of cross-reference validation allows an authenticated user with edit permissions on one entity type to manipulate billing data by linking it to unrelated entities.
From a technical perspective, this is a classic instance of Insecure Direct Object Reference where the application trusts client-supplied identifiers without performing sufficient authorization checks against the underlying data model. The attacker can exploit this by sending crafted requests that pair an authorized project or customer ID with a rate record belonging to a different, unauthorized project, customer, or activity. Because the system does not confirm ownership or association integrity before persisting changes, it results in unintended modifications to the kimai2_projects_rates, kimai2_customers_rates, and kimai2_activities_rates tables. This behavior effectively bypasses intended access controls, allowing users to alter billing configurations for resources they do not own or have permission to manage, thereby compromising the logical integrity of the application's data structure.
The operational impact of this vulnerability is significant for organizations relying on Kimai for accurate time tracking and financial reporting. By manipulating rate associations across unrelated entities, an attacker can distort cost calculations, inflate billing amounts for specific clients, or hide unauthorized activities by associating them with legitimate projects. This undermines the reliability of financial audits and internal resource allocation metrics. Furthermore, because this requires only authenticated access with edit privileges on a single parent object, it lowers the barrier to entry for exploitation compared to vulnerabilities requiring administrative rights or external network access. The ability to persist these changes means that even if detected later, the damage to data integrity may already be widespread across multiple billing cycles.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control where a user is able to bypass intended restrictions by manipulating object references. It also maps to MITRE ATT&CK technique T1078, specifically Valid Accounts, as the exploitation relies on legitimate credentials and privileges within the application environment rather than external system compromises. The flaw highlights the importance of implementing robust authorization checks that validate not just user permissions but also the relational integrity between related database entities during state-changing operations.
To mitigate this issue, organizations must upgrade Kimai to version 2.57.0 or later where the developer has implemented proper validation logic to ensure that rate identifiers correspond exclusively to their authorized parent objects before processing updates. In addition to upgrading, administrators should enforce strict role-based access control policies and regularly audit billing configuration changes for anomalies. Implementing server-side checks that verify foreign key constraints at the application layer, rather than relying solely on database-level integrity, provides an additional defense-in-depth measure against similar logical flaws in future development cycles.