Kimai: Teamlead authorization bypass in GET /api/timesheets allows reading other users' timesheet records without being teamlead of the targetGHSA-4m8q-55qv-9pwp
GHSA-4m8q-55qv-9pwp is a CWE-863 vulnerability in kimai/kimai. A fix is available for kimai/kimai — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-4m8q-55qv-9pwp.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
kimai/kimaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
GET /api/timesheets?user=<id> (and users[]=<id>) returns the targeted user's timesheet records to any caller that has the view_other_timesheet permission, without verifying that the caller is teamlead of any team containing the target user. The per-record endpoint GET /api/timesheets/{id} correctly enforces this check via TimesheetVoter/RolePermissionManager::checkTeamAccessTimesheet → checkTeamLeadAccess, but the list endpoint only filters projects/customers by team membership and never validates t.user. A ROLE_TEAMLEAD user can therefore enumerate any user's records — including the rate field — as long as those records are on a project with no team scoping (Kimai's default) or on any project that shares any team (membership, not lead) with the requester.
Details
Root cause: authorization mismatch between the per-record voter and the list endpoint.
Per-record path (correct)
src/Voter/TimesheetVoter.php:138:
if (!$this->permissionManager->checkTeamAccessTimesheet($subject, $user)) {
return false;
}
return $this->permissionManager->hasRolePermission($user, $permission . '_other_timesheet');
checkTeamLeadAccess (RolePermissionManager.php:143-160) requires isTeamleadOf (not just member) one of the target user's teams. The unit test testTeamleadDeniedWhenOnlyPlainMemberOfOwnerTeam (tests/Voter/TimesheetVoterTest.php:253-269) codifies this:
"a TEAMLEAD role with
view_other_timesheetmust not access another user's timesheet by being a plain team member — they must be the team's teamlead."
List path (vulnerable)
src/API/TimesheetController.php:97-119:
public function cgetAction(ParamFetcherInterface $paramFetcher, ..., UserRepository $userRepository): Response
{
$query = new TimesheetQuery(false);
$this->prepareQuery($query, $paramFetcher);
$seeAll = false;
if ($this->isGranted('view_other_timesheet')) {
/** @var array<int> $users */
$users = $paramFetcher->get('users');
$userId = $paramFetcher->get('user');
if ('all' === $userId) {
$seeAll = true;
} elseif (\is_string($userId) && $userId !== '') {
$users[] = (int) $userId;
}
if (!$seeAll) {
foreach ($userRepository->findByIds($users) as $user) {
$query->addUser($user); // <-- no teamlead-of-target check
}
}
}
...
config/packages/kimai.yaml:96,115 grants TIMESHEET_OTHER (which contains view_other_timesheet) to ROLE_TEAMLEAD, so the gate at line 103 passes for any teamlead. The user= / users[]= IDs are pushed straight into the query.
Net effect
For any victim bob who:
- has at least one team that the requester
aliceis not teamlead of (so the voter denies per-record access), AND - has timesheets either on a project with no team (Kimai's default), or on a project that shares any team with
alice(membership, not lead)
alice is denied via GET /api/timesheets/{id} but receives bob's records via GET /api/timesheets?user=<bob_id>.
Disclosed fields in the collection response include description, begin, end, duration, billable, exported, tags, rate, internalRate, plus project/activity/user IDs (Default/Collection serializer groups, Timesheet.php:164-173). rate is financial data that the per-record voter is supposed to gate via the separate view_rate_other_timesheet permission.
Why other proposed mitigations don't apply
- The
view_other_timesheetIsGrantedon the route is the only authorization layer in the list path; ROLE_TEAMLEAD has it globally. prepareQueryonly setscurrentUser, not authorization (BaseApiController.php:68-71).- The serializer does not filter
rateper caller — it is a staticDefault-group property. - Recent commit 20c7b03 "Re-usable ACL checks on teams" hardened the voter side but left the list endpoint unchanged.
A PoC was provided, but removed for security reasons.
Impact
- Authorization bypass: a
ROLE_TEAMLEAD(a non-admin role typically granted to multiple users in a Kimai instance) can read any other user's timesheet records - Financial data disclosure: the
rateandinternalRatefields are returned in the collection serializer group, leaking what gets billed/costed against any user's records. - PII / activity disclosure: per-entry
description,begin,end,duration,billable,exported, project/activity/customer IDs, and tags are leaked, allowing reconstruction of any user's activity timeline.
Solution
The list of requested user TimesheetController::cgetAction() is now guarded with the access_user permission.
The access_user permission verifies that the requesting user is allowed to see each of the requested user.
If any of the requested users may not be seen, the entire call will fail.
Find out more at https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | kimai/kimai | all versions | 2.57.0composer require kimai/kimai:^2.57.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for kimai/kimai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update kimai/kimai to 2.57.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4m8q-55qv-9pwp is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-4m8q-55qv-9pwp in your dependencies?
Find it across Packagist, including transitive dependencies.