CVE-2026-52821 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.57.0, GET or POST requests to /en/admin/activity/create/{project} and /en/admin/project/create/{customer} require only the generic create_activity or create_project capability and do not verify edit access to the supplied Project or Customer object. A user who knows a valid project.id or customer identifier can use the preset-parent creation logic in src/Controller/ActivityController.php or src/Controller/ProjectController.php to persist a new child business object under an unauthorized parent, polluting project or customer configuration and influencing later time-entry, rate, reporting, and billing behavior. 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 solution for professional time tracking, enabling organizations to monitor employee hours, manage projects, and generate financial reports based on accumulated data. The integrity of this system relies heavily on strict access control mechanisms that ensure users can only modify resources they are explicitly authorized to edit. In versions prior to 2.57.0, a critical authorization flaw exists within the application's administrative endpoints for creating new activities and projects. Specifically, the HTTP GET or POST requests directed at /en/admin/activity/create/{project} and /en/admin/project/create/{customer} fail to perform adequate verification of edit permissions against the supplied Project or Customer object identifiers. This oversight allows any authenticated user who can guess or obtain a valid project ID or customer identifier to bypass intended restrictions on resource ownership.
The technical root cause lies in the preset-parent creation logic implemented within src/Controller/ActivityController.php and src/Controller/ProjectController.php. When a request is made, the application accepts the parent entity identifier provided by the user without validating whether that specific user has administrative or editing rights over the target parent object. Consequently, an attacker can exploit this lack of server-side authorization checks to persist new child business objects under unauthorized parents. This behavior constitutes an Insecure Direct Object Reference vulnerability, where the system trusts client-supplied identifiers for access control decisions rather than verifying them against internal permission matrices. By leveraging this flaw, a malicious actor with low-privilege access can inject data into high-level organizational structures that they should not be able to touch.
The operational impact of this vulnerability is significant and multifaceted, affecting the reliability of time tracking, billing, and reporting processes within an organization. An attacker who successfully exploits this issue can pollute project or customer configurations by adding unauthorized activities or sub-projects. This data pollution directly influences subsequent time-entry behaviors, as employees may inadvertently log hours against manipulated entries. Furthermore, it distorts rate calculations and financial reports, potentially leading to incorrect billing for clients or inaccurate internal cost allocations. In severe cases, this could be used to mask malicious activity by embedding fake transactions within legitimate project structures, thereby complicating forensic analysis and audit trails.
This vulnerability aligns with CWE-862, which describes Missing Authorization, as the application fails to enforce proper access controls on a protected resource. Additionally, it maps to MITRE ATT&CK technique T1078, Valid Accounts, where an attacker uses legitimate credentials to perform unauthorized actions within the system environment. The exploitation does not require complex injection techniques or privilege escalation beyond what is already granted by basic authentication; instead, it relies solely on the logical failure to validate permissions relative to specific resource identifiers.
To mitigate this risk, organizations running Kimai must immediately upgrade to version 2.57.0 or later, where these authorization checks have been corrected. For environments that cannot patch instantly due to operational constraints, temporary mitigations should focus on restricting access to the administrative interface through network-level controls such as IP whitelisting or multi-factor authentication for admin roles. Additionally, implementing strict input validation and ensuring that all backend controllers verify ownership or explicit edit permissions before processing creation requests is essential. Regular security audits of custom plugins or extensions are also recommended to ensure no similar logic flaws exist in other parts of the application stack.