VulnerabilityPublished 6 May 2026

kimai/kimai · Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation

Affects kimai/kimaiSource GCVE Database

Public exploit available · CVSS 7.1 High : upgrade to 2.56.0 as a priority.

Data as of 27 Oct 2026, 00:07 UTC

CVSS 4.0 base score

7.1High

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 2.56.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P

Base metrics

Attack Vector: Network
Attack Complexity: Low
Attack Requirements: None
Privileges Required: Low
User Interaction: None
Vulnerable system confidentiality: None
Vulnerable system integrity: High
Vulnerable system availability: None
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Threat metrics

Exploit Maturity: POC

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Attack Requirements: None: The successful attack does not depend on the deployment and execution conditions of the vulnerable system. The attacker can expect to be able to reach the vulnerability and execute the exploit under all or most instances of the vulnerability.
Privileges Required: Low: The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction: None: The vulnerable system can be exploited without interaction from any human user, other than the attacker.
Vulnerable system confidentiality: None: There is no loss of confidentiality within the Vulnerable System.
Vulnerable system integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the vulnerable system. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the vulnerable system.
Vulnerable system availability: None: There is no impact to availability within the Vulnerable System.
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.
Exploit Maturity: POC: Based on threat intelligence sources each of the following must apply: · Proof-of-concept is publicly available · No knowledge of reported attempts to exploit this vulnerability · No knowledge of publicly available solutions used to simplify attempts to exploit the vulnerability

Definitions: FIRST CVSS v4.0 specification.

What to do

Upgrade kimai/kimai to 2.56.0.

Affected software

Product	Affected	Fixed in
Packagistkimai/kimai	Affected <2.56.0	Fixed in 2.56.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary Any ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system — regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0. ### Details `TimesheetVoter::voteOnAttribute()` maps permissions to `own_timesheet` or `other_timesheet` without checking team membership. The voter's own comment confirms this is a known gap: ```php // extend me for "team" support later on if ($subject->getUser()?->getId() === $user->getId()) { $permission .= 'own'; } else { $permission .= 'other'; } ``` ### PoC Tested against Kimai 2.52.0 Docker instance. Setup: - User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description "Private timesheet - UserA only" - User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A **User B reads User A's timesheet data:** ``` GET /api/timesheets/2 HTTP/1.1 X-AUTH-USER: userb X-AUTH-TOKEN: <userb_api_token> ``` Response: HTTP 200 — returns full timesheet record including description "Private timesheet - UserA only". **User B deletes User A's timesheet:** ``` DELETE /api/timesheets/3 HTTP/1.1 X-AUTH-USER: userb X-AUTH-TOKEN: <userb_api_token> ``` Response: HTTP 204 No Content — timesheet permanently deleted. **User B tampers User A's timesheet:** ``` PATCH /api/timesheets/6 HTTP/1.1 X-AUTH-USER: userb X-AUTH-TOKEN: <userb_api_token> Content-Type: application/json {"begin":"2026-03-24T08:00:00","end":"2026-03-24T18:00:00","project":1,"activity":1,"description":"TAMPERED","exported":false,"billable":false} ``` Response: HTTP 200 OK — duration inflated from 3600s to 36000s, description overwritten. **Note:** ROLE_USER (userc) is correctly blocked — DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable. ### Impact Any authenticated user with ROLE_TEAMLEAD or above can: 1. Permanently delete timesheets belonging to any user system-wide — destroying billable hours, payroll data, and project billing history 2. Silently alter timesheet descriptions, hours, and billing flags — forging hours up or down, directly affecting invoicing and payroll 3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records No user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access. ### Maintainers answer: why this is not eligible for a CVE The behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to `ROLE_TEAMLEAD` are: - `edit_other_timesheet` — Edit existing records of other users - `delete_other_timesheet` — Delete existing records of other users These permissions were global by design, not team-scoped. The UI surfaces only the teamlead's own team timesheets, but the API has historically honored these permissions as documented: a role holding `*_other_timesheet` can act on any other user's timesheet. The inline comment `// extend me for "team" support later on` reflects this accurately — team-scoped enforcement was a planned enhancement, not a security control that existed and failed. The report frames this as authorization bypass, but no authorization boundary is being crossed: `ROLE_TEAMLEAD` is operating within its documented permissions. Kimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications. ### Solution Team-scoped timesheet permission checks were added in 2.56.0. Operators of Kimai <= 2.55 who need stricter isolation between teamleads should not grant `ROLE_TEAMLEAD` to users who must not act on other teams' timesheets.

CWE-863Incorrect Authorization (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #17OWASP Top 10 A01:2025: Broken Access Control (opens in a new tab)
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Architecture and Design
Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
Architecture and Design
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records.
Architecture and Design · Libraries or Frameworks
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
OWASP Cheat Sheets
Authorization (opens in a new tab)
OWASP ASVS 4.0.3
V8.3.8 (opens in a new tab)
V13.4.2 (opens in a new tab)
V7.2.2 (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

WeaknessesCWE-863

Technical details

References

Community reviews

Related threats