GHSA-9g2q-w3w2-vf7q: Kimai/kimai Kimai Has Missing Voter Check Vulnerability

MODERATE
CWE-863
Published
Advisory Summary

GHSA-9g2q-w3w2-vf7q is a MODERATE kimai has missing voter check vulnerability (CWE-863: Incorrect Authorization) affecting Kimai/kimai libraries in the Packagist ecosystem. The issue involves kimai has missing voter check that allows cross-team timesheet manipulation. Remediation is available by upgrading affected packages to version 2.56.0.

GHSA-9g2q-w3w2-vf7q at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-9g2q-w3w2-vf7q
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-863: Incorrect Authorization
Affected Product Kimai/kimai
Package Ecosystem Packagist
Published Date
Last Updated

How to Fix GHSA-9g2q-w3w2-vf7q

To remediate this vulnerability, upgrade all affected Kimai/kimai dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

kimai/kimai fixed: 2.56.0
Upgrade kimai/kimai to 2.56.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for kimai/kimai

How to Check if You Are Affected

To determine whether your application is affected by GHSA-9g2q-w3w2-vf7q, inspect your project dependencies for Kimai/kimai:

inspect dependencies for kimai/kimai

Analyze the terminal output to locate any version of Kimai/kimai in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.56.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where 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. In Kimai/kimai, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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.

GHSA-9g2q-w3w2-vf7q Affected Kimai/kimai Versions

1 component(s)
Fixed Versions:
2.56.0
Product / Package Ecosystem Affected Versions Fixed Version
kimai/kimai
Packagist
< 2.56.0
2.56.0

References

Frequently Asked Questions

What is GHSA-9g2q-w3w2-vf7q?
GHSA-9g2q-w3w2-vf7q is a security vulnerability in Kimai/kimai involving Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation under CWE-863: Incorrect Authorization.
Which Kimai/kimai versions are affected?
Affected versions include releases prior to 2.56.0 across affected packages: kimai/kimai.
What version fixes GHSA-9g2q-w3w2-vf7q?
Upgrading to 2.56.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is kimai/kimai affected?
Yes, kimai/kimai is affected in releases prior to 2.56.0. Upgrade your dependency to 2.56.0 or later.
What CWE is associated with GHSA-9g2q-w3w2-vf7q?
GHSA-9g2q-w3w2-vf7q is classified under CWE-863: Incorrect Authorization (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.).
How can I check Packagist dependencies for GHSA-9g2q-w3w2-vf7q?
Run the dependency tree command: 'inspect dependencies for kimai/kimai'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-9g2q-w3w2-vf7q",
  "modified" : "2026-05-06T18:28:46Z",
  "published" : "2026-05-06T18:28:45Z",
  "aliases" : [ ],
  "summary" : "Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation",
  "details" : "### Summary\n\nAny 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.\n\n### Details\n\n`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:\n\n```php\n// extend me for \"team\" support later on\nif ($subject->getUser()?->getId() === $user->getId()) {\n    $permission .= 'own';\n} else {\n    $permission .= 'other';\n}\n```\n\n### PoC\n\nTested against Kimai 2.52.0 Docker instance.\n\nSetup:\n- User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description \"Private timesheet - UserA only\"\n- User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A\n\n**User B reads User A's timesheet data:**\n\n```\nGET /api/timesheets/2 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: <userb_api_token>\n```\n\nResponse: HTTP 200 — returns full timesheet record including description \"Private timesheet - UserA only\".\n\n**User B deletes User A's timesheet:**\n\n```\nDELETE /api/timesheets/3 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: <userb_api_token>\n```\n\nResponse: HTTP 204 No Content — timesheet permanently deleted.\n\n**User B tampers User A's timesheet:**\n\n```\nPATCH /api/timesheets/6 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: <userb_api_token>\nContent-Type: application/json\n\n{\"begin\":\"2026-03-24T08:00:00\",\"end\":\"2026-03-24T18:00:00\",\"project\":1,\"activity\":1,\"description\":\"TAMPERED\",\"exported\":false,\"billable\":false}\n```\n\nResponse: HTTP 200 OK — duration inflated from 3600s to 36000s, description overwritten.\n\n**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.\n\n### Impact\n\nAny authenticated user with ROLE_TEAMLEAD or above can:\n\n1. Permanently delete timesheets belonging to any user system-wide — destroying billable hours, payroll data, and project billing history\n2. Silently alter timesheet descriptions, hours, and billing flags — forging hours up or down, directly affecting invoicing and payroll\n3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records\n\nNo user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.\n\n### Maintainers answer: why this is not eligible for a CVE\n\nThe behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to `ROLE_TEAMLEAD` are:\n\n- `edit_other_timesheet` — Edit existing records of other users\n- `delete_other_timesheet` — Delete existing records of other users\n\nThese 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.\n\nThe report frames this as authorization bypass, but no authorization boundary is being crossed: `ROLE_TEAMLEAD` is operating within its documented permissions.\n\nKimai 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.\n\n### Solution\n\nTeam-scoped timesheet permission checks were added in 2.56.0.\n\nOperators 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.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "kimai/kimai"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.56.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.55.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/kimai/kimai/security/advisories/GHSA-9g2q-w3w2-vf7q"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/kimai/kimai"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-06T18:28:45Z",
    "nvd_published_at" : null
  }
}