CVE-2026-52827

Kimai, a self-hosted open-source time-tracking application, accepted the KIMAI_SESSION cookie issued after password verification but before TOTP completion on every /api route, because the API firewall only required IS_AUTHENTICATED and a Scheb TwoFactorToken satisfies that rule while ApiVoter grants API access to the underlying user. An attacker who possesses a valid account password can therefore perform authenticated REST API operations without ever supplying the second factor, even though web routes remain correctly blocked pending TOTP. The result is a partial 2FA bypass that exposes timesheet data and other API-reachable actions to anyone who already knows or has stolen a password (CVSS 4.0: 7.1, high). All installations running versions prior to 2.59.0 with TOTP/2FA enabled are affected; the issue is fixed in 2.59.0. No public proof of concept is known and there is no evidence of in-the-wild exploitation, and the flaw is not in the CISA KEV catalog.

What to do: Upgrade to Kimai 2.59.0 or later as soon as possible, since it is the only fixed version. Until then, treat a user's password alone as sufficient for API access: enforce strong passwords (or SSO), rotate credentials for accounts suspected of compromise, and review API access logs for activity from sessions that never completed TOTP. Additionally, restrict or firewall exposure of the /api endpoints where full API access is not needed.