Kimai Docker Image: Hardcoded Default APP_SECRET Enables Cookie Forgery and Account Takeover
Official Kimai Docker images ship with a publicly-known default `APP_SECRET`, allowing unauthenticated attackers to forge Symfony HMAC-signed cookies and authentication tokens to assume any account. This affects all unpatched deployments that did not manually override the sentinel value.
CVE References
Affected
Vulnerability Description
Kimai's official Docker image contains a hardcoded APP_SECRET=change_this_to_something_unique environment variable that serves as Symfony's kernel.secret. This secret is used to HMAC-sign critical security tokens including remember-me cookies, login links, password reset URLs, and CSRF tokens. The vulnerability stems from two failures: (1) shipping a publicly-known sentinel value in production-ready artifacts, and (2) absence of runtime validation or auto-generation logic in the entrypoint script or application bootstrap to detect and refuse execution with the default secret. This is a cryptographic-failure (CWE-327/CWE-321) combined with insecure-defaults (CWE-1004).
Proof-of-Concept Significance
The removed PoC likely demonstrated HMAC-based cookie forging or LoginLink signature generation using the hardcoded secret. The attack surface is exceptionally reliable because: (1) user IDs are sequential integers starting at 1, making the super_admin account highly predictable; (2) the secret is deterministic and publicly documented in the Dockerfile; (3) Symfony's signing mechanisms are well-known and reproducible. The only precondition is network reachability to a Kimai instance deployed without explicit APP_SECRET override—a likely scenario for organizations unaware of this requirement or following minimal deployment documentation.
Detection Guidance
Configuration Audit: Search deployed Kimai Docker containers for ENV APP_SECRET=change_this_to_something_unique in running processes (docker inspect, ps aux) or check .env files for the sentinel value or absence of a custom secret. Log Indicators: Authentication logs showing impossible or rapid successive logins from different user accounts, or LoginLink redemptions without corresponding requests. Runtime Signals: Monitor for HTTP requests containing signed tokens or cookies that validate correctly despite no legitimate user session—this indicates token forgery. Defensive Baseline: Establish a configuration audit to verify all Kimai instances have a cryptographically-random, unique APP_SECRET >32 characters.
Mitigation Steps
Immediate Actions: (1) Override APP_SECRET with a unique, cryptographically-random value (minimum 32 characters) in all Docker deployments via environment variable, .env file, or orchestration secrets management. (2) Audit authentication logs for anomalous login patterns. (3) Force session termination and password resets for all accounts. (4) Review access logs for forged LoginLink usage (password reset requests from unexpected IPs). Patching: Upgrade to patched Kimai versions that include startup-time validation refusing execution with the default secret. Preventive Configuration: Modify Docker build pipelines to reject deployments where APP_SECRET matches known sentinel values; implement pre-deployment configuration scanning.
Risk Assessment
This vulnerability has very high likelihood of exploitation in the wild because: (1) it affects all unpatched Docker deployments using default configurations; (2) it requires only network access and knowledge of the hardcoded secret (publicly available); (3) exploitation is silent, leaving minimal forensic artifacts; (4) the impact is immediate account takeover including administrative accounts. Threat actors actively targeting SaaS/hosting environments will prioritize scanning for this flaw. Organizations running Kimai without explicit secret configuration should assume compromise until patched and audited. The 2026 CVE date suggests this is a recently-disclosed historical issue or proactive researcher disclosure.
Sources