Kimai has Missing Object-Level Authorization in the Team API

Summary

The Team API endpoints use #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing Symfony TeamVoter to abstain from voting. This removes entity-level ownership checks on team operations, allowing any user with the edit_team permission to modify any team, not just teams they are authorized to manage.

Details

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. The web controller at src/Controller/TeamController.php:118 correctly uses #[IsGranted('edit', 'team')] with two arguments, passing the $team parameter as the subject. When edit_team is passed as the attribute, TeamVoter::supportsAttribute() returns false because it only recognizes view, edit, and delete. The voter abstains entirely. Only RolePermissionVoter fires, which checks the role-level permission without any entity-level ownership validation.

PoC

Authenticate as a user with edit_team permission who is NOT a member of Team 1

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

Expected: 403 Forbidden (user is not ROLE_ADMIN/ROLE_SUPER_ADMIN, or member of Team 1)

Actual (pre-2.54.0): 200 OK, user added to Team 1

Impact

In default configuration, only ROLE_ADMIN and ROLE_SUPER_ADMIN have edit_team, and both roles already have irrevocable view_all_data access, making the missing check redundant. The vulnerability becomes exploitable if an administrator grants edit_team to a lower-privilege role (such as ROLE_TEAMLEAD) through the permissions UI. In that scenario, the lower-privilege user could modify any team's membership, customer assignments, project assignments, and activity assignments without being a member or teamlead of that team.