Kimai Docker Flaw Exposes Hardcoded APP_SECRET, Enables Full Account Takeover

A critical vulnerability in Kimai, the popular open-source time-tracking software, allowed unauthenticated attackers to hijack any account, including super_admin, by exploiting a hardcoded secret baked directly into the project’s official Docker image.

Tracked as CVE-2026-52824 and cataloged under GHSA-jr9p-4h4j-6c58, the flaw carries a critical severity rating and affects all Kimai versions up to and including 2.57.0. Kimai maintainer kevinpapst published the advisory on June 11, crediting security researcher AzureADTrent for the discovery. A patch shipped in version 2.58.0.

At the heart of the issue sat a single line in Kimai’s Dockerfile: ENV APP_SECRET=change_this_to_something_unique. This placeholder value was meant as a prompt for administrators to set their own secret before deploying. Instead, it became the default in production whenever that step was skipped.

Kimai Docker Flaw

The Docker entrypoint script never checked whether this sentinel value had been replaced, and the bare-metal .env.dist file shipped the identical default. No startup guard existed anywhere in the codebase to block Kimai from launching with this known, public value.

That matters because APP_SECRET feeds directly into Symfony’s kernel.secret, which cryptographically signs several sensitive components:

The KIMAI_REMEMBER remember-me cookie
LoginLink authentication signatures
Password reset URLs
CSRF tokens

With the secret publicly known (it’s literally printed in Kimai’s own source code), anyone could forge valid HMAC signatures for these tokens without ever touching Kimai’s authentication system.

Exploitation hinged on a predictable detail: Kimai assigns user IDs as sequential integers starting at 1, and the first super_admin account almost always occupies that slot. Since user IDs frequently surface in URLs and API responses, an attacker didn’t need to guess blindly; they needed only a username and a plausible account ID.

Armed with the leaked APP_SECRET, an attacker could then forge a valid remember-me cookie or login link for that account ID, bypassing authentication entirely. The only real obstacle was two-factor authentication; accounts without active 2FA were fully exposed. A proof-of-concept exploit was submitted alongside the report but withheld from public release given the severity.

Kimai’s remediation in 2.58.0 addressed the flaw at its source rather than patching around it:

The entrypoint script now generates a cryptographically random secret via bin2hex(random_bytes(32)), stored in /opt/kimai/var/data/.appsecret
This secret populates a new .env.local file automatically, pulling from either the Docker environment or the generated secret file
The Dockerfile no longer contains a hardcoded default value at all
Login link generation now uses additional entropy (tracked separately as GHSA-m492-gv72-xvxj), adding a second layer of defense even if a secret is somehow compromised again
Documentation was updated to stress that administrators must treat APP_SECRET as a genuine secret, not a placeholder

Anyone running Kimai via Docker should upgrade to 2.58.0 or later immediately and verify their APP_SECRET isn’t still set to the default string.

Rotating this secret invalidates existing sessions, so plan for a brief re-authentication window. Enabling two-factor authentication on all administrator accounts remains the most effective compensating control against this entire class of token-forgery attack.

This case underscores a recurring lesson in container security: defaults intended as “obviously insecure placeholders” often persist into production, especially in self-hosted deployments where operators assume the vendor has handled security-critical configuration.