GHSA-J5MC-P8QG-39J7

Kimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user's timesheet.id can add that record to, or remove it from, the victim's favorite/recent bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.

Details

The issue affects the following routes:

• GET /en/favorite/timesheet/add/{id}
• GET /en/favorite/timesheet/remove/{id}

Both endpoints accept a user-controlled timesheet identifier and only require the caller to hold the generic start_own_timesheet permission. They do not verify that the referenced Timesheet object belongs to the currently authenticated user.

• In src/Controller/FavoriteController.php, the controller methods accept a Timesheet object directly and forward it to the favorite service.
• The root cause becomes more obvious in src/Timesheet/FavoriteRecordService.php. The bookmark owner is derived from $timesheet->getUser() instead of the current session user.
• Because of this design, any authenticated user who can reference another user's timesheet ID can modify the victim's favorite/recent bookmark data.

A PoC was provided, but removed for security reasons.

This vulnerability allows any authenticated low-privileged user to manipulate another user's favorite bookmark state across accounts. An attacker can inject arbitrary victim-owned timesheet entries into the victim's quick-entry workflow, remove existing favorites, and repeatedly disturb the victim's normal timesheet usage without needing administrative privileges.

The issue does not directly disclose sensitive data, but it is a real cross-user business-state tampering vulnerability with clear integrity impact. Because the add and remove endpoints can be combined, an attacker can reliably insert, remove, and reorder entries in another user's favorite/recent list.

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

Kodem intelligence

1. What is GHSA-J5MC-P8QG-39J7? GHSA-J5MC-P8QG-39J7 is a low-severity missing authorization vulnerability in kimai/kimai (composer), affecting versions <= 2.56.0. It is fixed in 2.57.0. The application does not perform an authorization check before performing a sensitive operation.
2. Which versions of kimai/kimai are affected by GHSA-J5MC-P8QG-39J7? kimai/kimai (composer) versions <= 2.56.0 is affected.
3. Is there a fix for GHSA-J5MC-P8QG-39J7? Yes. GHSA-J5MC-P8QG-39J7 is fixed in 2.57.0. Upgrade to this version or later.
4. Is GHSA-J5MC-P8QG-39J7 exploitable, and should I be worried? Whether GHSA-J5MC-P8QG-39J7 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-J5MC-P8QG-39J7 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-J5MC-P8QG-39J7? Upgrade kimai/kimai to 2.57.0 or later.