CVE-2026-80193 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.62.0 fails to validate create_other_timesheet permission in the QuickEntry controller when creating new timesheets. Authenticated users with view_other_timesheet and edit_other_timesheet permissions can create timesheet records for team members by submitting the QuickEntry form, bypassing authorization checks enforced elsewhere.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Kimai prior to version 2.62.0 represents a critical failure in access control logic within the application's time tracking module. Specifically, the issue resides in the QuickEntry controller, which is designed to facilitate rapid creation of timesheet entries for users who are actively working or need to log hours quickly. While the broader system enforces strict authorization checks requiring specific permissions such as view_other_timesheet and edit_other_timesheet for accessing or modifying records belonging to other team members, this validation logic was not consistently applied within the QuickEntry workflow. This inconsistency creates a path where authenticated users can bypass intended security boundaries by exploiting the less restrictive code path in the quick entry mechanism rather than navigating through standard administrative interfaces that properly enforce role-based access controls.
From a technical perspective, this flaw is classified as an Insecure Direct Object Reference or more accurately, a Broken Access Control vulnerability under CWE-284. The core issue stems from insufficient validation of user permissions when processing POST requests associated with the creation of new timesheet records via the QuickEntry endpoint. Although the application correctly checks for edit_other_timesheet privileges in other parts of the system to prevent unauthorized modifications, this check was omitted or incorrectly implemented within the specific controller handling quick entries. Consequently, any authenticated user possessing these elevated permissions can manipulate form data to assign work hours and project details to colleagues without proper oversight or authorization from those individuals' direct supervisors or administrators. This bypass allows for the manipulation of time records that should otherwise be protected by organizational hierarchy and role-based restrictions.
The operational impact of this vulnerability is significant, particularly in enterprise environments where accurate timesheet reporting drives billing, payroll, and project management decisions. An attacker with valid credentials can fabricate work hours for other team members, potentially leading to fraudulent billing if the organization relies on these records for client invoicing. Furthermore, it distorts internal resource allocation metrics, making it difficult for managers to assess actual productivity or workload distribution accurately. In severe cases, this could be leveraged to cover up unauthorized activities by attributing malicious actions during specific timeframes to other users, thereby complicating forensic investigations and incident response efforts. The ability to alter records without detection undermines the integrity of the entire timesheet system, eroding trust in data accuracy across departments.
Mitigation strategies must focus on enforcing consistent authorization checks across all entry points for modifying sensitive business objects. For organizations still running versions prior to 2.62.0, immediate patching is required as this issue has been resolved in subsequent releases by ensuring that the QuickEntry controller performs the same rigorous permission validation as other parts of the application. Administrators should also review existing audit logs if available to detect any potential exploitation attempts before the update is applied. Going forward, development practices should adopt a principle of least privilege and ensure that security checks are centralized or consistently replicated across all API endpoints and controllers handling user-modifiable data. This aligns with ATT&CK technique T1078, Valid Accounts, where attackers leverage legitimate credentials to bypass controls, highlighting the need for robust validation at every stage of request processing regardless of the entry method used by the authenticated user.