CVE-2026-52827: 
PHP Schwachstellenanalyse und -minderung

CVE-2026-52827 is a two-factor authentication (TOTP) bypass vulnerability in Kimai, an open-source time-tracking application, affecting all versions prior to 2.59.0. The flaw allows an attacker who knows a user's password to gain full authenticated access to the Kimai REST API without completing the TOTP second factor. It was first published by the maintainer on June 29, 2026, and added to the GitHub Advisory Database on July 14, 2026. The CVSS v4 base score is 7.1 (High) per the GitHub Advisory Database, though the original vendor advisory rates it 6.0 (Moderate) with a higher Attack Complexity (GitHub Advisory, Kimai Advisory).

The root cause is improper authentication (CWE-287) in Kimai's API firewall configuration. When a user logs in, the KIMAI_SESSION cookie is issued immediately after password verification — before the TOTP step is completed. The API firewall in config/packages/security.yaml uses the IS_AUTHENTICATED role check for ^/api paths, and the Scheb TwoFactorToken held in the session during the 2FA flow satisfies this check because it is a non-anonymous token. Additionally, App\API\Authentication\ApiRequestMatcher returns !$request->hasPreviousSession(), causing requests carrying the login session cookie to bypass the stateless API firewall and be handled by the main session firewall, where TwoFactorAccessDecider::isAccessible() incorrectly grants access. Web UI routes are unaffected because they require concrete roles such as ROLE_USER that a TwoFactorToken does not hold (GitHub Advisory, Kimai Advisory).

Successful exploitation renders 2FA completely ineffective for the Kimai REST API, meaning any attacker who obtains a user's password — through phishing, credential stuffing, password reuse, or a data breach — gains full authenticated API access as that user. No API token, Bearer header, or CSRF token is required; the single pre-2FA session cookie is sufficient. The primary impact is high confidentiality loss (access to all data accessible via the API) and low integrity impact (ability to make unauthorized modifications via API calls), with no availability impact (GitHub Advisory, Kimai Advisory).

1. Obtain credentials: Acquire a valid Kimai user account password through phishing, credential stuffing, password reuse, or a prior data breach — targeting accounts known to have 2FA enabled.
2. Submit login request: Send a POST request to the Kimai login endpoint (e.g., /en/login) with the username and password. The server responds with a Set-Cookie: KIMAI_SESSION=<value> header and redirects the browser to /en/auth/2fa for the TOTP step.
3. Extract the session cookie: Capture the KIMAI_SESSION cookie value from the login response before completing the TOTP challenge. The web UI will be stuck at the 2FA screen, but the cookie is already issued.
4. Replay cookie against the API: Use the captured cookie in a direct HTTP request to any /api/* endpoint (e.g., GET /api/timesheets or GET /api/users/me), including it as a Cookie: KIMAI_SESSION=<value> header. No Bearer token or CSRF token is needed.
5. Achieve full API access: The API firewall accepts the TwoFactorToken as satisfying IS_AUTHENTICATED, granting full authenticated access to all REST API endpoints as the target user, enabling data exfiltration, time entry manipulation, or user enumeration (GitHub Advisory, Kimai Advisory).

• Network: API requests to /api/* endpoints originating from IPs or user agents inconsistent with the account's normal usage patterns, particularly shortly after a login event that did not complete the 2FA flow.
• Logs: Kimai access logs showing a login request to /en/login followed immediately by API requests to /api/* from the same session, with no corresponding request to /en/auth/2fa or TOTP verification endpoint.
• Logs: Successful API responses (HTTP 200) to /api/* endpoints using a session cookie that was issued during an incomplete 2FA authentication flow.
• Behavioral: API activity (e.g., time entry reads/writes, user data access) occurring at times or from locations inconsistent with the legitimate account holder's normal behavior (GitHub Advisory).

Upgrade Kimai to version 2.59.0 or later, which resolves the issue by changing the /api/ firewall to use IS_AUTHENTICATED_REMEMBERED (assigned only after 2FA completion) instead of IS_AUTHENTICATED. The fix also adds checks in ApiVoter for $token instanceof TwoFactorTokenInterface and isGranted('IS_AUTHENTICATED_2FA_IN_PROGRESS', $user) to explicitly block mid-2FA sessions from API access, along with regression tests. No configuration-based workaround is documented; upgrading to 2.59.0 is the only recommended remediation (GitHub Advisory, Kimai Advisory).

The vulnerability was reported by security researcher shafiqaimanx and responsibly disclosed to the Kimai maintainer (kevinpapst), who published the advisory on June 29, 2026. The maintainer acknowledged the issue and released a patch in version 2.59.0. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified at this time (Kimai Advisory).