External risk intelligence

Kimai Docker Image Secret Leak Allows Account Takeover

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-52824

Kimai is a time-tracking application designed as a web-based service. Such applications are commonly deployed as internet-facing web interfaces accessible to users for remote time entry and management, making public network reachability a standard deployment pattern.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory addresses a vulnerability in the Kimai time-tracking application, specifically within its official Docker image. The issue stems from a predictable secret key used for authentication, which, under certain conditions, could allow an unauthenticated attacker to gain unauthorized access to user accounts. The primary concern is confirming if this specific application is in use and if it has been deployed without overriding the default secret.

  • Predictable key allows unauthorized account access.
  • Confirm if Kimai is used; assess exposure.
  • Ensure application deployments are secured.

Attack Path

How an attacker could exploit the issue

An attacker could gain unauthorized access to a Kimai account by exploiting a weakness in how the application handles secrets. If an administrator has not properly configured a unique secret for the application, an attacker who knows a username and the associated account ID, and can guess that the account lacks two-factor authentication, can forge authentication tokens. This allows them to bypass the password and take control of the account.

  • Unauthenticated access to a misconfigured deployment.
  • Forges authentication artifacts to impersonate a user.
  • Risks unauthorized account access and data manipulation.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, an unauthenticated attacker could forge authentication artifacts to access user accounts without a password, provided they know a username, can guess the account ID, and the targeted account lacks two-factor authentication.

  • User account access.
  • Forging authentication artifacts.
  • Unauthorized account access.

Operational Fix

Recommended remediation, mitigation, and detection steps

Owners of the Kimai application, likely within infrastructure or platform teams, must first confirm where Kimai is deployed and if it's internet-reachable. This is critical because the vulnerability allows unauthenticated attackers to forge authentication artifacts if the default `APP_SECRET` is not overridden and they know a username and account ID, and can guess the account ID for an account without 2FA. Vendor coordination may be necessary for patching or remediating the secret management.

  • Application owners and platform teams.
  • Verify `APP_SECRET` override and internet reachability.
  • Plan remediation based on verified risk and exposure.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is Kimai and how is it typically used?

Kimai is an open-source web application designed for time tracking and attendance management. Organizations use it to monitor billable hours, project timelines, and employee productivity. It is commonly deployed as a containerized web service to provide remote teams with a central interface for logging their daily work activities.

What does CVE-2026-52824 mean for software security?

This vulnerability is classified as CWE-1188, which involves the insecure use of a default or hardcoded secret. In this case, the application's Docker image includes a public default value for the secret key used to sign authentication tokens. Because the system does not enforce a unique secret upon startup, an attacker can use this known value to forge authentication artifacts and impersonate legitimate users.

How does an attacker trigger this vulnerability?

An attacker needs to interact with a Kimai deployment that still uses the default, unconfigured secret key. The bug is not triggered if the administrator has overridden the default value with a unique, custom secret. To succeed, the attacker must also possess specific knowledge about a target account, including a username and its associated ID, and must target an account where two-factor authentication is disabled.

Why should I care if my Kimai instance is internet-facing?

According to Halo Surface Signal, Kimai is frequently deployed as a web-based service accessible over the public internet to facilitate remote time entry. This connectivity increases the risk, as it allows unauthenticated attackers to reach the application and attempt to forge authentication artifacts remotely. Instances that are strictly internal may have a lower immediate risk, but all deployments should be checked.

How can I address this Kimai security issue?

The most effective fix is to update your Kimai deployment to version 2.58.0 or later. This updated version changes how the entrypoint script functions, automatically generating and persisting a secure, unique secret when no custom value is provided. If you cannot update immediately, ensure you have manually overridden the default APP_SECRET with a strong, unique, and private value.

References