CVE-2026-52824

Executive Summary

CVE-2026-52824 affects Kimai, an open-source time tracking application, prior to version 2.58.0. The official Docker image ships a static, publicly known APP_SECRET value (change_this_to_something_unique) that the container entrypoint neither replaces nor rejects, causing Symfony to use it as kernel.secret. An unauthenticated attacker who can reach a deployment that failed to override APP_SECRET, knows a valid username, correctly guesses the corresponding account ID, and targets an account without active two-factor authentication can forge HMAC-protected authentication artifacts (including KIMAI_REMEMBER cookies and login links) to gain account access without the password.

Technical Analysis

The vulnerability is classified as CWE-1188: "Insecure Default Initialization of Resource." The root cause is a hardcoded default cryptographic secret. The official Docker image defines APP_SECRET as the public value change_this_to_something_unique in the Dockerfile. The container's .docker/entrypoint.sh script neither replaces nor rejects this value before the application starts. Symfony subsequently consumes this value as kernel.secret, the keying material used to sign and verify HMAC-protected artifacts.

Symfony's authentication subsystem uses kernel.secret to produce HMAC signatures over several security-relevant artifacts. Two categories are explicitly called out in the advisory: the KIMAI_REMEMBER "remember me" cookie and login links. Because the HMAC key is a publicly known constant, any party who knows the key can generate a valid signature for an arbitrary artifact. This defeats the integrity guarantee that the HMAC is intended to provide.

The attack surface is the network-exposed Kimai deployment. Exploitation requires a specific set of preconditions described by the advisory:

1. The deployment did not override APP_SECRET (i.e., it is running the stock Docker image defaults).
2. The attacker knows a valid username.
3. The attacker correctly guesses the account ID associated with that username.
4. The target account does not have active two-factor authentication.

When these conditions align, the attacker can forge the HMAC-protected authentication artifacts and present them to the application, which verifies them against the known secret and accepts them as legitimate. This yields account access without knowledge of the victim's password. The advisory frames this as an unauthenticated attack against a deployment that meets the above conditions.

No CVSS score or vector was published with the supplied data; the CVSS vector included in this report is an analytical estimate consistent with the described preconditions (network attack vector, high attack complexity due to the username/ID/TF and deployment preconditions, no privileges required, no user interaction, high confidentiality and integrity impact, no availability impact). Treat it as an estimate, not a vendor-published score.

Exploitation Scenarios

The following chain is derived strictly from the advisory's stated preconditions and vulnerability class. No public proof-of-concept code was provided in the supplied data, so the steps are described at the mechanism level without speculative implementation detail.

1. Reconnaissance / target identification. The attacker identifies internet- or network-exposed Kimai deployments. Deployments running the official Docker image with an unmodified APP_SECRET are the target population. The attacker determines, or already knows, a valid username for the target instance.

2. Precondition verification. The attacker confirms the deployment likely retains the default secret (for example, an unmodified stock image) and identifies an account ID associated with the known username. The attacker also selects a target account that does not have active two-factor authentication enabled.

3. Artifact forgery. Because kernel.secret equals the publicly known change_this_to_something_unique value, the attacker computes a valid HMAC for an authentication artifact using that known key. The advisory explicitly permits forging KIMAI_REMEMBER cookies and login links. This is the core of the attack: the integrity of the signature no longer depends on a secret because the key is public.

4. Submission and access. The attacker presents the forged KIMAI_REMEMBER cookie or login link to the application. Kimai verifies the HMAC against the known secret, accepts the artifact as valid, and grants access to the targeted account without the account password.

5. Post-exploitation impact. Successful access to a time tracking account can expose and allow modification of time, project, customer, and activity data, depending on the privileges of the compromised account. Because the advisory concerns authentication artifact forgery, persistence via the remember-me mechanism is possible for as long as the deployment continues to use the insecure default secret.

Note: no exploit code or Nuclei template was supplied; the chain above is inferred from the vulnerability class and the advisory's stated preconditions. Attackers must satisfy all of the enumerated conditions (no APP_SECRET override, known username, correctly guessed account ID, no active 2FA) for the attack to succeed.

Impact Assessment

Successful exploitation results in unauthorized account access without the victim's password. The confidentiality and integrity impact is high for the compromised account: an attacker can read and, depending on role, modify time tracking, project, customer, and reporting data. Availability impact is minimal because the flaw does not directly affect service uptime.

Blast radius is bounded by the advisory's preconditions. Only deployments that (a) run the official Docker image, (b) did not override APP_SECRET, and (c) host the targeted accounts (without 2FA) are at risk for account takeover. A single instance may host multiple user accounts, and each account satisfying the username/ID/no-2FA conditions is independently targetable.

