Kimai vulnerabilities

Kimai versions before 2.65.0 contain an authorization bypass vulnerability in the REST API timesheet collection endpoint that fails to enforce activity-team access controls. Users with view_other_timesheet permission can list timesheets using activities restricted to teams they do not belong to, bypassing intended data isolation.

Kimai through 2.65.0 contains a business logic / improper authorization vulnerability in the default team creation endpoints. An authenticated user with project permission-management privileges can create or use a customer, project, or activity whose name matches an existing team; because the endpoints POST /api/customers/{id}/team, POST /api/projects/{id}/team, and POST /api/activities/{id}/team reuse an existing team of the same name and add the current user as teamlead without verifying that the user is authorized to manage that team, the attacker gains unauthorized team-lead (administration) rights over the existing team. Fixed in 2.65.0.

Kimai before 2.63.0 contains an improper authorization vulnerability in team access endpoints that allows authenticated users with team edit permissions and read-only access to grant team access to customers, projects, or activities. Attackers can exploit insufficient permission checks by sending POST requests to team access endpoints to modify access control lists for entities they should not be able to modify.

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.

In Kimai prior to 2.58.0, the official Docker image sets APP_SECRET to the public value change_this_to_something_unique in Dockerfile, and .docker/entrypoint.sh neither replaces nor rejects that value before Symfony uses it as kernel.secret. An unauthenticated attacker who reaches a deployment that did not override APP_SECRET, knows a username, correctly guesses the account ID associated with that username, and targets an account without active two-factor authentication can forge HMAC-protected authentication artifacts, including KIMAI_REMEMBER cookies and login links, to access the account without its password. The updated entrypoint generates and persists a random secret when no safe operator-provided value exists.

Kimai is an open-source time tracking application. Prior to 2.58.0, ExportController::createExportTemplate() and ExportController::editExportTemplate() inherit only the class-level create_export permission, which ROLE_TEAMLEAD receives by default, and omit the create_export_template permission required by the API routes and user interface. A teamlead can directly access the export template creation and editing web routes to create or modify global ExportTemplate records marked available to all users, altering export columns, renderer, format, and output used by other users and administrators. This issue is fixed in version 2.58.0.

In Kimai, the KIMAI_SESSION cookie issued after password verification but before TOTP completion is accepted by every /api route because config/packages/security.yaml protects the API with IS_AUTHENTICATED and App\API\Authentication\ApiRequestMatcher routes an existing session through the main firewall. A Scheb TwoFactorToken satisfies that access rule, and App\Voter\ApiVoter grants API access to its User, allowing an attacker with a valid account password to use authenticated REST API operations without entering the second factor even though web routes remain blocked. This issue is fixed in version 2.59.0.

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.

Kimai is an open-source time tracking application. Prior to 2.58.0, POST /api/teams/{id}/members/{userId} and POST /api/teams/{id}/activities/{activityId} verify that a teamlead may edit the Team but do not verify access_user for the referenced User or view access for the referenced Activity. A teamlead can add users or activities outside the teamlead's manageable scope to an editable team, bypassing the narrower choices enforced by TeamEditForm and UserRepository::getQueryBuilderForFormType(). The resulting relationships can be trusted by RolePermissionManager::checkTeamAccessActivity() and other team-based authorization, visibility, reporting, and workflow logic. This issue is fixed in version 2.58.0.

Kimai is an open-source time tracking application. Prior to 2.58.0, TimesheetController exposes GET /api/timesheets/{id}/stop and GET /api/timesheets/{id}/restart, which reuse an authenticated browser session and perform state-changing operations through GET requests without a request-forgery defense. A remote attacker can cause a logged-in user to request either route from attacker-controlled content, stopping a running timesheet or restarting a historical entry to create and start a new timesheet without the user's consent. The unauthorized changes can corrupt time records, billing, reports, approvals, and audits. This issue is fixed in version 2.58.0.

Kimai is an open-source time tracking application. Prior to 2.58.0, PATCH /api/timesheets/{id}/restart, PATCH /api/timesheets/{id}/duplicate, and the web duplicate workflow can derive a new record from an owned historical timesheet after the user's access to its project or activity has been revoked. TimesheetVoter evaluates the own-timesheet permission before current team access, and its canStart() logic validates object visibility but does not verify the user's current team access to the referenced project and activity. An old entry therefore acts as a persistent capability to create new time records under an unauthorized project and activity, corrupting budgets, statistics, reports, and invoices after an administrative revocation. This issue is fixed in version 2.58.0.

Prior to version 2.57.0 of Kimai, GET or POST requests to /en/admin/activity/create/{project} and /en/admin/project/create/{customer} required only the generic create_activity or create_project capability and did not verify edit access to the supplied Project or Customer object. A user knowing a valid project.id or customer identifier could create a new child business object under an unauthorized parent, polluting project or customer configuration and influencing later time-entry, rate, reporting, and billing behavior.

