Description

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.)

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-26T05:18:27.980Z",
  "pubdate": "2026-08-26T05:18:27.980Z",
  "executiveSummary": "Kimai versions prior to 2.56.0 contain an authorization bypass vulnerability within the TimesheetVoter component. The vulnerability is classified as an Improper Access Control issue, stemming from a failure to enforce team-membership validation during attribute evaluation.\nThe vulnerability allows authenticated users assigned the ROLE_TEAMLEAD role (or any role possessing edit_other_timesheet or delete_other_timesheet permissions) to perform unauthorized CRUD operations on timesheets belonging to any user across the entire application instance.\nBecause timesheet IDs are implemented as sequential integers, an attacker can trivially enumerate these records. This flaw bypasses the intended multi-tenancy and team-based access control models, exposing sensitive time-tracking data to unauthorized parties. The impact includes unauthorized disclosure, modification, and permanent deletion of system-wide timesheet records. Exploitation requires authenticated access to the application, specifically utilizing an account with elevated team-level permissions. While maintainers have noted this behavior aligns with their documented permission model, the lack of team-scoped constraints constitutes a significant privilege escalation risk for organizations relying on team segmentation.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the TimesheetVoter::voteOnAttribute() function within the Kimai application core. The voter logic facilitates permission checks but fails to incorporate a validation step to verify if the requesting user and the target timesheet entity share common team membership.\nIn the affected versions, the authorization logic evaluates permissions based solely on the presence of generic attributes such as own_timesheet or other_timesheet. Once a user is granted the ROLE_TEAMLEAD role, the system inherently assumes that the user possesses broad authority over records categorized under the 'other_timesheet' scope. Because the code lacks a cross-reference between the current user's team ID and the owner's team ID of the requested timesheet, the application permits cross-team operations.\nThe attack vector relies on the predictability of the object identifier scheme. Kimai assigns sequential integer IDs to timesheet records, which allows an attacker to perform brute-force enumeration. By iterating through these integer values via the API, a malicious actor can systematically query the endpoint to access timesheets that are not intended for their view or modification.\nThe exploitation flow proceeds as follows: First, an authenticated attacker with at least ROLE_TEAMLEAD permissions identifies an endpoint used for retrieving or modifying timesheets. Second, the attacker increments the sequential ID parameter in the API request. Third, the TimesheetVoter::voteOnAttribute() function triggers. Because the function checks only for the permission flag and ignores the team boundary, the authorization check returns a positive result (granting access). Fourth, the backend processes the request, allowing the attacker to read, update, or delete records belonging to arbitrary users across the platform.\nThis vulnerability is restricted to the API layer where TimesheetVoter is invoked. While standard ROLE_USER accounts are correctly restricted by the current voter logic, the elevation to ROLE_TEAMLEAD provides an unintended level of administrative-like access to records that should remain isolated within the specific team context. The post-exploitation impact includes the loss of data integrity, unauthorized data extraction, and potential disruption of business operations through the permanent deletion of logs."
}