Kimai's User Preferences API allows standard users to modify restricted attributes: hourly_rate, internal_rate
Date: 2026-04
Affected: composer/kimai/kimai
Attack vector: auth-bypass
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2026-40479
CVE-2026-40486
CWE: CWE-79
CWE-915
CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)

### Summary A Mass Assignment / Broken Object Property Level Authorization (BOPA) vulnerability in the User Preferences API allows any authenticated user (even those with the lowest privileges) to arbitrarily modify restricted financial attributes on their profile, specifically their `hourly_rate` and `internal_rate`. ### Details Kimai restrictively protects the `hourly_rate` and `internal_rate` parameters during standard GUI flow. Users lacking the `hourly-rate` role permissions cannot see or edit these fields via the standard Web Form (`UserApiEditForm` / `UserEditType`). The vulnerability exists in the dedicated preferences API endpoint: `src/API/UserController.php::updateUserPreference`. When a `PATCH` request is sent to `/api/users/{id}/preferences`, the endpoint iterates through the submitted JSON array and blindly applies the new values: ```php foreach ($request->request->all() as $preference) { // ... validation omitted ... if (null === ($meta = $profile->getPreference($name))) { throw $this->createNotFoundException(\sprintf('Unknown custom-field "%s" requested', $name)); } $meta->setValue($value); // <-- VULNERABILITY } ``` The underlying Role-Based Access Control logic (`UserPreferenceSubscriber::getDefaultPreferences`) accurately identifies that standard users lack the `hourly-rate` role, and flags the dynamically generated preference object as disabled (`$preference->setEnabled(false)`). However, the `updateUserPreference` API endpo


Mitigations:

Architectural layers (MAESTRO):