Skip to content
Data Breach

Kimai Docker Flaw Lets Unauthenticated Attackers Forge Cookies and Take Over Accounts

Kimai users utilizing the official Docker image are strongly urged to update their installations following the disclosure of a critical vulnerability that could allow unauthenticated attackers to forge authentication cookies and potentially take over accounts, including super administrator accounts....

· Jul 20, 2026 · 3 min read · 👁 3 views
Kimai Docker Flaw Lets Unauthenticated Attackers Forge Cookies and Take Over Accounts

Kimai users utilizing the official Docker image are strongly urged to update their installations following the disclosure of a critical vulnerability that could allow unauthenticated attackers to forge authentication cookies and potentially take over accounts, including super administrator accounts.

This vulnerability, tracked as CVE-2026-52824, affects Kimai versions 2.57.0 and earlier. The issue has been resolved in Kimai version 2.58.0.

Kimai is an open-source time-tracking application widely used by businesses and teams, delivered via Docker containers. The flaw originates from an insecure default value for the application’s APP_SECRET environment variable.

The official Docker image included the publicly known value “change_this_to_something_unique,” which was intended to be replaced during deployment. However, the Docker startup process did not enforce this requirement or automatically generate a replacement secret.

Kimai uses APP_SECRET as Symfony’s kernel secret, a cryptographic value required to create and validate HMAC-signed security tokens. If an installation continues to use the default secret, an attacker can exploit the known cryptographic key to forge tokens that the application might trust.

Kimai Docker Vulnerability

The GitHub advisory states that the exposed secret could allow attackers to forge several security-sensitive values, including the KIMAI_REMEMBER remember-me cookie, login link signatures, password reset URLs, and CSRF tokens.

An attacker with network access to a vulnerable Kimai instance could impersonate a user without needing valid credentials. For an account takeover scenario to occur, the attacker would need knowledge of a target username and the ability to identify the account’s user ID.

Kimai user IDs are sequential integers starting at 111, making them relatively predictable in many deployments. The first super administrator account is often assigned ID 111, making these privileged accounts attractive targets.

Two-factor authentication (2FA) can mitigate the attack when enabled on the targeted account. However, the advisory warns that accounts without active 2FA could be completely compromised.

Since the attack can be executed remotely against an exposed application, organizations that have deployed Kimai using default Docker settings should consider this issue urgent.

The vulnerability has been classified as critical and is associated with CWE-1188, “Initialization of a Resource with an Insecure Default.” Security researcher AzureADTrent reported the issue.

A proof of concept was initially provided but later removed to reduce the risk of exploitation. Kimai version 2.58.0 modifies the Docker initialization process to prevent the insecure setup.

The upgraded entrypoint generates a random APP_SECRET using bin2hex(random_bytes(32)) if an administrator has not supplied one. The generated secret is stored in /opt/kimai/var/data/.appsecret, and the deployment configuration is written to /opt/kimai/.env.local.

According to the GitHub advisory (GHSA-jr9p-4h4j-6c58), the maintainers removed the hard-coded default secret from the Dockerfile and updated the documentation to recommend using a unique, randomly generated secret.

Additionally, Kimai has strengthened login-link entropy in a separate advisory to reduce risks associated with predictable secrets in older configurations.

Administrators should immediately upgrade to Kimai version 2.58.0 or later. They should also explicitly set a high-entropy, unique APP_SECRET, rotate credentials and active sessions when feasible, review administrator accounts, and enable two-factor authentication for all privileged users.

Source: CybersecurityNews.com

Follow ShomoySoft for more: Follow on Facebook

💬 Comments (0)

Login to join the discussion.

No comments yet. Be the first!

Related Articles

Recommended for you