CVE-2026-52820 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.57.0, PATCH /api/timesheets/{id} and POST /api/timesheets accept a user-controlled project identifier through TimesheetApiEditForm and FormTrait, and ProjectRepository::getQueryBuilderForFormType() places that identifier in an unconditional OR branch that bypasses the team access criteria. Any authenticated user with edit_own_timesheet can therefore assign an owned timesheet to a project outside the user's teams, persist unauthorized project attribution, and retrieve project and customer metadata through GET /api/timesheets/{id}?full=true. TimesheetTeamAccessValidator now checks changed project and activity associations against current team access. This issue is fixed in version 2.57.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 time tracking application designed for freelancers, agencies, and enterprises to monitor work hours across various projects and clients. The software relies on role-based access control mechanisms to ensure that users can only interact with resources they are authorized to view or modify. However, in versions prior to 2.57.0, a critical logic flaw existed within the API layer responsible for managing timesheet records. This vulnerability stems from improper implementation of authorization checks during data modification operations, specifically affecting the PATCH /api/timesheets/{id} and POST /api/timesheets endpoints. The core issue lies in how user-supplied input is processed by the TimesheetApiEditForm and FormTrait classes before being persisted to the database via ProjectRepository::getQueryBuilderForFormType().
The technical root cause of this vulnerability involves an unconditional OR branch within the query builder logic used for form type processing. When a user submits a request to edit or create a timesheet, they can provide a project identifier as part of the payload. The application accepts this input and places it into a database query using an OR condition that does not adequately verify whether the specified project is accessible under the current team access criteria. This design flaw effectively bypasses the intended security controls that restrict users to their assigned teams or projects. Consequently, the system fails to validate if the authenticated user has permission to associate their timesheet with the provided external project before saving the record.
This architectural weakness allows any authenticated user possessing the edit_own_timesheet privilege to perform an unauthorized assignment of their timesheets to arbitrary projects outside their designated team scope. By manipulating this parameter, attackers can persist false attribution data within the database, making it appear as though they worked on restricted or confidential projects that are not part of their authorized portfolio. This manipulation compromises the integrity of time tracking records and billing reports which rely on accurate project associations for financial calculations and resource allocation analysis.
Beyond simple misattribution, this vulnerability facilitates information disclosure through related API endpoints. Once a user successfully assigns an unauthorized timesheet to a restricted project, they can exploit the GET /api/timesheets/{id}?full=true endpoint to retrieve detailed metadata associated with that project. This includes sensitive customer details and internal project configurations that should remain inaccessible to users without explicit team membership or administrative privileges. The ability to enumerate and extract this data expands the impact from mere record tampering to a broader confidentiality breach, potentially exposing business-critical information about client relationships and operational structures.
From an industry standard perspective, this vulnerability aligns with CWE-269 Improper Privilege Management due to the failure of the application to enforce proper access control policies during state-changing operations. It also reflects aspects of CWE-862 Missing Authorization where the system does not verify user permissions before allowing actions on specific resources. In terms of threat modeling, this behavior is consistent with MITRE ATT&CK technique T1078 Valid Accounts combined with lateral movement or privilege escalation concepts, as an attacker leverages valid credentials to access and manipulate data outside their authorized scope for intelligence gathering or further exploitation.
The operational impact extends beyond immediate data integrity issues. Accurate time tracking is often tied to payroll processing, client invoicing, and project profitability analysis. Unauthorized modifications can lead to significant financial discrepancies, legal liabilities regarding billing accuracy, and erosion of trust among stakeholders who rely on the system for resource planning. Furthermore, the ability to access restricted customer metadata could aid attackers in crafting more targeted social engineering attacks or identifying high-value targets within an organization based on client profiles exposed through the API response.
Mitigation strategies primarily involve upgrading the Kimai installation to version 2.57.0 or later, where this issue has been resolved. The fix introduces a new TimesheetTeamAccessValidator that rigorously checks changed project and activity associations against current team access permissions before allowing any modifications to persist in the database. This ensures that users cannot assign timesheets to projects they do not have explicit permission to view or edit. For organizations unable to upgrade immediately, implementing strict input validation at the API gateway level and reviewing audit logs for unusual patterns of timesheet project assignments can provide temporary defense-in-depth measures until a permanent patch is applied.