Two-factor authentication (TOTP) can be fully bypassed for the REST API. The KIMAI_SESSION cookie returned in the response to the login request; issued after only the password is verified, before the TOTP step; is already accepted as authenticated by every /api/* endpoint. So after submitting just the password, the web UI correctly holds the browser at the TOTP screen (/en/auth/2fa), but the cookie from that same login response can be …
Kimai 2.56.0 contains authenticated cross-site request forgery issues in its timesheet state-changing API endpoints. The application reuses the browser's existing session for /api/* requests, and both the stop and restart operations are exposed through GET and PATCH routes that directly modify business state. As a result, an attacker can trick a logged-in user into visiting a malicious page and cause unauthorized timesheet actions without the victim's consent. Depending on the …
Kimai 2.56.0 contains an authenticated improper authorization vulnerability in the preset-project activity creation flow. A user with the generic create_activity permission, but without access to a target project, can still create a new Activity under that unauthorized project by visiting the preset project creation route directly. This is a persistent cross-project business-object creation issue. The attacker does not need permission to view or edit the target project and only needs …
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, …
The ExportController web routes for creating and editing export templates are gated only by the class-level create_export permission, which is granted to ROLE_TEAMLEAD by default. The corresponding API routes and UI button visibility correctly require the stricter create_export_template permission, which is granted only to ROLE_ADMIN and ROLE_SUPER_ADMIN. A TEAMLEAD user can directly access the template create/edit routes to create or modify global export templates that are visible to all users …
The official Kimai Docker image ships with APP_SECRET=change_this_to_something_unique as the default environment variable. The Docker entrypoint does not override or validate this value. Any Kimai instance deployed using the Docker image without explicitly setting APP_SECRET runs with a publicly-known Symfony kernel.secret, enabling an unauthenticated attacker to forge HMAC-signed cookies and login links to take over any account including super_admin.
Kimai contains an authenticated improper authorization vulnerability in Team-related assignment APIs. A Teamlead who can edit their own team can use backend API endpoints to add users or activities that fall outside their intended visible or manageable scope, even when the frontend correctly hides those targets. This affects both team member assignment and team activity assignment. The issue is caused by treating "may edit this team" as equivalent to "may …
Kimai 2.56.0 contains an authenticated authorization bypass in the timesheet restart and duplicate workflows. After a user loses access to a project, the user can still derive a new timesheet from one of their historical entries and create a new record under that now-unauthorized project and activity combination. This is a permission revocation bypass with persistent write impact. The issue affects both restart and duplicate, which trust ownership of an …
The Timesheet API PATCH /api/timesheets/{id} and POST /api/timesheets endpoints accept a user-supplied project ID and resolve it through a Symfony EntityType whose query_builder allows the submitted ID to satisfy the access predicate via an unconditional OR branch. As a result, any authenticated user can re-assign their own timesheet to any project in the database — including projects that belong to teams or customers they have no membership in and cannot …
GET /api/timesheets?user=<id> (and users[]=<id>) returns the targeted user's timesheet records to any caller that has the view_other_timesheet permission, without verifying that the caller is teamlead of any team containing the target user. The per-record endpoint GET /api/timesheets/{id} correctly enforces this check via TimesheetVoter/RolePermissionManager::checkTeamAccessTimesheet → checkTeamLeadAccess, but the list endpoint only filters projects/customers by team membership and never validates t.user. A ROLE_TEAMLEAD user can therefore enumerate any user's records — including …
Kimai 2.56.0 contains authenticated cross-site request forgery issues in its 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. As a result, an attacker can trick a logged-in user with the required permissions into visiting a malicious page and cause unauthorized changes …
Kimai 2.56.0 contains a server-side request forgery vulnerability in its invoice PDF preview and generation workflow. If an attacker can control Markdown content that is later rendered into an invoice PDF, such as Customer.invoiceText, the server-side PDF renderer will fetch remote image URLs embedded in Markdown image syntax. This allows the application server to issue outbound requests to attacker-controlled or internal targets during PDF rendering. The behavior can be used …
Kimai 2.56.0 contains an authenticated improper authorization / IDOR vulnerability in the favorite timesheet add and remove endpoints. A low-privileged user who knows another user's timesheet.id can add that record to, or remove it from, the victim's favorite/recent bookmark list. This allows cross-user manipulation of per-user favorite state without administrative privileges.
The LoginLink signature used for password reset URLs covers only the user's id — it does not include the password hash. After a user clicks a reset link and successfully changes their password, the same link remains valid for up to 2 additional uses within a 1-hour window. Anyone who intercepts or caches the original link can log in as the user even after the password has been changed.
Users with the role System-Admin (ROLE_SYSTE_ADMIN) and the permission upload_invoice_template can upload PDF invoice templates, which can call pdfContext.setOption('associated_files', …) inside the sandboxed Twig render. This is forwarded to mPDF's SetAssociatedFiles(), whose writer calls file_get_contents($entry['path']) during PDF output and embeds the bytes as a FlateDecode stream in the PDF. Any file readable by the PHP worker is returned to the attacker inside the rendered invoice.
Kimai's Twig sandbox (StrictPolicy, used for admin-uploaded invoice and export templates) allow-lists the config() Twig function with no key filtering. config(name) delegates to App\Configuration\SystemConfiguration::find($name), which returns arbitrary entries from the flattened kimai.config container parameter built in App\DependencyInjection\AppExtension::loadInternal(). Any admin who can upload a Twig template can therefore render server-wide secrets - the LDAP bind password, the SAML SP private key, and any other dotted configuration key populated from kimai.yaml - …
Any ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system — regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.
Any ROLE_USER can create a tag with a formula string as its name (e.g. =SUM(54+51)) via POST /api/tags and assign it to a timesheet. When an admin exports timesheets to XLSX, ArrayFormatter.formatValue() joins tag names with implode() and returns the result unchanged. OpenSpout promotes any =-prefixed string to a FormulaCell, writing <f>SUM(54+51)</f> into the XLSX archive. Excel evaluates the formula when the file is opened.
The Team API endpoints use #[IsGranted('edit_team')] instead of #[IsGranted('edit', 'team')], causing Symfony TeamVoter to abstain from voting. This removes entity-level ownership checks on team operations, allowing any user with the edit_team permission to modify any team, not just teams they are authorized to manage.
Details src/API/Authentication/TokenAuthenticator.php calls loadUserByIdentifier() first and only invokes the password hasher (argon2id) when a user is returned. When the username does not exist, the request returns roughly 25 ms faster than when it does. The response body is the same in both cases ({"message":"Invalid credentials"}, HTTP 403), so the leak is purely timing. The /api/* firewall has no login_throttling configured, so the probe is unbounded. The legacy X-AUTH-USER / X-AUTH-TOKEN …
A Mass Assignment / Broken Object Property Level Authorization (BOPA) vulnerability in the User Preferences API allows any authenticated user (even those with the lowest privileges) to arbitrarily modify restricted financial attributes on their profile, specifically their hourly_rate and internal_rate.
The client-side escapeForHtml() function in KimaiEscape.js, introduced in commit 89bfa82c (#2959) to fix a JavaScript XSS vulnerability, only escapes <, >, and & but does not escape " (double quote) or ' (single quote). When user-controlled data (profile alias) is placed in an HTML attribute context (title="DISPLAY") via the team member form prototype and rendered through innerHTML, the missing quote escaping allows HTML attribute injection, resulting in Stored XSS.
The Twig sandbox used for invoice templates blocks certain sensitive User methods (password, TOTP secret, etc.) via a blocklist in StrictPolicy::checkMethodAllowed(). However, getApiToken() and getPlainApiToken() are not on the blocklist. An admin who creates an invoice template can embed calls to these methods, causing the bcrypt or sodium hashed API password of any user who generates an invoice using that template to be included in the rendered output. Only relevant …
The SAML authentication success handler in Kimai returns the RelayState POST parameter as a redirect destination without validating the host or scheme. After a user successfully authenticates via SAML, they are redirected to an attacker-controlled URL if the IdP includes a malicious RelayState value. This enables phishing attacks that steal credentials or session tokens post-SSO. Requires SAML to be enabled (non-default configuration).
GET /api/invoices/{id} only checks the role-based view_invoice permission but does not verify the requesting user has access to the invoice's customer. Any user with ROLE_TEAMLEAD (which grants view_invoice) can read all invoices in the system, including those belonging to customers assigned to other teams.
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.
| Field | Value | |——-|——-| | Title | Authenticated SSTI via Permissive Export Template Sandbox || Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | High (Admin with export permissions and server access) | | User Interaction | None | | Impact | Confidentiality: HIGH (Credential/Secret Extraction) | | Affected Versions | Kimai 2.45.0 (likely earlier versions) | | Tested On | Docker: …