Because the secret is a public constant, all vulnerable deployments share the same keying material, meaning a forged artifact technique developed for one instance applies conceptually to any other instance that retains the default. The EPSS score of 0.02062 (80.4th percentile) indicates a modest but non-trivial predicted exploitation probability relative to other CVEs. There is no CISA KEV listing and no confirmed exploit-in-the-wild evidence in the supplied data. The advisory does describe a public PoC status (PoC/Exploit: Public) but no exploit code was provided.

Detection Guidance

Sigma Rule

title: Kimai Forged Authentication Artifact Using Default APP_SECRET
id: 7f3a1c92-4b6e-4d21-9f0a-1c2d3e4f5a6b
status: experimental
description: Detects access attempts consistent with forged KIMAI_REMEMBER cookies or login links against Kimai instances that may retain the default APP_SECRET.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-52824
author: valtersit.com
date: 2026-02-01
logsource:
  category: webserver
  product: kimai
detection:
  selection_path:
    cs-uri-stem|contains:
      - '/login'
      - '/en/login'
      - '/de/login'
  selection_cookie:
    cs-cookie|contains: 'KIMAI_REMEMBER'
  selection_status:
    sc-status:
      - 200
      - 302
  condition: selection_path and selection_cookie and selection_status
falsepositives:
  - Legitimate remember-me logins by authenticated users
level: medium
tags:
  - attack.t1190
  - cve.2026.52824

YARA Rule

rule CVE_2026_52824_Kimai_Default_App_Secret
{
    meta:
        description = "Detects the publicly known default APP_SECRET value shipped in Kimai Docker images"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-52824"
        date = "2026-02-01"
        severity = "high"

    strings:
        $secret = "change_this_to_something_unique"
        $appsecret = "APP_SECRET" ascii wide nocase

    condition:
        $secret and $appsecret
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-52824 Kimai Forged KIMAI_REMEMBER Cookie Attempt"; flow:established,to_server; http.cookie; content:"KIMAI_REMEMBER"; http.uri; content:"/login"; reference:cve,2026-52824; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-52824; classtype:attempted-user; sid:202652824; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=60s
  [http where http.request.method == "GET" and url.path : ("/login" or "*/login")]
  [http where http.request.method == "GET" and http.request.headers.cookie : "*KIMAI_REMEMBER*" and http.response.status_code == 200]

Splunk SPL Query

index=web sourcetype=access_combined
| search uri_path="*/login*" cookie="*KIMAI_REMEMBER*"
| stats count by src_ip, uri_path, cookie, status
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="kimai,web,">
  <rule id="2026528" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>\.*\/login.*</url>
    <match>KIMAI_REMEMBER</match>
    <description>CVE-2026-52824: Possible Kimai forged KIMAI_REMEMBER cookie / login link authentication attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch (not independently confirmed)). The fix is asserted only by OSV in the supplied data; independently verify against the vendor's release before relying on it alone.

1. Immediate mitigations:

   • Override APP_SECRET on every deployment with a long, random, unique value that is not the public default. Do not use change_this_to_something_unique.
   • Ensure all privileged and sensitive accounts, especially those for which a username may be knowable, have two-factor authentication enabled. This directly blocks the described attack precondition.
   • Restrict network exposure of Kimai instances to trusted networks where feasible, and place authentication endpoints behind access controls or a reverse proxy with rate limiting and monitoring.
   • Rotate any KIMAI_REMEMBER cookies and invalidate login links issued while an insecure secret may have been in use, since artifacts signed with the public key cannot be trusted.

2. Patch/upgrade:

   • Upgrade to Kimai 2.58.0 or later. The updated entrypoint generates and persists a random secret when no safe operator-provided value exists.
   • After upgrading, confirm a non-default secret is in effect (for example by inspecting deployment configuration rather than relying solely on the entrypoint behavior).
   • Rebuild or redeploy Docker images from the patched release so the corrected .docker/entrypoint.sh is in use.

3. Long-term hardening:

   • Treat secrets as first-class deployment configuration: use a secrets manager, generate high-entropy values at deploy time, and fail closed (refuse to start) when a known-default placeholder is detected.
   • Add configuration checks to CI/CD and infrastructure-as-code pipelines that reject known default secrets.
   • Enforce two-factor authentication organization-wide and monitor for authentication anomalies such as remember-me cookie use from new networks.
   • Monitor vendor advisories and subscribe to release channels for Kimai to shorten exposure windows for future issues.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-52824
• OSV advisory (patch source cited in supplied data): https://osv.dev/ (search CVE-2026-52824)
• Kimai project and release notes (version 2.58.0): https://www.kimai.org/
• CWE-1188 — Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html

Threat actor campaigns / exploit-in-the-wild: none identified in the supplied data. CISA KEV: not listed. PoC/exploit status is Public per supplied data, but no exploit code or Nuclei template was provided, and there is no confirmed in-the-wild exploitation evidence at the time of writing. All technical claims above are limited to what the advisory and metadata explicitly state.