CVE-2026-52822 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.58.0, PATCH /api/timesheets/{id}/restart, PATCH /api/timesheets/{id}/duplicate, and the web duplicate workflow can derive a new record from an owned historical timesheet after the user's access to its project or activity has been revoked. TimesheetVoter evaluates the own-timesheet permission before current team access, and its canStart() logic validates object visibility but does not verify the user's current team access to the referenced project and activity. An old entry therefore acts as a persistent capability to create new time records under an unauthorized project and activity, corrupting budgets, statistics, reports, and invoices after an administrative revocation. This issue is fixed in version 2.58.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
Kimai serves as a widely adopted open-source solution for professional time tracking, enabling organizations to monitor labor hours against specific projects and activities with precision. The integrity of this system relies heavily on the enforcement of role-based access controls that dynamically adjust user permissions based on their current team memberships or project assignments. However, in versions prior to 2.58.0, a critical logic flaw exists within the application's authorization layer, specifically affecting the API endpoints for restarting and duplicating timesheets as well as the corresponding web interface workflow. This vulnerability allows users to bypass access restrictions that should have been enforced after their permissions were revoked by an administrator.
The technical root cause of this issue lies in the implementation of the TimesheetVoter class, which is responsible for evaluating whether a user has permission to perform actions on specific timesheet objects. The voter prioritizes checking if a timesheet belongs to the current user before validating broader team-based access controls. While the canStart() method correctly verifies that the object itself is visible to the user, it fails to re-evaluate the user's current authorization status regarding the project and activity referenced by that historical record. Consequently, once a user has legitimately created or accessed a timesheet entry while they had appropriate permissions, that specific data structure retains an implicit capability to spawn new records even after the underlying access rights have been withdrawn.
This design flaw creates a persistent privilege escalation vector where revoked users can effectively maintain unauthorized control over time tracking operations. By leveraging the restart and duplicate functionalities on old entries, these individuals can generate new timesheet records under projects or activities they no longer have permission to view or edit. This behavior circumvents the intended security boundaries established by system administrators who rely on dynamic access revocation to secure sensitive data after employees leave teams or organizations. The vulnerability is particularly insidious because it does not require exploiting a buffer overflow or injection flaw but rather abuses the logical flow of existing, legitimate features in an unintended manner.
The operational impact of this vulnerability extends beyond simple unauthorized access and directly compromises the financial and analytical integrity of the organization's time tracking data. Since new records can be created under restricted projects, budgets may become corrupted with unapproved labor hours that skew cost analyses. Statistical reports generated from this tainted data will provide inaccurate insights into productivity and resource allocation. Furthermore, if Kimai is integrated with billing systems or invoicing software, these unauthorized entries could lead to incorrect client invoices, resulting in direct financial loss and potential legal liabilities for the organization. The ability to inject false historical data also undermines audit trails, making it difficult to detect when such tampering has occurred without deep forensic analysis of database logs.
To mitigate this risk, organizations running Kimai must upgrade immediately to version 2.58.0 or later, where the TimesheetVoter logic has been corrected to enforce current team access checks alongside object visibility validation. Until an upgrade is performed, administrators should monitor for unusual patterns in timesheet creation timestamps and review audit logs for duplicate entries associated with users who have recently had their permissions modified. Implementing strict database-level constraints or additional application-layer validations that re-verify project membership at the moment of record creation can also serve as a temporary compensating control. This incident highlights the importance of ensuring that authorization checks are stateless regarding user privileges and do not rely solely on static ownership attributes when dynamic access controls are in play, aligning with best practices for preventing broken object level permissions as defined by industry standards such as CWE-639.