Critical Kimai Flaw Lets Attackers Forge Cookies and Take Over Accounts

A critical Kimai vulnerability can let an unauthenticated attacker forge trusted authentication data and take over user accounts, including a super administrator account. The attack is possible when a self-hosted Kimai installation retains the application’s publicly known default secret.

The vulnerability is tracked as CVE-2026-52824 and GHSA-jr9p-4h4j-6c58. According to the official Kimai security advisory, versions 2.57.0 and earlier are affected, while version 2.58.0 contains the fix.

Administrators should upgrade to the latest available Kimai release and confirm that the deployment uses a unique, randomly generated APP_SECRET. Updating the application without correcting an old deployment configuration may leave questions about whether the exposed secret was fully replaced.

Who Is Affected by CVE-2026-52824?

The flaw was discovered in the official Kimai Docker image, which included change_this_to_something_unique as the default value for APP_SECRET. The Docker startup process did not require administrators to change that value.

However, the scope is wider than Docker alone. Kimai’s bare-metal default configuration used the same placeholder, so any self-hosted installation that never replaced it may be vulnerable regardless of its deployment method.

The GitHub advisory for CVE-2026-52824 assigns the issue a critical CVSS 4.0 score of 9.1. It lists network access, no required privileges and no user interaction as key characteristics of the vulnerability.

Deployment	Potentially affected?	Required action
Official Docker image, Kimai 2.57.0 or earlier, default secret retained	Yes	Upgrade and replace the secret immediately
Bare-metal installation using the placeholder secret	Yes	Upgrade and replace the secret immediately
Self-hosted installation with a strong unique secret	Not exposed through the known default secret	Upgrade to receive all related hardening
Kimai 2.58.0 or later installed with secure configuration	Fixed	Keep the application updated
Kimai Cloud	No	No action required for this vulnerability

Why the Default APP_SECRET Is Dangerous

Kimai is built on Symfony and uses APP_SECRET as the framework’s kernel secret. The application relies on this value when signing several security-sensitive tokens.

A digital signature allows Kimai to determine whether a cookie, login link or other value was created by the application and has not been modified. That protection fails when an attacker already knows the signing secret.

Because the placeholder was published in the image and source configuration, it was not secret. Separate installations that retained the value effectively shared the same cryptographic key.

• KIMAI_REMEMBER remember-me cookies
• Login-link signatures
• Password-reset URLs
• Cross-site request forgery tokens

How an Account Takeover Could Happen

An attacker who can reach a vulnerable Kimai site over the network may be able to create authentication data that the application accepts as genuine. No valid password or existing authenticated session is required.

To target a particular account through the documented takeover path, the attacker must know its username and determine the corresponding numeric user ID. The target account must also lack active two-factor authentication.

Kimai user IDs are sequential and begin at 1. The first super administrator account is commonly assigned ID 1, and user IDs can appear in some application URLs and API responses. These details can make privileged accounts easier to identify.

Attack requirement	Details
Network access	The attacker must be able to reach the Kimai application
Known default secret	The installation must still use the public placeholder value
Target username	The attacker must know a valid Kimai username
Correct user ID	The numeric ID must be known or successfully guessed
No active 2FA	The targeted account must not be protected by two-factor authentication

Does Two-Factor Authentication Stop the Attack?

Kimai says accounts with active two-factor authentication are not affected by this specific takeover path. This makes 2FA an important additional control for administrator and other privileged accounts.

Two-factor authentication does not remove the vulnerable shared secret or protect every function that relies on it. Administrators must still upgrade and rotate APP_SECRET, even if all privileged accounts use 2FA.

Password changes alone do not fix the vulnerability because the weakness is in the application’s signing key rather than a user’s password. Password resets should be considered when logs or account activity indicate a possible compromise.

What Changed in Kimai 2.58.0?

Kimai 2.58.0 changes the initialization process so a new installation no longer depends on a shared placeholder. If an administrator does not provide a secret, the entrypoint generates a random value using bin2hex(random_bytes(32)).

The generated secret is stored persistently at /opt/kimai/var/data/.appsecret. The entrypoint then writes the active configuration to /opt/kimai/.env.local. The hard-coded default was removed from the Dockerfile.

The patch details are documented in the GitHub security advisory. Login links also received additional entropy as a defense-in-depth improvement.