Prior to version 2.57.0 of Kimai, the PATCH /api/timesheets/{id} and POST /api/timesheets endpoints accepted a user-controlled project identifier that bypassed team access criteria. Any authenticated user with edit_own_timesheet could assign an owned timesheet to a project outside the user's teams, persist unauthorized project attribution, and retrieve project and customer metadata through GET /api/timesheets/{id}?full=true.

Prior to version 2.57.0 of Kimai, the GET /api/timesheets list endpoint accepted user identifiers from a caller with view_other_timesheet but did not verify that a ROLE_TEAMLEAD requester leads a team containing each target user. This allowed a teamlead to retrieve another user's descriptions, timing data, tags, rate, and internalRate even though GET /api/timesheets/{id} would deny access.

Kimai versions prior to 2.58.0 contain authenticated cross-site request forgery issues in their default team creation shortcuts for projects, customers, and activities. These endpoints are exposed through GET routes and directly create or reuse a Team, add the current user as teamlead, and bind the target object to that team.

Kimai versions prior to 2.58.0 contain a server-side request forgery vulnerability in the invoice PDF preview and generation workflow. If an attacker controls Markdown content rendered into an invoice PDF, such as Customer.invoiceText, the server-side PDF renderer fetches remote image URLs embedded in Markdown, allowing outbound requests to attacker-controlled or internal targets.

Kimai before version 2.65.0 fails to properly validate permissions when removing team access to activities, projects, and customers via API endpoints. Authenticated users with edit_team permission can revoke team access without the required permissions_activity check, bypassing authorization controls.

Kimai before 2.56.0 does not enforce team-membership checks in TimesheetVoter::voteOnAttribute(), allowing any authenticated user with ROLE_TEAMLEAD (or a role holding edit_other_timesheet/delete_other_timesheet) to read, modify, and permanently delete timesheets belonging to any user system-wide via the API, regardless of team membership.

Kimai before 2.53.0 fails to block sensitive User methods in the Twig invoice template sandbox, allowing admins to call getApiToken() and getPlainApiToken() methods. Attackers with template creation permissions can embed these method calls in invoice templates to leak hashed API tokens in rendered invoice output.

Kimai before 2.53.0 contains an open redirect vulnerability in the SAML authentication success handler that accepts unvalidated RelayState POST parameters as redirect destinations. Attackers with IdP access can supply malicious RelayState values to redirect authenticated users to attacker-controlled URLs for credential theft or phishing attacks.

Kimai before 2.54.0 has a timing oracle vulnerability in TokenAuthenticator that allows unauthenticated attackers to enumerate valid usernames via the X-AUTH-USER header. Response time differences reveal account existence.

Kimai versions before 2.56.0 fail to restrict the config() Twig function in sandboxed invoice and export templates, allowing administrators to access arbitrary configuration keys. Attackers with admin privileges can upload malicious templates to exfiltrate server-wide secrets including LDAP bind passwords and SAML private keys into invoice or export documents accessible to lower-privileged users.

Kimai before version 2.57.0 contains an improper authorization vulnerability in the favorite timesheet add and remove endpoints that allows authenticated users to manipulate other users' bookmarks. Attackers can add or remove timesheet entries from another user's favorite list by referencing their timesheet identifier, enabling cross-user business-state tampering without administrative privileges.

Kimai before 2.58.0 contains an authentication bypass vulnerability where password reset links remain valid after password changes because the LoginLink signature covers only the user id, not the password hash. Attackers who intercept or cache a password reset link can use it up to 2 additional times within a 1-hour window to log in as the user even after the legitimate user has changed their password.

A vulnerability in Kimai before version 2.63.0 in the team update API endpoint (PATCH /api/teams/{id}) removes all existing team members before validating the submitted replacement member list. An authenticated teamlead (or other user) with permission to edit a team can submit a malformed members payload; although Kimai returns a validation error, the existing membership rows have already been deleted. This bypasses the dedicated member-removal endpoint's protection against removing teamleaders and can leave a team with no members or teamleaders, disrupting team-based access control.

A vulnerability in Kimai before version 2.64.0 in the ProjectViewController export route (report_project_view_export) is due to missing authorization. The authorization guards are attached to the sibling __invoke method rather than at the class level, so the export route inherits no authorization checks. Any authenticated user, including a plain ROLE_USER without the project_reporting permission, can download the project overview export - which returns the same dataset as the protected report - disclosing customer names, project names, currency, budget type, and aggregate totals across all customers. Actual financial figures remain protected in the export template.

Kimai before 2.62.0 fails to validate create_other_timesheet permission in the QuickEntry controller when creating new timesheets. Authenticated users with view_other_timesheet and edit_other_timesheet permissions can create timesheet records for team members, bypassing authorization checks.

Kimai 2 contains a persistent cross-site scripting vulnerability that allows attackers to inject malicious scripts into timesheet descriptions. Attackers can insert SVG-based XSS payloads in the description field to execute arbitrary JavaScript when the page is loaded and viewed by other users.