CVE-2026-52825 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.58.0, POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId} verify that a teamlead may edit the Team but do not verify access_user for the referenced User or view access for the referenced Activity. A teamlead can add users or activities outside the teamlead's manageable scope to an editable team, bypassing the narrower choices enforced by TeamEditForm and UserRepository::getQueryBuilderForFormType(). The resulting relationships can be trusted by RolePermissionManager::checkTeamAccessActivity() and other team-based authorization, visibility, reporting, and workflow logic. This issue is fixed in version 2.58.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
Kimai is a widely deployed open-source time tracking application used by organizations to monitor employee productivity and project expenditures. A critical security flaw was identified in versions prior to 2.58.0, specifically affecting the API endpoints POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId}. These endpoints are designed to allow team leaders to manage team composition by adding members or linking activities to a specific team. The vulnerability stems from an incomplete authorization check within these API handlers. While the system correctly verifies that the authenticated user holds the role of a team leader for the specified team, it fails to validate whether the target user ID belongs to a member who is actually part of that team's scope, or if the referenced activity ID falls under activities accessible by that specific team lead.
This oversight creates an authorization bypass vulnerability where a malicious actor with legitimate team leadership privileges can manipulate relationships outside their intended administrative boundaries. By exploiting this flaw, an attacker can add users to a team who are not supposed to be members of that group or link activities that the leader does not have permission to manage. This behavior directly contradicts the constraints enforced by the frontend components such as TeamEditForm and backend repository methods like UserRepository::getQueryBuilderForFormType(), which typically restrict choices based on existing permissions. The API layer, however, operates with a broader scope than intended, allowing for unauthorized data manipulation that bypasses these granular controls.
The operational impact of this vulnerability is significant because the resulting invalid relationships are subsequently trusted by downstream authorization and logic components within Kimai. Specifically, functions such as RolePermissionManager::checkTeamAccessActivity() rely on the integrity of team membership and activity associations to determine visibility, reporting capabilities, and workflow permissions. Consequently, an attacker can effectively grant unauthorized users access to sensitive project data or manipulate time entries for activities they should not be able to view or edit. This undermines the core security model of the application, potentially leading to data leakage, inaccurate billing reports, and compromised audit trails within organizational workflows.
From a classification perspective, this issue aligns with CWE-269 Improper Privilege Management, as it involves an actor obtaining privileges that they are not authorized to have by bypassing intended access controls. It also relates to CWE-862 Missing Authorization, where the application fails to enforce proper checks on user actions regarding specific resources. In terms of attack vectors and tactics, this vulnerability can be leveraged in conjunction with ATT&CK techniques such as T1078 Valid Accounts, since it requires a legitimate team lead account, and potentially contributes to lateral movement or privilege escalation within the context of time tracking data integrity if combined with other exploitation methods.
To mitigate this risk, organizations running Kimai must upgrade immediately to version 2.58.0 or later, where these authorization checks have been corrected to ensure that both user membership and activity accessibility are validated against the team leader's actual scope before allowing modifications. For environments unable to patch immediately due to operational constraints, network-level controls such as Web Application Firewalls can be configured to restrict access to these specific API endpoints based on strict IP whitelisting or additional authentication factors until an upgrade is feasible. Additionally, administrators should review existing team configurations for any anomalous user memberships or activity links that may have been introduced during the window of vulnerability and remove them manually if necessary.