GHSA-4M8Q-55QV-9PWP

Vulnerability from github – Published: 2026-07-13 23:55 – Updated: 2026-07-13 23:55

Summary

Kimai: Teamlead authorization bypass in GET /api/timesheets allows reading other users' timesheet records without being teamlead of the target

Details

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_timesheet must 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 alice is 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_timesheet IsGranted on the route is the only authorization layer in the list path; ROLE_TEAMLEAD has it globally.
prepareQuery only sets currentUser, not authorization (BaseApiController.php:68-71).
The serializer does not filter rate per caller — it is a static Default-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 rate and internalRate fields 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

Severity

6.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.56.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.57.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T23:55:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`GET /api/timesheets?user=\u003cid\u003e` (and `users[]=\u003cid\u003e`) returns the targeted user\u0027s 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` \u2192 `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\u0027s records \u2014 including the `rate` field \u2014 as long as those records are on a project with no team scoping (Kimai\u0027s default) or on any project that shares any team (membership, not lead) with the requester.\n\n## Details\n\n**Root cause:** authorization mismatch between the per-record voter and the list endpoint.\n\n### Per-record path (correct)\n\n`src/Voter/TimesheetVoter.php:138`:\n```php\nif (!$this-\u003epermissionManager-\u003echeckTeamAccessTimesheet($subject, $user)) {\n    return false;\n}\nreturn $this-\u003epermissionManager-\u003ehasRolePermission($user, $permission . \u0027_other_timesheet\u0027);\n```\n\n`checkTeamLeadAccess` (RolePermissionManager.php:143-160) requires `isTeamleadOf` (not just member) one of the **target user\u0027s** teams. The unit test `testTeamleadDeniedWhenOnlyPlainMemberOfOwnerTeam` (tests/Voter/TimesheetVoterTest.php:253-269) codifies this:\n\n\u003e *\"a TEAMLEAD role with `view_other_timesheet` must not access another user\u0027s timesheet by being a plain team member \u2014 they must be the team\u0027s teamlead.\"*\n\n### List path (vulnerable)\n\n`src/API/TimesheetController.php:97-119`:\n```php\npublic function cgetAction(ParamFetcherInterface $paramFetcher, ..., UserRepository $userRepository): Response\n{\n    $query = new TimesheetQuery(false);\n    $this-\u003eprepareQuery($query, $paramFetcher);\n    $seeAll = false;\n\n    if ($this-\u003eisGranted(\u0027view_other_timesheet\u0027)) {\n        /** @var array\u003cint\u003e $users */\n        $users = $paramFetcher-\u003eget(\u0027users\u0027);\n        $userId = $paramFetcher-\u003eget(\u0027user\u0027);\n\n        if (\u0027all\u0027 === $userId) {\n            $seeAll = true;\n        } elseif (\\is_string($userId) \u0026\u0026 $userId !== \u0027\u0027) {\n            $users[] = (int) $userId;\n        }\n\n        if (!$seeAll) {\n            foreach ($userRepository-\u003efindByIds($users) as $user) {\n                $query-\u003eaddUser($user);   // \u003c-- no teamlead-of-target check\n            }\n        }\n    }\n    ...\n```\n\n`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.\n\n### Net effect\n\nFor any victim `bob` who:\n- has at least one team that the requester `alice` is **not** teamlead of (so the voter denies per-record access), AND\n- has timesheets either on a project with no team (Kimai\u0027s default), or on a project that shares any team with `alice` (membership, not lead)\n\n`alice` is denied via `GET /api/timesheets/{id}` but receives `bob`\u0027s records via `GET /api/timesheets?user=\u003cbob_id\u003e`.\n\nDisclosed 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.\n\n### Why other proposed mitigations don\u0027t apply\n- The `view_other_timesheet` `IsGranted` on the route is the only authorization layer in the list path; ROLE_TEAMLEAD has it globally.\n- `prepareQuery` only sets `currentUser`, not authorization (BaseApiController.php:68-71).\n- The serializer does not filter `rate` per caller \u2014 it is a static `Default`-group property.\n- Recent commit 20c7b03 \"Re-usable ACL checks on teams\" hardened the voter side but left the list endpoint unchanged.\n\n*A PoC was provided, but removed for security reasons.*\n\n## Impact\n\n- **Authorization bypass**: a `ROLE_TEAMLEAD` (a non-admin role typically granted to multiple users in a Kimai instance) can read any other user\u0027s timesheet records\n- **Financial data disclosure**: the `rate` and `internalRate` fields are returned in the collection serializer group, leaking what gets billed/costed against any user\u0027s records.\n- **PII / activity disclosure**: per-entry `description`, `begin`, `end`, `duration`, `billable`, `exported`, project/activity/customer IDs, and tags are leaked, allowing reconstruction of any user\u0027s activity timeline.\n\n# Solution\n\nThe list of requested user `TimesheetController::cgetAction()` is now guarded with the `access_user` permission.\nThe `access_user` permission verifies that the requesting user is allowed to see each of the requested user.\nIf any of the requested users may not be seen, the entire call will fail.\n\nFind out more at [https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp](https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp)",
  "id": "GHSA-4m8q-55qv-9pwp",
  "modified": "2026-07-13T23:55:16Z",
  "published": "2026-07-13T23:55:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-4m8q-55qv-9pwp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai: Teamlead authorization bypass in GET /api/timesheets allows reading other users\u0027 timesheet records without being teamlead of the target"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

GHSA-4M8Q-55QV-9PWP

Summary

Details

Per-record path (correct)

List path (vulnerable)

Net effect

Why other proposed mitigations don't apply

Impact

Solution

Tags

Sightings

Nomenclature