CVE-2026-52827

Executive Summary

CVE-2026-52827 is an authentication-bypass vulnerability in Kimai, an open-source time-tracking application. Prior to version 2.59.0, a partially authenticated session cookie (KIMAI_SESSION) — issued after password verification but before TOTP (second-factor) completion — is incorrectly accepted by every /api route, because the security configuration grants API access under the IS_AUTHENTICATED rule and an existing session is routed through the main firewall by App\API\Authentication\ApiRequestMatcher. The impact is that any attacker who knows a valid account password (but not the TOTP secret) can perform fully authenticated REST API operations while web routes remain blocked by the second-factor gate. The flaw is a multi-factor authentication enforcement failure (CWE-287) that undermines the entire purpose of MFA on the API surface.

Technical Analysis

Kimai enforces two-factor authentication through the Symfony security component combined with the scheb/2fa bundle. The authentication flow issues a session cookie to the client as soon as username and password are validated, and only afterwards prompts the user to complete TOTP verification. In a correctly configured application, that intermediate session must not be treated as fully authenticated. CVE-2026-52827 demonstrates that Kimai's authorization boundary for the API was misconfigured.

Three configuration/component elements interact to produce the bypass, as described in the NVD record:

1. config/packages/security.yaml protects the API with the IS_AUTHENTICATED access rule. This rule is satisfied by any authenticated token, including intermediate/partial tokens — it does not require full MFA completion (e.g., it does not require IS_AUTHENTICATED_FULLY or a custom IS_AUTHENTICATED_WITH_TOTP-style check).
2. App\API\Authentication\ApiRequestMatcher routes requests bearing an existing session through the main firewall rather than forcing a separate API authentication path. Consequently, a session cookie that is still in the pre-TOTP state is recognized as an authenticated session.
3. Scheb TwoFactorToken — the token emitted by the Scheb two-factor bundle before the second factor is satisfied — does satisfy the IS_AUTHENTICATED rule. This is the crux: a token that semantically represents "password verified, MFA pending" is being accepted as sufficient for the API.
4. App\Voter\ApiVoter then grants API access to the User object associated with that token, completing the authorization decision in the attacker's favor.

The net effect is a classic privilege/authorization-boundary confusion: the web UI correctly blocks the post-password, pre-TOTP session, but the API does not. Because the API shares the same session cookie and firewall context, the attacker simply directs their (partially authenticated) session at /api endpoints instead of web routes. The IS_AUTHENTICATED rule, combined with the ApiVoter decision, permits REST operations that should have required the second factor.

Root cause class: CWE-287 (Improper Authentication) — specifically the failure to require completion of all authentication factors before granting access to a protected resource. The vulnerability is not a memory-safety issue, injection flaw, or cryptographic break; it is a logic/authorization-configuration defect in how MFA state is represented and enforced across two different access surfaces (web vs. API).

Exploitation Scenarios

No public PoC is available; the following attack chain is inferred from the vulnerability class and the technical elements documented in the NVD description. It does not rely on any fabricated endpoint names or parameters beyond those explicitly provided (/api).

1) Reconnaissance / target identification An attacker identifies a Kimai instance (exposed web UI, characteristic login page, or known API base path). They confirm the target has MFA enabled for the account they intend to abuse, and they possess — or have obtained — valid login credentials for that account (for example via credential stuffing, phishing, password reuse, or a previously leaked password). The attacker does not need the victim's TOTP secret or an active MFA device.

2) Triggering the flaw class The attacker authenticates normally with the username and password. The application verifies the password and issues the KIMAI_SESSION cookie, but then halts the web flow at the second-factor prompt. At this point the session token is the intermediate Scheb TwoFactorToken state. Instead of completing TOTP, the attacker simply uses this session cookie against /api routes.

