Critical Kimai Docker Flaw Lets Attackers Forge Cookies, Take Over Accounts
Key Takeaways A critical vulnerability (CVE-2026-52824) has been discovered in Kimai’s official Docker image. The flaw allows unauthenticated attackers to forge authentication cookies and...
Key Takeaways
- A critical vulnerability (CVE-2026-52824) has been discovered in Kimai’s official Docker image.
- The flaw allows unauthenticated attackers to forge authentication cookies and potentially compromise user accounts, including those of super administrators.
- The root cause is an insecure default value for the
APP_SECRETenvironment variable. - All Kimai installations using Docker images up to version 2.57.0 are affected.
- A fix is available in Kimai version 2.58.0, and immediate updates are strongly recommended.
Users of Kimai, the popular open-source time-tracking application, are being urged to update their Docker-based deployments immediately. A critical security flaw, identified as CVE-2026-52824, has been uncovered that could enable unauthenticated attackers to craft valid authentication cookies, leading to potential account takeovers, including highly privileged super administrator accounts.
Table Of Content
The vulnerability impacts Kimai versions 2.57.0 and earlier when deployed via its official Docker image. The issue has been addressed and patched in Kimai version 2.58.0.
The Insecure Default Secret
The core of the problem lies with an insecure default value for the APP_SECRET environment variable within the official Kimai Docker image. This variable functions as Symfony’s kernel secret, a cryptographic key vital for generating and validating HMAC-signed security tokens within the application.
Historically, the Docker image included a publicly known default value: “change_this_to_something_unique.” While this was intended as a placeholder, the Docker startup process failed to enforce its replacement or automatically generate a new, unique secret. Consequently, many deployments might have inadvertently retained this insecure default, making them susceptible to attack.
Exploiting the Known Secret
With knowledge of this predictable cryptographic key, an attacker can forge various security-sensitive values. According to the GitHub advisory (GHSA-jr9p-4h4j-6c58), this includes the KIMAI_REMEMBER “remember me” cookie, signatures for login links, password reset URLs, and CSRF tokens.
An attacker with network access to a vulnerable Kimai instance could leverage this to impersonate users without requiring their actual credentials. For a full account takeover, the attacker would need to know a target username and their corresponding user ID. Kimai user IDs are sequential, typically starting at 111, which can make them relatively easy to guess in many installations. The first super administrator account is often assigned ID 111, making these accounts particularly attractive targets for compromise.
While two-factor authentication (2FA) can offer a layer of protection if enabled on a targeted account, the advisory explicitly warns that accounts without active 2FA are at a high risk of complete compromise. Given that the attack can be executed remotely against an exposed application, organizations running Kimai with default Docker configurations should treat this vulnerability with extreme urgency.
The vulnerability, reported by security researcher AzureADTrent, has been categorized as critical and is associated with CWE-1188, “Initialization of a Resource with an Insecure Default.” Although a proof-of-concept exploit was initially shared, it has since been removed to mitigate the risk of widespread exploitation.
Patch and Mitigation
Kimai version 2.58.0 introduces significant changes to the Docker initialization process to prevent insecure setups. The updated entrypoint now generates a random APP_SECRET using bin2hex(random_bytes(32)) if an administrator has not explicitly provided one. This newly generated secret is stored in /opt/kimai/var/data/.appsecret, and the deployment configuration is written to /opt/kimai/.env.local.
Furthermore, the maintainers have removed the hard-coded default secret from the Dockerfile and updated the official documentation to emphasize the importance of using a unique, randomly generated secret. Kimai has also independently enhanced login link entropy in a separate advisory to further reduce risks associated with predictable secrets in older configurations.
What You Should Do
- Upgrade Immediately: Update all Kimai Docker installations to version 2.58.0 or later without delay.
- Set a Unique APP_SECRET: Explicitly configure a high-entropy, unique
APP_SECRETfor your Kimai instance. Do not rely on default values. - Rotate Credentials and Sessions: Whenever feasible, rotate all user credentials and terminate active sessions to invalidate any potentially forged tokens.
- Review Administrator Accounts: Conduct a thorough review of all administrator accounts for any suspicious activity.
- Enable Two-Factor Authentication (2FA): Ensure 2FA is enabled for all privileged user accounts to add an extra layer of security against account takeovers.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.