Kimai CVE-2026-80202

The attacker must possess a valid authenticated Kimai account carrying ROLE_TEAMLEAD, or any role that grants the edit_other_timesheet or delete_other_timesheet permission, and API access (token) to the instance. No team membership with the victim and no user interaction are required, and the deployment does not need any non-default feature enabled - the flawed voter logic is present in default installations. Limiting factors: plain ROLE_USER accounts are correctly restricted (DELETE returns 403), so the attacker needs the elevated teamlead-level role; only affects Kimai <= 2.55.0. This means the realistic risk is insider/abused-privilege or account-compromise of a teamlead, not anonymous internet exploitation.

The signals are largely aligned toward high priority but with one caveat worth calling out. The published CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) rates this critical and treats it as unauthenticated (PR:N), yet the description and PoC make clear that exploitation requires an authenticated account with ROLE_TEAMLEAD or an equivalent edit_other/delete_other grant - ROLE_USER accounts are correctly blocked. That is a real conflict: PR should be at least Low, so the raw 9.3 slightly overstates the pre-conditions. That said, teamlead is a commonly delegated, non-administrative role, so the barrier is modest, and impact is severe and irreversible (permanent deletion of billing/payroll data plus silent tampering). No EPSS probability was supplied and the CVE is not in CISA KEV, so there is no evidence of mass or automated exploitation yet; however, working exploit code is public and the attack is trivially scriptable against sequential IDs. A further complicating signal: the maintainers characterize this behavior as matching Kimai's documented permission model, which may affect how the fix is perceived even though 2.56.0 changes the behavior. Net: any organization running multi-team Kimai with delegated teamleads should treat this as an urgent patch, since a single semi-trusted role can destroy financial records across the whole instance.

A disgruntled or compromised employee who holds ROLE_TEAMLEAD authenticates to the API with a valid token, enumerates sequential timesheet IDs (GET /api/timesheets/{id}), and issues DELETE requests to permanently wipe another team's billable hours or PATCH requests to inflate/deflate durations and flip billing flags - directly corrupting invoicing and payroll. A working PoC demonstrating read (HTTP 200), delete (HTTP 204), and tamper (HTTP 200) against Kimai 2.52.0 is published in the advisory. Given AV:N/AC:L and no user interaction, the entire attack is a short, easily scripted loop over integer IDs.