3) Payload / execution method (vulnerability-class level) The attacker sends authenticated REST API requests to the Kimai API endpoints, presenting the pre-TOTP KIMAI_SESSION cookie. Because the API access rule is IS_AUTHENTICATED, the intermediate token satisfies it; ApiRequestMatcher routes the request through the main firewall, and ApiVoter authorizes the underlying User. The API therefore processes the request as though MFA had been completed. No special payload is required — the "payload" is simply the legitimate API request performed without supplying a one-time code. (No specific API endpoint paths or parameters are documented in the source data, so none are asserted here.)

4) Post-exploitation impact With API access, the attacker can read and manipulate the time-tracking data, users, projects, activities, and related records that the compromised account is entitled to via the REST API — bypassing the MFA control entirely. The web routes, which do enforce the second factor, remain inaccessible, but that limitation does not materially reduce impact: the API is the broader, machine-friendly attack surface. The account owner and defenders may see successful API activity with no corresponding MFA event, complicating attribution and detection.

Impact Assessment

The primary impact is a defeat of the second authentication factor on the API surface for any account whose password is known to the attacker. Under a representative CVSS v3.1 assessment (the authoritative score is unavailable; the vector below is a reasoned estimate consistent with the described behavior), the profile is:

• Attack Vector (AV:N): Network — the API is reachable over the network.
• Attack Complexity (AC:L): Low — no race condition or specialized conditions; a valid password and a pre-TOTP session suffice.
• Privileges Required (PR:L): Low — the attacker must already hold a valid account password.
• User Interaction (UI:N): None — no victim action is required.
• Scope (S:U): Unchanged — the vulnerable component authorizes access to its own resources.
• Confidentiality (C:H) / Integrity (I:H): High — API access exposes and allows modification of protected time-tracking data.
• Availability (A:N): None directly attributable.

Blast radius: Any Kimai deployment below 2.59.0 that (a) enables MFA and (b) where an attacker can obtain a valid password. Because MFA is marketed as a compensating control against password compromise, the affected population is precisely the set of organizations that believed they were protected. Business impact includes unauthorized disclosure and tampering with time/billing records, potential payroll or invoicing inaccuracies, and erosion of trust in the MFA control across the environment. The exploit requires credential knowledge, which moderates the effective risk (EPSS 0.00429, ~36.5th percentile), but for targeted attackers who already possess a password (post-phishing or post-stuffing), it converts a partially blocked account into full API control.

Detection Guidance

Given that exploitation reuses a legitimate credential and a partially authenticated session, detection must focus on the mismatch between a password-verified, pre-TOTP session and successful /api activity — i.e., API access that was never preceded by a completed second-factor event.

Sigma Rule

title: Kimai API Access Without Completed MFA (CVE-2026-52827)
id: 8f2c1a94-6b7d-4e2a-9c31-1d5a0c9e7f42
status: experimental
description: Detects Kimai API requests authorized using a KIMAI_SESSION cookie issued before TOTP completion, indicating exploitation of the CVE-2026-52827 authentication bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-52827
author: Threat Intelligence - valtersit.com
date: 2026/01/01
tags:
  - attack.t1078
  - attack.defense_evasion
logsource:
  category: web
  product: kimai
detection:
  selection_api:
    cs-uri-stem|startswith:
      - '/api/'
  selection_session:
    cs-cookie|contains: 'KIMAI_SESSION'
  filter_mfa_complete:
    mfa_completed: 'true'
  condition: selection_api and selection_session and not filter_mfa_complete
falsepositives:
  - Legitimate sessions immediately after login where the MFA event log has not yet been correlated
level: high

YARA Rule

