CVE-2026-52827: Kimai Time Tracking Auth Bypass Vulnerability

CVE-2026-52827 Overview

Kimai, an open-source time tracking application, contains an authentication bypass vulnerability affecting versions prior to 2.59.0. The KIMAI_SESSION cookie issued after password verification, but before Time-based One-Time Password (TOTP) completion, is accepted by every /api route. An attacker with valid account credentials can invoke authenticated REST API operations without providing the required second factor, even though web routes remain properly blocked. The flaw is classified under [CWE-287: Improper Authentication] and is fixed in Kimai 2.59.0.

Critical Impact
Attackers with a stolen or phished password can fully bypass two-factor authentication (2FA) against the Kimai REST API, gaining programmatic access to time tracking data, invoices, and user records.

Affected Products

Kimai time tracking application, all versions prior to 2.59.0
Deployments using Scheb TwoFactorBundle with TOTP enforcement
Instances exposing the /api route to authenticated users

Discovery Timeline

2026-09-15 - CVE-2026-52827 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-52827

Vulnerability Analysis

The vulnerability results from a mismatch between how the Symfony security firewall evaluates two-factor authentication (2FA) state on web routes versus API routes. Kimai enforces TOTP verification on the web firewall, blocking access until the second factor is completed. However, the API firewall applies the IS_AUTHENTICATED access rule, which is satisfied by any authenticated token, including the intermediate Scheb\TwoFactorToken issued between password verification and TOTP completion.

Because App\API\Authentication\ApiRequestMatcher routes requests carrying an existing session through the main firewall, the intermediate token is honored on API endpoints. The App\Voter\ApiVoter then grants API access to the underlying User object attached to the TwoFactorToken, completing the bypass.

Root Cause

The root cause is an insufficient authorization check in config/packages/security.yaml. The IS_AUTHENTICATED rule does not distinguish between fully authenticated principals and partially authenticated principals awaiting a second factor. ApiVoter compounds the issue by unwrapping the User from any token type without verifying that 2FA is complete.

Attack Vector

Exploitation requires network access to the /api endpoint and valid credentials for a Kimai account with 2FA enabled. An attacker submits the standard username and password login flow, obtains the KIMAI_SESSION cookie issued before TOTP completion, and replays that cookie against /api routes. Web routes correctly reject the session, but every API operation authorized for the target user succeeds.

javascript

// Patch snippet from assets/js/plugins/KimaiAjaxModalForm.js (Release 2.59, PR #5957)
                            if (hasFieldError || hasFormError || hasFlashError) {
                                this._openFormInModal(html);
                            } else {
-                               events.trigger(eventName);
+                               if (eventName !== undefined) {
+                                   events.trigger(eventName);
+                               }

                                this._isDirty = false;
                                this._getModal().hide();

Source: GitHub Commit 87c85270. The full security fix rewires the API firewall so that a Scheb\TwoFactorToken is rejected on /api routes; see the GitHub Security Advisory GHSA-v8hx-4vx8-wc96 for the complete server-side changes.

Detection Methods for CVE-2026-52827

Indicators of Compromise

Requests to /api/* endpoints carrying a KIMAI_SESSION cookie for a user account that never completed a TOTP challenge within the same session window.
API activity from a user immediately after a password submission but with no corresponding successful 2FA event in application logs.
Automated or scripted access patterns to /api endpoints originating from IP addresses that never load the web UI.

Detection Strategies

Correlate authentication logs to identify sessions that reached the API without a TOTP success event for the same session identifier.
Alert on any Kimai API request where the associated user has 2FA enforced but no verified second-factor timestamp exists in the session store.
Deploy web application firewall (WAF) rules to flag requests to /api that reuse cookies produced during the pre-TOTP authentication step.

Monitoring Recommendations

Enable verbose logging on the Symfony security firewall to record token class transitions between TwoFactorToken and fully authenticated tokens.
Forward Kimai application and web server logs to a centralized SIEM to baseline normal 2FA completion rates and detect deviations.
Track API rate and endpoint diversity per user account to identify credential-only attackers programmatically enumerating resources.

How to Mitigate CVE-2026-52827

Immediate Actions Required

Upgrade all Kimai instances to version 2.59.0 or later without delay.
Rotate API tokens and force session invalidation for all accounts, especially those with 2FA enforced.
Audit REST API access logs since 2FA was enabled to identify suspicious activity predating the patch.

Patch Information

The fix is included in Kimai Release 2.59.0. The corrective changes are tracked in GitHub Pull Request 5957 and applied in commit 87c85270a98899e6545108cbb9f41103ec6ea312. Vendor guidance is available in the Kimai Security Overview GHSA-v8hx-4vx8-wc96.

Workarounds

Restrict /api access at the reverse proxy or WAF layer to trusted networks or VPN clients until patching is complete.
Temporarily disable REST API functionality for user accounts that rely on 2FA by revoking API scopes in Kimai user settings.
Enforce IP allowlisting for administrative and privileged accounts to reduce the exposure surface of the API firewall.

bash

# Example nginx rule to block API access from untrusted networks until patched
location /api/ {
    allow 10.0.0.0/8;      # internal management network
    allow 192.168.10.0/24; # trusted VPN range
    deny all;
    proxy_pass http://kimai_backend;
}