• Removed the fixed default secret from the Docker image
• Added automatic generation of a cryptographically random secret
• Stored the generated value in persistent application data
• Created a local environment configuration with the active secret
• Updated documentation to require a unique secret
• Added more entropy to login links

Upgrade to the Latest Kimai Version

Version 2.58.0 is the minimum release containing the fix. The Kimai release history shows that newer releases have since become available.

At the time of writing, Kimai’s update documentation identifies version 2.62.0 as the latest release. Administrators should normally move to the latest supported version rather than stopping at the minimum fixed build.

Before upgrading, create and test a database backup. Kimai’s official update instructions also recommend checking the upgrade documentation for manual changes that may apply to the installed version or plugins.

How to Determine Whether an Installation Is Exposed

Administrators should inspect the effective application configuration, Docker Compose files, orchestration secrets and environment-management platform used by the deployment. The goal is to determine which value the running application actually receives as APP_SECRET.

Do not copy the active secret into tickets, chat systems, screenshots or diagnostic logs. Treat it as a credential. Access to production environment variables should be limited to authorized administrators.

An installation should be considered exposed if its effective secret equals change_this_to_something_unique. Systems upgraded from older versions also require attention because an existing environment variable may override the safer behavior introduced by the new image.

1. Identify every self-hosted Kimai instance.
2. Record its application version and deployment method.
3. Inspect the effective APP_SECRET without disclosing it.
4. Check whether the public placeholder is still configured.
5. Upgrade any release at or below version 2.57.0.
6. Replace the secret with a unique random value.
7. Restart or recreate the application containers.
8. Confirm that the new configuration remains after another restart.

Rotating APP_SECRET Requires Care

Changing APP_SECRET invalidates values signed with the previous key. Users may be signed out, and existing remember-me cookies, login links, password-reset links and CSRF tokens may stop working.

This is an expected security effect. Administrators should schedule the change, notify users about required sign-ins and avoid switching back to the exposed value if an old token fails.

Each Kimai installation should receive its own randomly generated secret. Reusing one value across development, staging and production would increase the impact if that secret were later disclosed.

Incident Response for an Exposed Installation

An internet-accessible Kimai instance that used the default secret should be treated as potentially exposed. The advisory confirms that remote account takeover was possible, but it does not state that every vulnerable deployment was compromised.

Teams should review application, reverse-proxy and identity logs for unusual sessions or administrative actions. Useful evidence can include unexpected source addresses, changes to privileged users, new API tokens and activity performed outside normal working hours.

The Kimai remediation guidance says existing installations using the placeholder should set a unique random secret immediately. Kimai Cloud customers do not need to rotate a secret for this issue because the hosted service already uses strong, random values.

• Rotate APP_SECRET and restart the application.
• Invalidate active sessions and remember-me cookies where possible.
• Review super administrator and administrator accounts.
• Remove unknown accounts, API tokens and integrations.
• Enable 2FA for every privileged account.
• Review recent password-reset and login-link activity.
• Check time records, customers, projects and invoices for unauthorized changes.
• Preserve relevant logs before normal retention removes them.
• Reset user passwords if evidence suggests account access.

Recommended Remediation Priorities

Priority	Action	Reason
Immediate	Restrict public access if the default secret is still active	Reduces exposure while remediation is underway
Immediate	Upgrade to the latest available Kimai version	Installs the fixed initialization process and related hardening
Immediate	Set a unique high-entropy APP_SECRET	Prevents signatures from being created with the public key
High	Invalidate sessions and review privileged accounts	Limits continued access after possible account takeover
High	Enable 2FA for administrators	Blocks the documented takeover path against protected accounts
High	Review logs and sensitive data changes	Helps identify signs of prior exploitation
Ongoing	Follow the Kimai update process	Keeps the deployment on supported security releases

No Public Exploitation Confirmed

The original report included a proof of concept, but it was removed from the advisory to reduce misuse. The public advisory does not report confirmed exploitation in real-world attacks.

Absence of confirmed exploitation should not delay remediation. The default secret is public, the application can be reached remotely in many deployments and successful exploitation can provide access to sensitive business and time-tracking information.

AzureADTrent reported the vulnerability, and Kimai maintainer Kevin Papst developed the correction. Administrators can review the official Kimai releases to select the newest supported build and should not deploy any version earlier than 2.58.0.

FAQ