CVE-2026-52821

Executive Summary

CVE-2026-52821 is an authorization bypass (CWE-639, Authorization Bypass Through User-Controlled Key) in Kimai, an open-source time-tracking application. Prior to version 2.57.0, authenticated users holding only the generic create_activity or create_project capability can submit GET or POST requests to /en/admin/activity/create/{project} or /en/admin/project/create/{customer} and persist a new child object under a parent Project or Customer for which they hold no edit rights. The impact is integrity-focused: unauthorized creation of business objects that pollute project/customer configuration and silently influence downstream time-entry, rate, reporting, and billing behavior. No public PoC, exploit code, or Nuclei template is known, and EPSS remains low (0.00257, 17.5th percentile).

Technical Analysis

The vulnerability is an instance of CWE-639: Authorization Bypass Through User-Controlled Key. In this class of flaw, an application trusts a client-supplied object identifier to select a parent (or target) record but fails to re-validate that the requesting principal is authorized to act on that specific record. Here, the object key is the parent identifier embedded in the route — {project} in /en/admin/activity/create/{project} and {customer} in /en/admin/project/create/{customer}.

Per the NVD description, the affected endpoints require only the generic creation capability (create_activity or create_project) and explicitly "do not verify edit access to the supplied Project or Customer object." Kimai's permission architecture distinguishes between broad functional capabilities (can this user create activities/projects at all?) and scoped access to individual business objects. The faulty logic conflates these two checks: passing the generic capability gate is treated as sufficient, and the object-scoped authorization check is omitted.

The preset-parent creation logic in src/Controller/ActivityController.php and src/Controller/ProjectController.php is the vulnerable mechanism. The route parameter supplies a parent identifier, and the controller's "preset parent" convenience logic uses that identifier directly to set the parent relationship on the newly created child object. Because the user controls the key and no edit-access verification is performed against that key, a user who merely knows a valid project.id or customer identifier — whether by guessing, enumeration, or incidental disclosure — can bind a new child business object to an unauthorized parent.

Two properties make this reliably exploitable at the vulnerability-class level:

1. Authenticated, low-privilege trigger. Any account with create_activity/create_project is sufficient. No administrator role, no UI interaction beyond the request itself (UI:N).
2. IDOR-style key requirement. The attacker must supply a valid parent identifier. The description notes that knowledge of a valid key is the precondition, which implies identifier disclosure or enumeration is the practical gating factor rather than any cryptographic or permission barrier.

The description does not enumerate the exact request parameters, HTTP method semantics beyond "GET or POST," or any CSRF characteristics, so this report does not speculate on them. The essential technical claim derivable from the source is: creation-capability checks pass; object-scoped edit checks are absent; the client-controlled parent key is trusted.

Exploitation Scenarios

No public PoC is available; the chain below is inferred strictly from the vulnerability class and the NVD description. Only identifiers appearing in the description are used.

1. Reconnaissance / target identification. The attacker authenticates with an account carrying the create_activity or create_project capability. They then identify a valid parent identifier: a project.id for the activity endpoint, or a customer identifier for the project endpoint. Because the flaw requires "a user who knows a valid project.id or customer identifier," disclosure or inference of that identifier is the reconnaissance objective. Kimai is multi-tenant by team/customer, so the valuable targets are projects and customers the attacker cannot normally edit.

2. Triggering the flaw class. The attacker issues a GET or POST request to /en/admin/activity/create/{project} (using the target project.id) or /en/admin/project/create/{customer} (using the target customer identifier). The route's generic capability check (create_activity / create_project) is satisfied by the attacker's own role. The missing object-scoped edit-access check is what permits the request to proceed against a parent the attacker has no rights over. This is textbook IDOR / user-controlled-key authorization bypass.

3. Payload / execution at the vulnerability-class level. The "payload" is the crafted object identifier in the URL path. The preset-parent creation logic in src/Controller/ActivityController.php or src/Controller/ProjectController.php then persists a new child business object (an activity under the project; a project under the customer) bound to the attacker-selected parent. No code execution, deserialization, or injection is involved — the impact is state corruption via unauthorized object creation.

4. Post-exploitation impact. The persisted child object now pollutes the parent's configuration. Per the description, this "influences later time-entry, rate, reporting, and billing behavior": billable activity may be booked against a project the attacker doesn't control; rate tables and reporting aggregates for that project/customer are altered; and downstream billing derived from those records is skewed. The attacker gains no direct read access (C:N) but achieves high integrity impact (I:H) on business records.

Impact Assessment

• Confidentiality (C:N): The flaw is a creation/authorization-bypass issue; nothing in the description indicates data exfiltration.
• Integrity (I:H): Unauthorized creation of child objects bound to unauthorized parents directly corrupts project/customer configuration and the time-entry, rate, reporting, and billing records that depend on it. This is the primary impact.
• Availability (A:N): No denial-of-service mechanism is described.
• Scope (S:U): Effects remain within the Kimai application's authorization and data model; no sandbox or privilege-boundary escape beyond the intended object scope is described.
• Attack vector / complexity / privileges / UI: Network-reachable (AV:N), no special conditions beyond a valid key (AC:L), requires a low-privileged authenticated account (PR:L), and no user interaction (UI:N). Note: NVD lists no CVSS score for this CVE ("N/A"), so the vector above is an analyst-derived estimate consistent with CWE-639; it is not vendor- or NVD-published and should be treated as provisional.
• Blast radius: Any Kimai instance < 2.57.0 with multiple teams/customers/projects where lower-privileged users legitimately hold only create-level capabilities. Billing integrity is the highest-value exposure, since Kimai is frequently used for client invoicing.
• Exploitability reality: EPSS 0.00257 (17.5th percentile), no KEV listing, no public PoC, no Nuclei template. Exploitation requires an authenticated account and a valid parent key, which tempers mass-exploitation risk while leaving targeted insider or cross-tenant abuse fully viable.

