CVE-2026-84808 in Kimai
Summary
by MITRE • 09/02/2026
Kimai versions before 2.65.0 contain an authorization bypass vulnerability in the REST API timesheet collection endpoint that fails to enforce activity-team access controls. Users with view_other_timesheet permission can list timesheets using activities restricted to teams they do not belong to, bypassing intended data isolation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The identified security flaw resides within the Kimai time-tracking application, specifically affecting versions prior to 2.65.0. This vulnerability is classified as an authorization bypass in the REST API timesheet collection endpoint. The core technical issue stems from a failure in server-side access control logic when handling requests for timesheet data associated with specific activities. In a properly secured system, activity-based permissions should restrict visibility of related records to only those users who are members of the designated teams or have explicit individual grants. However, the implementation flaw allows any authenticated user possessing the view_other_timesheets permission to bypass these granular team-level restrictions. This means that while the application correctly enforces basic authentication and general viewing rights for other timesheets, it neglects to validate whether the requesting user is part of the specific team associated with the activity linked to the requested timesheet entries.
From a technical perspective, this represents a classic case of broken object level authorization or insufficient access control at the resource level. The vulnerability exploits the gap between high-level role permissions and low-level data isolation rules. When an API request is made to retrieve timesheets for a particular activity, the backend logic checks if the user has permission to view other people's timesheets but fails to cross-reference this against the team membership requirements defined by the activity configuration. Consequently, sensitive time-tracking data becomes accessible beyond its intended scope. This flaw undermines the principle of least privilege and compromises the integrity of multi-tenant or team-based workflows where strict separation of duties is required for accurate billing, resource allocation, and privacy compliance.
The operational impact of this vulnerability is significant in environments where Kimai is used by multiple teams with distinct projects and confidential time entries. Attackers who possess valid credentials with the view_other_timesheets permission can enumerate and extract timesheet data from activities they are not authorized to access. This could lead to unauthorized disclosure of internal project durations, client billing details, employee productivity metrics, or other sensitive operational intelligence. In organizations where time tracking is tied to financial invoicing or regulatory compliance such as GDPR for personal data handling, this exposure poses a direct risk to business confidentiality and legal standing. The ability to scrape historical timesheet data without detection further exacerbates the severity, as it allows for potential long-term surveillance of organizational activities by malicious insiders or compromised accounts.
This vulnerability aligns with CWE-284 Improper Access Control and is closely related to CWE-639 Authorization Bypass Through User-Controlled Key if the activity ID were manipulated, though here the bypass occurs through insufficient validation rather than key manipulation alone. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts, as it relies on legitimate credentials, and potentially T1530 Data from Cloud Storage Object or T1213 Data from Information Repositories if the timesheets are considered structured data repositories. The exploitation path involves authenticated API interaction rather than unauthenticated access, which limits the attack surface to internal users or those who have obtained valid session tokens through other means such as phishing or credential stuffing.
Mitigation strategies must prioritize immediate patching and configuration hardening. Administrators should upgrade Kimai to version 2.65.0 or later where this authorization logic has been corrected to properly enforce team-based access controls on the timesheet collection endpoint. Until an upgrade is feasible, organizations can implement compensating controls such as restricting the view_other_timesheets permission to a minimal set of trusted administrators rather than broad groups like managers or project leads who may not need cross-team visibility. Additionally, deploying a Web Application Firewall with rules that monitor for anomalous API access patterns involving timesheet endpoints could provide an additional layer of defense by detecting and blocking requests from users accessing resources outside their expected team boundaries. Regular auditing of user permissions and activity assignments is also recommended to ensure that the principle of least privilege is maintained across all teams within the organization.