Kimai CVE-2026-52826
MEDIUMSeverity by source
Network-reachable Web endpoint requires low-privilege authentication; integrity impact is high due to persistent financial data corruption, with no confidentiality or availability impact.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
2DescriptionCVE.org
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 a recognized invariant in the application design, but the Web edit endpoints fail to enforce it for projects, customers, and activities.
*A PoC was provided, but removed for security reasons.*
Impact
This vulnerability allows authenticated users to tamper with billing-related rate configuration outside their authorized project, customer, or activity scope. An attacker can modify rate values belonging to other teams or business domains, which can affect time-based settlement, inherited pricing, cost calculations, budget reporting, revenue reporting, and downstream invoice generation.
Because the issue directly persists changes into kimai2_projects_rates, kimai2_customers_rates, and kimai2_activities_rates, it is a real cross-scope integrity vulnerability rather than a UI-only flaw. The attack breaks team-based isolation boundaries for high-value financial configuration.
Solution
The rate edit forms for customers, projects and activities now verify that the rate belongs to the parent referenced in the URL and reject the request otherwise.
See https://www.kimai.org/en/security/ghsa-2xgg-2x8h-8xw4 for more information.
AnalysisAI
Cross-scope billing rate manipulation in Kimai 2.56.0 allows authenticated users with edit access to any single project, customer, or activity to tamper with rate configurations belonging to entirely different organizational units they are not authorized to access. The root cause is missing parent-child consistency validation in three Web admin rate-editing endpoints, where the controller validates the authenticated user's access to the parent object but never verifies that the child rate record actually belongs to that same parent. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The attacker must be an authenticated Kimai user (PR:L) holding edit permission on at least one project, customer, or activity - this is a standard non-administrative role in multi-user Kimai deployments. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | No CVSS score was assigned by the vendor or NVD, so risk metrics are independently assessed. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | An authenticated Kimai user with legitimate edit access to Project A identifies the sequential integer rate IDs assigned to Project B (a project they are not authorized to manage) by enumerating the `{rate}` parameter. The attacker submits a POST request to `/en/admin/project/{id_of_project_A}/rate/{rate_id_of_project_B}` with attacker-supplied rate values; the controller validates access to Project A and proceeds to persist the modified rate record into `kimai2_projects_rates` for Project B, silently overwriting billing configuration outside the attacker's authorized scope. |
| Remediation | Upgrade to Kimai 2.57.0, which introduces parent-child consistency validation in the rate edit forms for customers, projects, and activities, rejecting any request where the rate record does not belong to the parent object referenced in the URL path. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-2xgg-2x8h-8xw4