CVE-2026-52825: 
PHP Schwachstellenanalyse und -minderung

CVE-2026-52825 is an authenticated improper authorization vulnerability in Kimai, an open-source time-tracking application, affecting the Team Member and Team Activity Assignment APIs. A Teamlead who has permission to edit their own team can directly call backend API endpoints to add users or activities that fall outside their authorized management scope, bypassing frontend restrictions. The vulnerability affects Kimai versions up to and including 2.57.0, with version 2.58.0 containing the fix. It was originally published on June 11, 2026, and added to the GitHub Advisory Database on July 14, 2026. The CVSS v4 base score is 5.3 (Medium) (GitHub Advisory, Kimai Advisory).

The root cause is classified as CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The backend TeamController.php uses #[IsGranted('edit', 'team')] to verify only that the caller may edit the target team, but performs no secondary authorization check to confirm whether the referenced User or Activity object falls within the Teamlead's permitted management scope. The vulnerable API routes are POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId}. While the frontend form (TeamEditForm.php) correctly restricts visible user choices via UserRepository::getQueryBuilderForFormType(), this restriction is not enforced server-side in the API layer. The activity assignment case is particularly risky because RolePermissionManager::checkTeamAccessActivity() trusts existing team/activity relations, meaning a fraudulently written relation can influence subsequent access-control decisions (GitHub Advisory).

Successful exploitation allows a Teamlead to use their own editable team as an expansion container to attach users and activities that should remain outside their authorized scope. This breaks the integrity of Kimai's team-based security isolation model, potentially affecting user scoping, customer/project/activity visibility, time-entry behavior, statistics, and reporting. Once unauthorized relations are written to the database, downstream authorization logic may treat them as legitimate, compounding the access control bypass. There is no direct confidentiality or availability impact at the system level, but the integrity of access control boundaries is undermined (Kimai Advisory).

1. Authenticate as Teamlead: Log in to the Kimai instance with a Teamlead account that has permission to edit at least one team.
2. Enumerate target IDs: Use the Kimai API (e.g., GET /api/users or GET /api/activities) to enumerate user IDs or activity IDs that are outside the Teamlead's normal visible scope. These may be accessible via the API even if not shown in the frontend.
3. Craft malicious POST request: Directly call the vulnerable API endpoint with a target ID outside the authorized scope, bypassing the frontend restriction:
   • To add an unauthorized user: POST /api/teams/{teamId}/members/{targetUserId}
   • To add an unauthorized activity: POST /api/teams/{teamId}/activities/{targetActivityId}
4. Confirm unauthorized relation is written: Verify the response indicates success (no authorization error), confirming the user or activity has been added to the team.
5. Leverage expanded access: With the unauthorized relation now persisted, downstream authorization checks (e.g., checkTeamAccessActivity()) may grant the Teamlead or their team members access to the newly attached resources, including visibility into projects, customers, time entries, and reports (GitHub Advisory, Kimai Advisory).

• Network/API Logs: Unexpected POST requests to /api/teams/{id}/members/{userId} or /api/teams/{id}/activities/{activityId} originating from Teamlead accounts, particularly where the referenced userId or activityId does not belong to the Teamlead's normal visible scope.
• Application Logs: Successful API responses (HTTP 200/201) for team member or activity assignment calls where the assigned entity is outside the Teamlead's authorized management range.
• Database: Unexpected entries in team-user or team-activity association tables linking teams to users or activities that were not previously in scope for that Teamlead's teams.
• Behavioral: Teamlead accounts suddenly gaining visibility into projects, customers, or activities they were not previously authorized to view, or unexpected changes in time-entry or reporting data scope.

Upgrade Kimai to version 2.58.0 or later, which adds the following permission checks in src/API/TeamController.php: #[IsGranted('access_user', 'member')] before adding a team member, and #[IsGranted('view', 'activity')] before granting a team access to an activity (along with equivalent checks for customers and projects). No configuration-based workaround is available for unpatched versions; the only effective remediation is upgrading. Organizations unable to upgrade immediately should consider restricting Teamlead API access at the network or application firewall level (GitHub Advisory, Kimai Advisory).

The vulnerability was reported by security researcher Mitchell45 and patched by Kimai maintainer kevinpapst. The advisory was published on June 11, 2026, and added to the GitHub Advisory Database on July 14, 2026. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (GitHub Advisory).