CVE-2026-80202 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.56.0 does not enforce team-membership checks in TimesheetVoter::voteOnAttribute(), which maps permissions only to own_timesheet or other_timesheet. As a result, any authenticated user with ROLE_TEAMLEAD (or a role holding edit_other_timesheet/delete_other_timesheet) can read, modify, and permanently delete timesheets belonging to any user system-wide via the API, regardless of team membership. Timesheet IDs are sequential integers and trivially enumerable. ROLE_USER accounts are correctly restricted. (Note: the maintainers characterize this behavior as matching the documented permission model.)
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 vulnerability identified in Kimai versions prior to 2.56.0 represents a critical failure in access control logic within the application's authorization layer, specifically affecting how permissions are evaluated for timesheet operations. The core technical flaw resides in the TimesheetVoter::voteOnAttribute() method, which is responsible for determining whether an authenticated user has permission to perform specific actions on timesheet entities. In this flawed implementation, the voter maps permissions exclusively based on two binary states: own_timesheet and other_timesheet. This design choice fails to incorporate any verification of team membership or organizational boundaries when evaluating requests that fall under the other_timesheet category. Consequently, the system does not distinguish between a user attempting to access data within their designated team scope versus accessing data outside of it, leading to a complete bypass of intended isolation mechanisms for certain privileged roles.
This architectural oversight has severe operational implications for organizations utilizing Kimai as a time tracking and billing solution. Any authenticated user holding the ROLE_TEAMLEAD role, or any custom role that includes permissions such as edit_other_timesheet or delete_other_timesheet, gains unrestricted ability to read, modify, and permanently delete timesheets belonging to any other user in the entire system. This capability is exercised via the application's API, which allows for programmatic interaction with these endpoints. Because Timesheet IDs are implemented as sequential integers, an attacker can trivially enumerate valid identifiers through simple iteration or brute-force techniques. This predictability significantly lowers the barrier to entry for exploitation, allowing malicious actors to systematically target specific records without needing prior knowledge of internal data structures or UUIDs that might otherwise obscure resource locations.
The impact extends beyond mere unauthorized access to include potential integrity and availability compromises. An attacker with elevated privileges could alter billing hours, leading to financial discrepancies and inaccurate project costing reports. More critically, the ability to permanently delete timesheets can result in irreversible loss of critical business data, potentially disrupting payroll processes or legal compliance records that rely on accurate time tracking history. While ROLE_USER accounts are correctly restricted by this logic, ensuring they cannot access other users' data, the privilege escalation inherent in team lead roles creates a significant security gap. This discrepancy highlights a fundamental misalignment between the documented permission model and the actual enforcement mechanisms within the codebase, as maintainers have characterized this behavior as intentional rather than a bug, despite its clear deviation from standard least-privilege principles expected in multi-user enterprise applications.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in authorization checks that allow users to access resources belonging to other entities. It also maps closely to MITRE ATT&CK techniques related to Privilege Escalation and Data Exfiltration via API endpoints. The sequential nature of the identifiers further exacerbates the risk by facilitating enumeration attacks, which are often categorized under reconnaissance phases in threat modeling frameworks. To mitigate this issue, organizations running affected versions must immediately upgrade to Kimai version 2.56.0 or later, where these team-membership checks have been properly enforced within the voter logic. Until an update is applied, administrators should consider restricting access to timesheet-related API endpoints through network-level controls such as firewalls or reverse proxy rules, limiting exposure only to trusted internal subnets if possible. Additionally, implementing strict input validation and rate-limiting on enumeration-prone endpoints can help reduce the risk of systematic data harvesting by malicious actors exploiting this flaw.