CVE-2026-84808: Kimai REST API Auth Bypass Vulnerability

CVE-2026-84808 Overview

Kimai versions before 2.65.0 contain an authorization bypass vulnerability in the REST API timesheet collection endpoint. The endpoint fails to enforce activity-team access controls when returning timesheet data. Authenticated users holding the view_other_timesheet permission can list timesheets tied to activities restricted to teams they do not belong to. This bypasses the intended data isolation between teams and exposes timesheet records to unauthorized personnel. The flaw is classified under CWE-863: Incorrect Authorization and affects the confidentiality of timesheet data managed by the Kimai time-tracking application.

Critical Impact
Authenticated low-privilege users can enumerate timesheet records belonging to teams they are not authorized to access, breaking activity-based team isolation.

Affected Products

Kimai time-tracking application, all versions prior to 2.65.0
Deployments exposing the REST API /api/timesheets collection endpoint
Instances relying on team-scoped activity restrictions for data isolation

Discovery Timeline

2026-09-02 - CVE-2026-84808 published to the National Vulnerability Database
2026-09-02 - Last updated in NVD database

Technical Details for CVE-2026-84808

Vulnerability Analysis

Kimai enforces access controls through a combination of permissions and team memberships. Activities can be restricted to specific teams so that only members of those teams may view associated timesheet records. The REST API timesheet collection endpoint bypasses the activity-team scoping check when listing timesheets. Any authenticated user who holds the view_other_timesheet permission receives records regardless of whether they belong to the team that owns the referenced activity.

The defect is a REST API vulnerability rooted in a missing authorization check rather than a broken authentication mechanism. Attackers do not need to escalate privileges or forge tokens. They only need a valid account with the view_other_timesheet permission, which is a common role assignment in multi-team Kimai deployments.

Root Cause

The timesheet collection query filters results by user-level permission but does not intersect that filter with the caller's team membership relative to the activity attached to each timesheet. The activity-team relationship is validated in the web UI code path yet omitted in the API controller's query builder. This inconsistency between UI and API enforcement is the underlying authorization gap.

Attack Vector

Exploitation is network-based and requires a low-privilege authenticated session. An attacker with the view_other_timesheet permission issues a GET request to the timesheet collection endpoint, optionally filtering by activity identifiers belonging to restricted teams. The API returns timesheet records for those activities even though the caller is not a member of the owning team. No user interaction is required, and no additional exploitation primitives are needed beyond a valid API token or session cookie. See the GitHub Security Advisory GHSA-c6j4-35fc-x3hw and the VulnCheck advisory for further technical detail.

Detection Methods for CVE-2026-84808

Indicators of Compromise

Access logs showing GET /api/timesheets requests with activity filter parameters referencing activities outside the caller's team assignments.
API tokens or user sessions producing large-volume enumeration of the timesheet collection endpoint over short time windows.
User accounts with the view_other_timesheet permission suddenly querying timesheet data across multiple projects or customers they historically never accessed.

Detection Strategies

Compare API access patterns against user-to-team mappings and alert when a user retrieves timesheets tied to activities owned by teams they do not belong to.
Baseline normal timesheet API call volume per user and flag deviations consistent with data enumeration.
Inspect Kimai audit logs for authenticated read operations that would have been denied through the web UI path but succeeded through the REST API.

Monitoring Recommendations

Forward Kimai web server and application logs to a centralized log platform and retain API request metadata for at least 90 days.
Correlate REST API activity with identity and permission data to surface cross-team access anomalies.
Monitor for unpatched Kimai instances by tracking deployed versions against the fixed release 2.65.0.

How to Mitigate CVE-2026-84808

Immediate Actions Required

Upgrade all Kimai instances to version 2.65.0 or later, which restores activity-team enforcement in the REST API timesheet endpoint.
Audit user accounts that currently hold the view_other_timesheet permission and remove it from users who do not require cross-user visibility.
Rotate long-lived API tokens issued to accounts with view_other_timesheet to invalidate any credentials that may have been abused.

Patch Information

The vulnerability is fixed in Kimai 2.65.0. Refer to the GitHub Security Advisory GHSA-c6j4-35fc-x3hw for release notes and the associated commit. Administrators should follow the standard Kimai upgrade procedure and verify the running version after deployment.

Workarounds

Restrict access to the REST API at the network layer, permitting only trusted internal ranges until the upgrade is completed.
Temporarily revoke the view_other_timesheet permission from non-administrative roles to reduce exposure.
Disable or firewall the /api/timesheets endpoint if the REST API is not required for business workflows.

bash

# Verify installed Kimai version and confirm the fix
php bin/console kimai:version
# Expected output: 2.65.0 or later