CVE-2026-52819 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.57.0, the GET /api/timesheets list endpoint accepts user and users[] target identifiers from a caller with view_other_timesheet but does not apply access_user or verify that a ROLE_TEAMLEAD requester leads a team containing each target user. TimesheetController::cgetAction() adds the resolved users directly to the query while project and customer filtering still permits records on unscoped projects or projects sharing ordinary team membership, allowing a teamlead to retrieve another user's descriptions, timing data, tags, rate, and internalRate even though GET /api/timesheets/{id} would deny access through TimesheetVoter. This issue is fixed in version 2.57.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
Kimai is a widely deployed open-source time tracking application used by organizations to monitor employee productivity, billable hours, and project expenditures. The vulnerability identified affects the REST API endpoint GET /api/timesheets prior to version 2.57.0. This specific endpoint serves as a list view for timesheet records, allowing administrators or team leads to retrieve aggregated data about time entries across multiple users within their scope of authority. While the application implements role-based access control through Symfony voters such as TimesheetVoter to enforce granular permissions on individual resource actions like viewing a single record via GET /api/timesheets/{id}, this security logic was not consistently applied to the bulk retrieval endpoint, creating an authorization bypass flaw.
The technical root cause lies in the implementation of the TimesheetController::cgetAction method. When processing requests from users holding the view_other_timesheet permission, the controller accepts target user identifiers provided via query parameters such as user and users[]. However, it fails to enforce critical access controls that are present elsewhere in the application logic. Specifically, the code does not verify whether a requester with the ROLE_TEAMLEAD role actually leads the team containing each of the targeted users. Furthermore, while project and customer filtering mechanisms exist, they only restrict results based on ordinary team membership or scoped projects rather than strict hierarchical ownership. This allows a team lead to bypass intended restrictions by manipulating these parameters to include timesheet records belonging to individuals outside their direct supervisory chain or those associated with shared but unscoped resources.
The operational impact of this vulnerability is significant, as it enables an authenticated attacker with the role of team leader to perform unauthorized data exfiltration. By exploiting the lack of proper access verification in the list endpoint, the attacker can retrieve sensitive personal and financial information belonging to other employees. This includes detailed descriptions of work performed, precise timing data indicating when tasks were completed, associated tags for categorization, billable rates, and internal cost rates. Such exposure violates principles of confidentiality and could lead to privacy breaches under regulations like GDPR or HIPAA if applicable, as well as potential competitive intelligence leaks regarding project costs and labor allocation strategies within the organization.
This flaw is categorized under CWE-284 Improper Access Control, specifically reflecting a failure in authorization logic where access decisions are not consistently enforced across different API endpoints for similar resources. In terms of adversarial tactics, this vulnerability aligns with ATT&CK technique T1078 Valid Accounts and potentially T1530 Data from Cloud Storage Object if the data is exfiltrated to an external location, as it involves abusing legitimate credentials to access restricted information. The inconsistency between the granular checks in TimesheetVoter for individual record access and the lax validation in the bulk list endpoint represents a common architectural oversight where security controls are applied at one level of abstraction but neglected at another.
To mitigate this vulnerability, organizations must upgrade Kimai to version 2.57.0 or later, which contains patches that enforce consistent authorization checks across all timesheet retrieval endpoints. Until an upgrade is feasible, administrators should restrict the view_other_timesheet permission to only those users who strictly require it for operational purposes and ensure that team structures are accurately configured so that no unauthorized cross-team access is possible through existing filtering mechanisms. Additionally, implementing strict input validation on user identifiers passed via query parameters can help prevent enumeration attacks where attackers attempt to iterate through user IDs to discover valid targets even if the primary authorization check were partially effective. Regular security audits of API endpoints should be conducted to ensure that bulk operations adhere to the same stringent access control policies as individual resource actions, thereby closing gaps created by inconsistent implementation of role-based access controls.