CVE-2026-41498: 
PHP vulnerability analysis and mitigation

CVE-2026-41498 is a Missing Object-Level Authorization vulnerability in Kimai, an open-source time tracking application, affecting all versions prior to 2.54.0. The flaw exists in the Team API endpoints, which use the incorrect Symfony authorization annotation #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing the TeamVoter to abstain from voting and bypassing entity-level ownership checks. It was published on April 21, 2026, by maintainer kevinpapst, with the GitHub Advisory Database entry updated on May 12, 2026. The vulnerability carries a CVSS v3.1 base score of 3.3 (Low) (Github Advisory, Kimai Advisory).

The root cause is CWE-862 (Missing Authorization): all 8 team association endpoints in src/API/TeamController.php (lines 177, 201, 229, 252, 275, 298, 321, 339) use #[IsGranted('edit_team')] with a single argument, whereas the web controller at src/Controller/TeamController.php:118 correctly uses #[IsGranted('edit', 'team')] with two arguments, passing the $team entity as the subject. When edit_team is passed as the attribute, TeamVoter::supportsAttribute() returns false because it only recognizes view, edit, and delete — causing the voter to abstain entirely. Only RolePermissionVoter fires, which validates the role-level permission without any entity-level ownership check. A proof-of-concept demonstrating the bypass via a simple curl POST request is publicly available in the security advisory (Kimai Advisory).

An authenticated user with the edit_team permission can modify any team in the Kimai instance — including teams they do not own or belong to — by manipulating team membership, customer assignments, project assignments, and activity assignments. In the default configuration, only ROLE_ADMIN and ROLE_SUPER_ADMIN hold edit_team, and those roles already have broad view_all_data access, limiting practical impact. However, if an administrator grants edit_team to a lower-privilege role such as ROLE_TEAMLEAD, the vulnerability becomes exploitable by those users to tamper with arbitrary team data, resulting in low confidentiality and low integrity impact with no availability impact (Kimai Advisory, Github Advisory).

A proof-of-concept exploit is publicly available in the GitHub security advisory, demonstrated via a curl command targeting the Team API endpoint. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires the attacker to already be authenticated and possess the edit_team permission, which is a high-privilege prerequisite in default configurations. The EPSS score is approximately 0.013% (2nd percentile), indicating a very low probability of exploitation in the near term (Github Advisory, Kimai Advisory).

1. Reconnaissance: Identify a Kimai instance running a version prior to 2.54.0 and obtain credentials for an account that has been granted the edit_team permission (e.g., a ROLE_TEAMLEAD user in a non-default configuration).
2. Authenticate: Obtain a valid API bearer token by authenticating to the Kimai API with the lower-privilege account credentials.
3. Identify target team: Enumerate available teams via the Kimai API (e.g., GET /api/teams) to identify a team the attacker does not belong to or manage.
4. Send unauthorized modification request: Issue a POST request to a team association endpoint, such as adding a member to an arbitrary team:

   curl -X POST https://TARGET/api/teams/1/members/2 \
     -H "Authorization: Bearer <TOKEN>" \
     -H "Content-Type: application/json"

5. Achieve unauthorized modification: Due to the missing entity-level authorization check, the server responds with 200 OK and applies the change, allowing the attacker to modify team membership, customer assignments, project assignments, or activity assignments for any team (Kimai Advisory).

• Network: Unexpected API requests (POST/DELETE) to /api/teams/{id}/members/{userId}, /api/teams/{id}/customers/{customerId}, /api/teams/{id}/projects/{projectId}, or /api/teams/{id}/activities/{activityId} from users who are not members or teamleads of the targeted team.
• Logs: Kimai application logs showing successful 200 OK responses to Team API modification endpoints for users without team membership or admin roles; audit logs reflecting team membership or assignment changes not initiated by team owners or admins.
• Behavioral: Unexpected changes to team membership, customer/project/activity assignments in the Kimai database that do not correspond to actions by authorized team managers or administrators.

The vulnerability is patched in Kimai version 2.54.0, which corrects the authorization annotation to #[IsGranted('edit', 'team')] across all 8 affected Team API endpoints. Administrators should upgrade to version 2.54.0 or later immediately. As an interim workaround, restrict the edit_team permission exclusively to ROLE_ADMIN and ROLE_SUPER_ADMIN roles (the default configuration) and avoid granting it to lower-privilege roles such as ROLE_TEAMLEAD. Additionally, audit Team API access logs to identify any unauthorized team modifications that may have occurred (Kimai Advisory, Kimai Release).

The vulnerability was reported by security researcher AzureADTrent and disclosed responsibly through GitHub's security advisory process by Kimai maintainer kevinpapst. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified.