CVE-2026-80197 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.57.0 contains an improper authorization vulnerability in the favorite timesheet add and remove endpoints that allows authenticated users to manipulate other users' bookmarks. Attackers can add or remove timesheet entries from another user's favorite list by referencing their timesheet identifier, enabling cross-user business-state tampering without administrative privileges.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The identified vulnerability in Kimai versions prior to 2.57.0 represents a critical failure in server-side access control mechanisms, specifically classified under CWE-862 as Missing Authorization or CWE-913 as Improper Control of Dynamically Managed Code Resources depending on the specific implementation details of the bookmarking feature. This flaw resides within the API endpoints responsible for adding and removing timesheet entries from a user's favorite list. The core technical deficiency is that these endpoints do not adequately validate whether the authenticated actor initiating the request possesses ownership or explicit administrative rights over the target timesheet identifier being manipulated. Instead, the application relies on insufficient checks that allow an attacker to supply arbitrary identifiers belonging to other users within their HTTP requests. This lack of object-level permission verification enables a direct bypass of intended security boundaries, allowing any validly authenticated user to interact with resources they are not authorized to access.
From an operational perspective, this vulnerability facilitates cross-user business-state tampering without the need for elevated privileges or administrative credentials. An attacker can systematically add timesheet entries from other users' records to their own favorite list, potentially exposing sensitive project data, billing information, or internal work metrics that were intended to remain private. Conversely, the ability to remove these entries disrupts the workflow of legitimate users who rely on quick access to specific tasks for productivity and time tracking accuracy. This manipulation compromises the integrity of the application's state by allowing unauthorized modifications to user-specific configurations and data associations. The impact extends beyond mere privacy violations; it undermines trust in the system's reliability and can lead to significant operational disruptions within teams that depend on accurate timesheet management for billing, resource allocation, and performance evaluation.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, particularly T1078 Valid Accounts, as exploitation requires initial authentication, and T1530 Data from Information Repositories if the favorite list is used to aggregate sensitive data for exfiltration or analysis. Furthermore, it reflects patterns associated with Insecure Direct Object References (IDOR), where internal implementation objects are exposed to end-users without proper access controls. The ability to manipulate another user's state highlights a fundamental gap in how session context and resource ownership are correlated during request processing.
To mitigate this vulnerability, immediate action is required by upgrading the Kimai installation to version 2.57.0 or later, where these authorization checks have been corrected. In environments where patching is not immediately feasible, administrators should implement strict input validation on server-side logic to ensure that any timesheet identifier referenced in favorite management requests matches the user ID associated with the active session token. Additionally, deploying a Web Application Firewall (WAF) with rules designed to detect anomalous patterns of cross-user resource access can provide a temporary layer of defense against exploitation attempts while permanent remediation is underway. Regular security audits focusing on object-level authorization logic are recommended to prevent similar flaws in other parts of the application that handle user-specific data modifications.