Kimai's User Preferences API allows standard users to modify restricted attributes: hourly_rate, internal_rate

The core impact of CVE-2026-40486 lies in the potential for unauthorized modification of financial data. An attacker, having successfully authenticated to the Kimai system, can leverage this BOPA vulnerability to alter their own hourly and internal rates. This could lead to inflated billing amounts, inaccurate project costing, and ultimately, financial losses for the organization. While the vulnerability requires authentication, the ease of exploitation – requiring only a valid user account – significantly broadens the attack surface. The blast radius is limited to the affected user's profile and associated billing records, but widespread exploitation could impact multiple users and projects.

Organizations utilizing Kimai for time tracking, particularly those with a large number of users or complex billing structures, are at risk. Specifically, deployments with relaxed role-based access controls or shared hosting environments where user privileges are not carefully managed are more vulnerable.

• php: Examine Kimai application logs for unusual API requests targeting the user profile modification endpoints (e.g., /api/user/preferences). • generic web: Monitor access logs for POST requests to /api/user/preferences originating from authenticated users with limited privileges. • generic web: Check Kimai configuration files for any misconfigured access controls related to user profile modification.

1. 2026-04-17Disclosure

   disclosure

1. 已保留2026-04-13
2. 发布日期2026-04-17
3. 修改日期2026-04-20
4. EPSS 更新日期2026-04-25

The primary mitigation for CVE-2026-40486 is to upgrade Kimai to version 2.5.4 or later, which includes the necessary fix. If an immediate upgrade is not feasible, consider implementing stricter role-based access controls within Kimai to limit the number of users with the ability to modify financial attributes. Additionally, carefully review user profiles for any unusual rate changes. While a WAF or proxy cannot directly prevent this BOPA, it could be configured to monitor for suspicious API requests targeting the user profile modification endpoints. After upgrading, confirm the fix by attempting to modify the hourlyrate and internalrate fields with a user account lacking the hourly-rate role permission; these modifications should be denied.