Detection Guidance

Because no public exploit artifacts exist, detections focus on anomalous create requests containing parent identifiers and on authorization-denied patterns. Tune identifiers to your deployment.

Sigma Rule

title: Kimai Unauthorized Child Object Creation via Preset-Parent Endpoints (CVE-2026-52821)
id: 8f3c1a2e-6b7d-4e5f-9a10-2c3d4e5f6a7b
status: experimental
description: Detects access to Kimai preset-parent creation endpoints that may indicate CWE-639 authorization bypass on versions prior to 2.57.0
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-52821
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
detection:
  selection_path:
    cs-uri-stem|contains:
      - '/admin/activity/create/'
      - '/admin/project/create/'
  selection_method:
    cs-method: 
      - 'GET'
      - 'POST'
  condition: selection_path and selection_method
falsepositives:
  - Legitimate administrators creating activities or projects under authorized parents
level: medium

YARA Rule

rule CVE_2026_52821_Kimai_AuthzBypass
{
    meta:
        author = "valtersit.com"
        description = "Detects references to Kimai preset-parent creation endpoints associated with CVE-2026-52821 in logs or artifacts"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-52821"
        date = "2026-01-01"
        severity = "medium"
    strings:
        $ep1 = "/admin/activity/create/" ascii wide nocase
        $ep2 = "/admin/project/create/" ascii wide nocase
        $cve = "CVE-2026-52821" ascii wide
        $ver = "Kimai" ascii wide nocase
    condition:
        (uint16(0) == 0x3C3F or uint32(0) == 0x696D614B) and
        (any of ($ep1, $ep2)) and $ver or $cve
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-52821 Kimai Unauthorized Child Object Creation Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/admin/activity/create/"; nocase; sid:2026528210; rev:1;)
alert http any any -> any any (msg:"CVE-2026-52821 Kimai Unauthorized Project Creation Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/admin/project/create/"; nocase; sid:2026528211; rev:1;)

Elastic Detection

sequence by user.name with maxspan=30s
  [ url.path : ("*/admin/activity/create/*" or "*/admin/project/create/*") and http.request.method : ("GET" or "POST") ]
  [ http.response.status_code : 200 or http.response.status_code : 302 ]

Splunk SPL Query

index=web sourcetype=access_combined
| eval uri=lower(uri)
| where (match(uri,"/admin/activity/create/") OR match(uri,"/admin/project/create/"))
        AND (method="GET" OR method="POST")
| stats count values(uri) as targets values(status) as statuses by src_ip, user
| where count > 0
| sort - count
| table src_ip user count targets statuses

Wazuh OSSEC Rule

<group name="web,kimai,cve-2026-52821,">
  <rule id="100821" level="7">
    <decoded_as>web-accesslog</decoded_as>
    <url>/admin/activity/create/|/admin/project/create/</url>
    <description>CVE-2026-52821: Kimai preset-parent creation endpoint accessed - possible authorization bypass (CWE-639)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100822" level="10">
    <if_sid>100821</if_sid>
    <status>^20[01]$|^30[12]$</status>
    <description>CVE-2026-52821: Kimai child object created successfully via preset-parent endpoint (possible unauthorized parent)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor advisory, commit reference, or tracked patch source is available, and the affected-version list is empty in the supplied data. Treat the guidance below as defense-in-depth until an authoritative update is verified.

1. Immediate mitigations

   • Restrict who holds create_activity and create_project capabilities. The flaw requires only these generic capabilities, so narrowing their assignment reduces the exploitable population.
   • Enforce object-scoped authorization at the reverse proxy or application gateway where feasible: block or alert on /admin/activity/create/{project} and /admin/project/create/{customer} requests from users lacking edit access to the referenced parent.
   • In multi-tenant deployments, segregate teams/customers so that create-capable users cannot see or infer identifiers for projects/customers they do not own, limiting key discovery.
   • Monitor the detection rules above for anomalous create/302 patterns; investigate any child object created under a parent the actor does not own.

2. Patch / upgrade steps

   • The NVD description states the issue is fixed in Kimai 2.57.0. Upgrade to 2.57.0 or later as soon as the release is available from your normal distribution channel.
   • Because patch confidence is 0/4 and no vendor advisory is tracked in the supplied data, independently verify the 2.57.0 fix (e.g., by reviewing the upstream changelog/commit and confirming the object-scoped edit check is present in ActivityController.php and ProjectController.php) before relying on it.
   • Until verified, treat affected versions as unpatched and keep the mitigations above active.

3. Long-term hardening

   • Adopt a consistent authorization pattern that always validates object-scoped permissions, not just functional capabilities, on any request that accepts a client-supplied object key.
   • Add automated tests/regression checks for IDOR-style parent-binding on all create endpoints.
   • Apply least privilege to Kimai roles; audit which users genuinely require creation capabilities.
   • Integrate object-ownership checks into code review for controllers that accept route parameters referencing business entities.

References

• NVD — CVE-2026-52821: https://nvd.nist.gov/vuln/detail/CVE-2026-52821
• MITRE CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• Kimai project (upstream; verify 2.57.0 release notes): https://www.kimai.org/
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Exploit-in-the-wild / threat actor activity: None observed. CISA KEV status: NO. EPSS 0.00257 (17.5th percentile). No public PoC, exploit code, or Nuclei template is known. There are no known threat actor campaigns associated with this CVE as of the data provided.