CVE-2026-52824 in Kimai
Summary
by MITRE • 09/15/2026
Kimai is an open-source time tracking application. Prior to 2.58.0, the official Docker image sets APP_SECRET to the public value change_this_to_something_unique in Dockerfile, and .docker/entrypoint.sh neither replaces nor rejects that value before Symfony uses it as kernel.secret. An unauthenticated attacker who reaches a deployment that did not override APP_SECRET, knows a username, correctly guesses the account ID associated with that username, and targets an account without active two-factor authentication can forge HMAC-protected authentication artifacts, including KIMAI_REMEMBER cookies and login links, to access the account without its password. The updated entrypoint generates and persists a random secret when no safe operator-provided value exists. This issue is fixed in version 2.58.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
Kimai is an open-source time tracking application widely deployed via containerized environments, where security configurations are often managed through environment variables or Dockerfile instructions. A critical vulnerability existed in versions prior to 2.58.0 regarding the handling of the APP_SECRET configuration parameter within the official Docker image. The Symfony framework relies on this secret key for generating secure cryptographic tokens, including session identifiers and authentication cookies. In the affected versions, the default value set in the Dockerfile was change_this_to_something_unique, a static string that is publicly accessible as part of the open-source repository source code. Furthermore, the container entrypoint script did not validate or replace this placeholder value before passing it to the Symfony kernel secret configuration. This oversight resulted in deployments using a predictable and known cryptographic key unless explicitly overridden by the operator during setup.
The operational impact of this misconfiguration is severe for unauthenticated attackers who can reach the application interface. Because the APP_SECRET was static and public, an attacker could reverse-engineer or forge HMAC-protected authentication artifacts specific to that deployment. Specifically, the vulnerability allowed for the forgery of KIMAI_REMEMBER cookies and login links without knowledge of the user's password. To successfully exploit this flaw, the attacker required a known valid username from the target system and needed to correctly guess the associated account ID. Additionally, the victim account must not have active two-factor authentication enabled, as MFA would provide an additional layer of security that HMAC forgery alone could not bypass. This scenario highlights a classic case where default configuration values in containerized deployments create significant attack surfaces if operators fail to perform proper hardening procedures before deployment.
From a vulnerability classification perspective, this issue aligns with CWE-798: Use of Hard-coded Credentials and CWE-330: Use of Insufficiently Random Values. The use of a static secret for cryptographic operations violates the fundamental principle that secrets must be unique per instance and unpredictable to external parties. In terms of adversary tactics, this vulnerability facilitates Initial Access through exploitation of software misconfigurations, allowing attackers to bypass authentication mechanisms entirely. It also relates to ATT&CK technique T1078: Valid Accounts, as it enables unauthorized access using legitimate account credentials without requiring password cracking or phishing efforts. The ability to forge session tokens effectively grants the attacker full control over the targeted user's profile and time tracking data, potentially leading to further lateral movement if integrated with other enterprise systems.
Mitigation strategies focus on ensuring that cryptographic secrets are generated dynamically and securely for each deployment instance. For users of Kimai versions prior to 2.58.0, immediate remediation involves manually overriding the APP_SECRET environment variable in the Docker container configuration with a cryptographically strong random string before starting the service. Operators should audit their deployments to ensure no instances remain running with default or placeholder secrets. The vulnerability was addressed in version 2.58.0 by modifying the entrypoint script to automatically generate and persist a unique, random secret when no operator-provided value is detected. This ensures that even if an administrator forgets to configure the secret manually, the application will not fall back to a predictable default. Regular security audits of container configurations and adherence to CIS benchmarks for Docker containers are recommended to prevent similar misconfigurations in future deployments.