rule CVE_2026_52827_Kimai_MFA_Bypass_Session
{
    meta:
        author = "Threat Intelligence - valtersit.com"
        description = "Detects KIMAI_SESSION cookie material in web server logs or captures consistent with the pre-TOTP API auth bypass in Kimai < 2.59.0"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-52827"
        cve = "CVE-2026-52827"
        date = "2026-01-01"

    strings:
        $cookie = "KIMAI_SESSION" ascii wide nocase
        $api    = "/api/" ascii wide
        $twofa  = "TwoFactorToken" ascii wide
        $match  = "ApiRequestMatcher" ascii wide

    condition:
        $cookie and (any of ($api, $twofa, $match))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-52827 Kimai API access with pre-TOTP KIMAI_SESSION cookie"; flow:established,to_server; http.uri; content:"/api/"; http.cookie; content:"KIMAI_SESSION"; classtype:attempted-user; reference:cve,2026-52827; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-52827; sid:2026528271; rev:1; metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Elastic Detection

sequence by source.ip with maxspan=10m
  [ authentication where event.outcome == "success" and user.name != null ]
  [ network where url.path startswith "/api/" and http.request.method in ("GET","POST","PUT","DELETE","PATCH") and
      http.request.headers.cookie contains "KIMAI_SESSION" ]

Splunk SPL Query

index=web sourcetype=kimai_access
| where match(uri, "^/api/") AND match(cookie, "KIMAI_SESSION")
| eval mfa_state = if(match(_raw, "(?i)mfa_completed=true|totp_verified=true"), "complete", "pending_or_missing")
| where mfa_state = "pending_or_missing"
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as api_paths by src_ip, user
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="kimai,web,authentication_bypass,cve_2026_52827">
  <rule id="202652827" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <match>KIMAI_SESSION</match>
    <regex type="pcre2">^/api/</regex>
    <description>CVE-2026-52827: Kimai API request using pre-TOTP KIMAI_SESSION cookie (MFA bypass) - possible exploitation.</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>authentication_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 2/4 (CLAIMED — a single source, OSV, claims a fix; this has not been independently confirmed). Treat the version number as a strong indicator but verify against the upstream Kimai release and advisory before closing the risk.

1) Immediate mitigations (until patched/verified)

• Where MFA is enabled, restrict access to /api to trusted network ranges or require API access through a reverse proxy that enforces an independent authentication/second-factor control.
• Temporarily consider disabling API access for accounts that require MFA if the API is not operationally needed, or force full session re-authentication (terminate intermediate sessions promptly and reduce session/idle timeouts to shrink the pre-TOTP window).
• Audit authentication logs for API activity originating from sessions that never logged a completed TOTP event; initiate credential resets for any account showing such activity.

2) Patch / upgrade steps

• Upgrade Kimai to 2.59.0 or later, per the OSV advisory. Because patch confidence is only CLAIMED, confirm the fix is present in the target release (release notes/changelog) before relying on it.
• After upgrading, validate that API routes now require fully authenticated (post-MFA) sessions: authenticate with a password but stop before TOTP, then confirm /api requests are rejected.
• Rotate any API-accessible credentials and review API audit logs for unauthorized activity during the exposure window.

3) Long-term hardening

• Change the API access rule from IS_AUTHENTICATED to a stricter check that requires completion of all factors (e.g., fully authenticated / MFA-complete token), and ensure ApiRequestMatcher/ApiVoter do not authorize intermediate Scheb TwoFactorToken states.
• Add automated authorization tests that assert intermediate/partial authentication tokens cannot reach protected API resources.
• Adopt defense-in-depth: rate-limit authentication, alert on successful API access without a corresponding MFA event, and enforce least privilege on API account scopes.

References

• NVD — CVE-2026-52827: https://nvd.nist.gov/vuln/detail/CVE-2026-52827
• OSV advisory (cited patch source, "fixed in 2.59.0"): https://osv.dev/ (search CVE-2026-52827)
• Kimai project / release notes for 2.59.0 (verify patch): https://www.kimai.org/
• MITRE CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/

Threat actor / exploit-in-the-wild: None observed. CISA KEV: NOT listed. No public PoC, Nuclei template, or exploit code is available as of this reporting. EPSS 0.00429 (~36.5th percentile) indicates low predicted exploitation likelihood, consistent with the requirement that an attacker already possess a valid password.