Critical Kimai Docker Vulnerability Enables Super Admin Account Takeover (CVE-2026-52824)

A critical security vulnerability has been disclosed in the official Kimai Docker image that could allow unauthenticated attackers to compromise any user account, including the highly privileged super_admin account.

The flaw, tracked as CVE-2026-52824, affects Docker-based Kimai deployments that rely on the default application configuration without manually replacing the predefined APP_SECRET.

Security researchers warn that the issue poses a significant risk because it enables attackers to forge authentication tokens and bypass normal authentication mechanisms, potentially leading to complete administrative control of vulnerable instances.

Critical Kimai Docker Vulnerability

The vulnerability originates from a hardcoded default secret included in the official Kimai Docker image. Specifically, the Dockerfile defines the environment variable APP_SECRET=change_this_to_something_unique as the default value.

While this placeholder is intended to be replaced during deployment, the container’s startup process failed to validate or automatically generate a secure alternative.

As a result, administrators who deployed Kimai using the default Docker configuration unknowingly operated their applications with a publicly known Symfony kernel.secret, creating a severe authentication weakness.

Symfony relies on the APP_SECRET to generate HMAC signatures for several security-sensitive features, including remember-me cookies (KIMAI_REMEMBER), LoginLink authentication, password reset URLs, and Cross-Site Request Forgery (CSRF) tokens.

Because the default secret was publicly known, attackers could independently generate valid authentication tokens without requiring prior access to the application. This effectively breaks the trust model of these security mechanisms and enables unauthorized account access.

The exploitation process is particularly dangerous because Kimai assigns sequential numeric IDs to user accounts. In most installations, the very first account created is assigned ID 1, which typically belongs to the super_admin user.

Since user IDs are often exposed through application URLs, API responses, or other predictable sources, attackers can easily determine valid account identifiers.

By combining the publicly known APP_SECRET, a valid username, the corresponding user ID, and the absence of two-factor authentication (2FA), an attacker can successfully forge authentication tokens and hijack privileged accounts without needing valid credentials.

The vulnerability has been classified under CWE-1188: Initialization of a Resource with an Insecure Default, highlighting the dangers of shipping production software with insecure default configurations.

Security experts also noted that the issue extended beyond Docker deployments. The same placeholder secret appeared in Kimai’s bare-metal .env.dist template, and the application contained no startup validation to prevent deployments from running with the insecure default value. This increased the overall attack surface for organizations that failed to customize the secret during installation.

Kimai maintainer Kevin Papst has resolved the vulnerability in Kimai version 2.58.0 by introducing multiple security improvements. The updated entrypoint.sh script now automatically generates a cryptographically secure APP_SECRET using bin2hex(random_bytes(32)) whenever a custom secret is not supplied.

The generated secret is securely stored in /opt/kimai/var/data/.appsecret and written to /opt/kimai/.env.local during container initialization.

Additionally, the insecure default value has been completely removed from the Dockerfile, preventing future deployments from inheriting the vulnerable configuration.

The project documentation has also been updated to emphasize the importance of configuring a unique secret, while a companion advisory (GHSA-m492-gv72-xvxj) introduces additional entropy to LoginLink tokens, further reducing exploitation risks for older deployments.

Organizations running Kimai through Docker are strongly advised to upgrade immediately to version 2.58.0 or later. For environments where an immediate upgrade is not possible.

Administrators should manually configure a strong, randomly generated APP_SECRET, restart affected containers, invalidate existing authentication sessions where appropriate, and enforce two-factor authentication for all administrative accounts.

Prompt remediation is essential to prevent unauthorized account takeover and protect sensitive time-tracking data from compromise.