CVE-2026-80195 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.63.0 contains a business logic / improper authorization vulnerability in the team update API endpoint (PATCH /api/teams/{id}), which removes all existing team members before validating the submitted replacement member list. An authenticated teamlead (or other user) with permission to edit a team can submit a malformed members payload; although Kimai returns a validation error, the existing membership rows have already been deleted. This bypasses the dedicated member-removal endpoint's protection against removing teamleaders and can leave a team with no members or teamleaders, disrupting team-based access control.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in versions of Kimai prior to 2.63.0 represents a critical failure in business logic enforcement within the application's API layer, specifically affecting the PATCH /api/teams/{id} endpoint used for updating team configurations. This flaw is categorized under CWE-841 Improper Enforcement of Business Logic and aligns with ATT&CK technique T1546 Event Triggered Execution if leveraged to disrupt operational continuity through denial of service conditions. The core technical issue stems from an incorrect sequence of operations during the update process, where the system prioritizes data removal over validation integrity checks. When a user possessing team lead privileges or specific edit permissions submits a request to modify team membership by providing a new list of members, the backend implementation immediately executes database commands to delete all existing rows associated with that team's member table before performing any syntactic or semantic validation on the incoming payload.
This architectural flaw creates a race condition-like state where data loss occurs regardless of whether the subsequent validation step succeeds or fails. In standard secure design patterns, such as those recommended by OWASP for API security best practices, input validation should precede any side effects that modify persistent storage to ensure atomicity and consistency. By removing existing members first, the application violates these principles, leading to a scenario where an authenticated attacker can exploit this sequence error even if their submitted payload is malformed or rejected due to missing required fields or invalid user identifiers. The system returns a validation error response indicating failure, yet the database state has already been irreversibly altered by stripping all current associations from the team record.
The operational impact of this vulnerability extends beyond simple data inconsistency; it fundamentally undermines the integrity of role-based access control mechanisms within Kimai. Teams are central to organizing user permissions and project assignments in the application. By deleting existing members without ensuring a valid replacement set is successfully committed, an attacker can effectively orphan teams, leaving them with no assigned users or team leaders. This disruption prevents legitimate administrators from managing resources associated with those teams and may cause cascading failures in reporting, billing, and access control systems that rely on accurate membership data. Furthermore, this behavior bypasses the protective logic present in dedicated member-removal endpoints which are designed to prevent the accidental removal of critical roles such as team leaders.
Mitigation strategies must focus on correcting the transactional integrity of the update operation. The most effective remediation is to refactor the API endpoint implementation so that validation occurs prior to any database write operations, ensuring that deletions only proceed if the new member list passes all business rule checks. Alternatively, implementing a two-phase commit approach or using temporary storage for proposed changes until they are validated can prevent premature data loss. For organizations unable to immediately patch their Kimai instances to version 2.63.0 or later, restricting API access through network-level controls and monitoring logs for unusual patterns of team updates with subsequent validation errors may help detect exploitation attempts. Immediate application of the vendor-provided security update is strongly recommended to restore proper authorization logic and prevent unauthorized disruption of team structures.