CVE-2026-52827 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.59.0, 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Kimai prior to version 2.59.0 represents a critical authentication bypass within its RESTful application programming interface, stemming from an incomplete implementation of multi-factor authentication controls for API endpoints. Kimai is an open-source time tracking solution that relies on Symfony's security component for access control. The core flaw lies in the configuration and logic governing how sessions are validated against specific route types. Specifically, the KIMAI_SESSION cookie issued immediately after successful password verification but before the completion of Time-based One-Time Password (TOTP) authentication was erroneously accepted by every API route. This behavior contradicts the intended security posture where two-factor authentication should be mandatory for all authenticated actions, including those performed via programmatic interfaces.
From a technical perspective, the issue originates in the interaction between the main firewall configuration and custom request matchers defined in config/packages/security.yaml. The API routes were protected using an IS_AUTHENTICATED access rule combined with App\API\Authentication\ApiRequestMatcher logic designed to route existing sessions through the primary authentication mechanism. However, this setup failed to distinguish between a fully authenticated session and one that is only partially authenticated via password alone. In Symfony's security model, Scheb TwoFactorToken represents a state where the user has passed the first factor but not yet completed the second. The App\Voter\ApiVoter component was configured to grant API access based on the presence of this token type without verifying whether the two-factor challenge had been successfully resolved. Consequently, any actor possessing valid credentials could bypass the TOTP requirement entirely when interacting with the REST API, while web-based routes remained correctly blocked until full authentication was achieved.
The operational impact of this vulnerability is significant because it allows for unauthorized programmatic access to sensitive time tracking data and administrative functions without requiring possession of the user's second factor device or authenticator application. An attacker who obtains a valid username and password through phishing, credential stuffing, or other means can immediately leverage these credentials against API endpoints to extract confidential information such as project details, billable hours, client records, and potentially modify time entries if write permissions are granted. This bypass undermines the security benefit of multi-factor authentication for any user whose account is targeted via automated tools rather than interactive web sessions. Since many enterprise deployments rely on APIs for integration with other business systems or mobile applications, this flaw could lead to data exfiltration or integrity compromise across connected services that trust Kimai's API responses as authoritative sources of truth regarding employee time and project status.
This vulnerability aligns with CWE-287 Improper Authentication because the system failed to adequately verify identity during authentication processes for specific entry points. It also maps to ATT&CK technique T1078 Valid Accounts, where adversaries leverage legitimate credentials to gain access, specifically exploiting the lack of enforcement for secondary factors in non-browser contexts. The failure represents a classic case of inconsistent security policy application across different client types within the same framework.
Mitigation requires upgrading Kimai to version 2.59.0 or later, which corrects the logic within ApiVoter and ensures that API routes strictly require full authentication completion including two-factor verification before granting access. For organizations unable to upgrade immediately due to dependency constraints, temporary mitigations include restricting direct external network exposure of API endpoints behind a Web Application Firewall capable of enforcing stricter session validation rules or implementing additional backend checks that verify the presence of completed second factor tokens in every request payload rather than relying solely on cookie-based session state. Additionally, auditing logs for unusual patterns of API access following password resets or new account creations can help detect potential exploitation attempts while patches are being deployed.