CVE-2026-84807 in Kimai
Summary
by MITRE • 09/02/2026
Kimai (kimai/kimai) through 2.65.0 contains a business logic / improper authorization vulnerability in the default team creation endpoints. An authenticated user with project permission-management privileges can create or use a customer, project, or activity whose name matches an existing team; because the endpoints POST /api/customers/{id}/team, POST /api/projects/{id}/team, and POST /api/activities/{id}/team reuse an existing team of the same name and add the current user as teamlead without verifying that the user is authorized to manage that team, the attacker gains unauthorized team-lead (administration) rights over the existing team. Fixed in 2.65.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Kimai versions through 2.65.0 represents a critical business logic flaw rooted in improper authorization controls within the application's API endpoints for managing teams associated with customers, projects, and activities. Specifically, the POST /api/customers/{id}/team, POST /api/projects/{id}/team, and POST /api/activities/{id}/team endpoints exhibit a failure to validate whether an authenticated user possesses administrative privileges over a target team before granting them leadership rights. The core technical flaw lies in the application's logic for handling team creation or association requests where the requested team name matches an existing team within the system rather than creating a new entity. Instead of rejecting such requests due to insufficient permissions, the software erroneously reuses the existing team record and automatically assigns the requesting user as the team lead without performing adequate access control checks against that specific resource's ownership or administrative hierarchy.
This design defect allows any authenticated user who holds project permission-management privileges to escalate their authority significantly. By simply initiating a request with a name identical to an existing team, the attacker can hijack administrative control over that team. Once this operation is successful, the attacker gains full administration rights, including the ability to manage members, modify settings, and potentially access sensitive data associated with the team's projects or customers. This constitutes a severe privilege escalation vulnerability because it bypasses the intended separation of duties within the application's role-based access control model. The impact extends beyond mere administrative convenience; an attacker could manipulate time tracking records, alter project configurations, or exfiltrate confidential client information depending on the scope of data accessible to team leads in their specific deployment environment.
From a classification perspective, this vulnerability aligns with CWE-269, which denotes Improper Privilege Management, as it involves granting elevated access rights without proper verification of user authority. It also maps closely to CWE-862, Missing Authorization, since the application fails to enforce that the actor is authorized for the requested action on the specific resource. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1078, Valid Accounts, specifically within the context of Local Account manipulation or privilege escalation via misconfigured permissions. The vulnerability highlights a common pitfall in RESTful API design where business logic rules for entity resolution are not sufficiently decoupled from access control validation layers.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. As indicated, the issue has been resolved in version 2.65.0 of Kimai, so upgrading to this patched version is the primary recommendation. For organizations unable to upgrade immediately, implementing a web application firewall rule to monitor for anomalous patterns in team-related API calls may provide limited protection, though it is not a substitute for code-level fixes. Developers should ensure that all endpoints performing state-changing operations verify the user's current role and permissions against the specific resource being modified before executing any logic that alters ownership or leadership status. Additionally, implementing strict input validation to prevent name collisions during team creation processes can reduce the attack surface by forcing distinct entity identification rather than allowing ambiguous reuse of existing names without explicit administrative consent.