Description

Kimai versions from 2.61.0 before 2.63.0 fail to disable admin-only work-contract preferences for low-privilege users in the PATCH /api/users/{id}/preferences endpoint. Although the web interface gates these employment-contract fields behind the contract_other_profile admin permission, the WorkContractPreferenceSubscriber (introduced in 2.61.0) registers the preferences as enabled without a permission check, so an authenticated regular user can use the API to modify their own admin-only work-contract data. The issue is fixed in 2.63.0 by applying the same permission check to the API endpoint.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-02T12:17:17.457Z",
  "pubdate": "2026-09-02T12:17:17.457Z",
  "executiveSummary": "Kimai versions 2.61.0 through 2.62.x are affected by an authorization bypass vulnerability within the API layer. The flaw specifically concerns the 'PATCH /api/users/{id}/preferences' endpoint, which fails to enforce administrative permission checks for work-contract related preferences.\nThis vulnerability allows authenticated low-privilege users to modify their own employment-contract data, which is intended to be strictly restricted to users with the 'contract_other_profile' administrative permission. While the web interface correctly implements these gating mechanisms, the backend API subscriber registers these fields without validating the caller's authorization level.\nThe primary risk implication is the unauthorized manipulation of sensitive employment records within the application, leading to a violation of access control policies and potential integrity issues regarding user metadata. Successful exploitation requires an attacker to possess a valid, low-privilege authenticated session. No complex preconditions beyond standard authentication are required. The issue has been addressed in version 2.63.0 through the implementation of explicit permission verification within the affected API workflow.",
  "technicalDetails": "The root cause of this vulnerability lies in an inconsistent authorization implementation between the frontend interface and the backend API architecture. With the introduction of the 'WorkContractPreferenceSubscriber' in version 2.61.0, the system began handling work-contract preferences in a way that bypassed existing security controllers.\nThe 'PATCH /api/users/{id}/preferences' endpoint functions as an API entry point for updating user-specific configuration data. In a secure deployment, this endpoint should verify that the requester possesses the 'contract_other_profile' permission before committing changes to sensitive fields related to employment contracts. However, the 'WorkContractPreferenceSubscriber' registers these preferences as globally enabled for the endpoint without invoking the required permission-check logic.\nThe attack flow proceeds as follows: 1. An authenticated low-privilege user initiates a PATCH request to the '/api/users/{id}/preferences' endpoint. 2. The user includes a JSON payload containing the sensitive work-contract fields that are technically gated in the web interface. 3. The API, processing the request through the vulnerable 'WorkContractPreferenceSubscriber', fails to query the user's role or permission set against the 'contract_other_profile' requirement. 4. The backend service validates the request structure and commits the modified preference values to the database.\nBecause the 'WorkContractPreferenceSubscriber' omits this check, the application implicitly trusts the user-supplied data for fields that were intended to be read-only or immutable for non-admin users. This creates a functional bypass where the server performs the requested mutation because the API subscriber logic explicitly overrides or ignores the permission gating applied to the UI component. The impact of this vulnerability is the ability for non-administrative users to overwrite their own work-contract configuration, which may lead to business logic errors, payroll synchronization issues, or unauthorized data modifications in systems that rely on these specific Kimai profile settings. The exploit is entirely performed over standard HTTP/HTTPS protocols and requires no administrative privileges to execute successfully."
}