https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-09-30T01:52:28.208305+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/fkie_cve-2026-52826 fkie_cve-2026-52826 2026-09-30T01:52:28.477592+00:00

Kimai is an open-source time tracking application. Prior to 2.57.0, GET or POST requests to /en/admin/project/{id}/rate/{rate}, /en/admin/customer/{id}/rate/{rate}, and /en/admin/activity/{id}/rate/{rate} independently resolve the authorized parent identifier and the attacker-selected child rate identifier without confirming that the ProjectRate, CustomerRate, or ActivityRate belongs to that parent. An authenticated user who can edit one parent object can pair it with a rate record from an unauthorized project, customer, or activity and persist changes to billing configuration in kimai2_projects_rates, kimai2_customers_rates, or kimai2_activities_rates. This issue is fixed in version 2.57.0.

 https://vulnerability.circl.lu/vuln/ghsa-2xgg-2x8h-8xw4 GHSA-2xgg-2x8h-8xw4 — Kimai: Improper Authorization in Project, Customer, and Activity Rate Edit Endpoints Allows Cross-Scope Rate Manipulati… 2026-09-30T01:52:28.477745+00:00

Affected: Packagist: kimai/kimai

### Summary

Kimai 2.56.0 contains an authenticated improper authorization vulnerability in the Web rate editing flows for projects, customers, and activities. A user who can edit one authorized parent object can combine that authorized parent ID with the rate ID of a different, unauthorized parent object and thereby modify the unauthorized rate record.

This affects `ProjectRate`, `CustomerRate`, and `ActivityRate` editing. The issue is caused by missing parent-child consistency validation and allows cross-project, cross-customer, or cross-activity tampering of billing-related configuration.

### Details

The issue affects the following Web routes:

- `GET/POST /en/admin/project/{id}/rate/{rate}` - `GET/POST /en/admin/customer/{id}/rate/{rate}` - `GET/POST /en/admin/activity/{id}/rate/{rate}`

In both cases, the parent object and the rate object are resolved independently from user-controlled route parameters. The controller only checks whether the current user may edit the parent object referenced by `{id}`, but it does not verify that the child rate object referenced by `{rate}` actually belongs to that same parent.

In these controllers, there is no validation such as:

- `$rate->getProject() === $project` - `$rate->getCustomer() === $customer` - `$rate->getActivity() === $activity`

This missing binding check is especially notable because the API delete endpoints already enforce the expected parent-child relationship.

This shows that parent-child consistency is already…