{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/kimai/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kimai (\u003c 2.59.0)"],"_cs_severities":["high"],"_cs_tags":["kimai","api","2fa-bypass","vulnerability","web-application"],"_cs_type":"advisory","_cs_vendors":["Kimai"],"content_html":"\u003cp\u003eA critical authentication bypass vulnerability, identified as CVE-2026-52827, affects Kimai versions prior to 2.59.0, allowing attackers to circumvent Two-Factor Authentication (TOTP) for the REST API. This flaw enables an attacker who has compromised a user's password to obtain a \u003ccode\u003eKIMAI_SESSION\u003c/code\u003e cookie during the initial login phase, even before the TOTP step is completed. By replaying this cookie against any \u003ccode\u003e/api/*\u003c/code\u003e endpoint, the attacker gains full authenticated API access as the legitimate user without ever needing to provide the second authentication factor. This vulnerability effectively nullifies 2FA protection for Kimai's API, exposing affected instances to unauthorized data access and manipulation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker obtains a user's password for a Kimai instance through various means (e.g., phishing, credential stuffing, or password reuse).\u003c/li\u003e\n\u003cli\u003eThe attacker initiates a login attempt to the Kimai web UI (\u003ccode\u003e/en/auth/login\u003c/code\u003e) using the compromised credentials.\u003c/li\u003e\n\u003cli\u003eKimai's authentication process validates the provided password and, before prompting for the Two-Factor Authentication (TOTP) code, issues a \u003ccode\u003eKIMAI_SESSION\u003c/code\u003e cookie.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts this \u003ccode\u003eKIMAI_SESSION\u003c/code\u003e cookie from the HTTP response, prior to the TOTP verification step.\u003c/li\u003e\n\u003cli\u003eThe attacker then crafts subsequent HTTP requests to any \u003ccode\u003e/api/*\u003c/code\u003e endpoint, including the intercepted \u003ccode\u003eKIMAI_SESSION\u003c/code\u003e cookie in the request headers.\u003c/li\u003e\n\u003cli\u003eDue to a logical flaw in Kimai's API firewall and \u003ccode\u003eAPIVoter\u003c/code\u003e (specifically using \u003ccode\u003eIS_AUTHENTICATED\u003c/code\u003e instead of \u003ccode\u003eIS_AUTHENTICATED_REMEMBERED\u003c/code\u003e and not properly checking \u003ccode\u003eTwoFactorTokenInterface\u003c/code\u003e status), the API treats the session as fully authenticated.\u003c/li\u003e\n\u003cli\u003eThis grants the attacker complete, unauthorized access to the Kimai REST API, allowing them to perform any actions permitted to the compromised user, effectively bypassing the intended 2FA protection.\u003c/li\u003e\n\u003cli\u003eThe attacker can now exfiltrate sensitive data, manipulate time entries, or perform other malicious actions via the API.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability completely neutralizes the protection offered by Two-Factor Authentication for Kimai's REST API. If an attacker successfully compromises a user's password, they gain full authenticated API access, irrespective of whether 2FA is enabled for that account. This can lead to unauthorized access to sensitive user data, manipulation of time tracking entries, and other critical business functions managed via the API. The exploit requires only the compromised password and the \u003ccode\u003eKIMAI_SESSION\u003c/code\u003e cookie, making it a straightforward attack vector.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003ePatch Kimai installations immediately to version 2.59.0 or later to address CVE-2026-52827, which includes updated API firewall logic.\u003c/li\u003e\n\u003cli\u003eVerify that the \u003ccode\u003econfig/packages/security.yaml\u003c/code\u003e file in your Kimai instance correctly utilizes \u003ccode\u003eIS_AUTHENTICATED_REMEMBERED\u003c/code\u003e for API paths and that the \u003ccode\u003eAPIVoter\u003c/code\u003e checks for \u003ccode\u003eTwoFactorTokenInterface\u003c/code\u003e and \u003ccode\u003eIS_AUTHENTICATED_2FA_IN_PROGRESS\u003c/code\u003e status, as outlined in the solution section of the advisory.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-14T00:35:22Z","date_published":"2026-07-14T00:35:22Z","id":"https://feed.craftedsignal.io/briefs/2026-07-kimai-2fa-bypass/","summary":"A critical vulnerability, CVE-2026-52827, in Kimai versions prior to 2.59.0 allows an attacker who has compromised a user's password to bypass Two-Factor Authentication (TOTP) for the REST API by intercepting and replaying the `KIMAI_SESSION` cookie obtained after password verification but before TOTP completion, granting full authenticated API access.","title":"Kimai REST API Two-Factor Authentication Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-07-kimai-2fa-bypass/"},{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Kimai (Docker image)","composer/kimai/kimai (\u003c= 2.57.0)"],"_cs_severities":["critical"],"_cs_tags":["vulnerability","web-application","misconfiguration","account-takeover","docker"],"_cs_type":"advisory","_cs_vendors":["Kimai"],"content_html":"\u003cp\u003eA critical vulnerability (CVE-2026-52824) affects the official Kimai Docker image, enabling unauthenticated attackers to achieve full account takeover. The root cause is the Docker image shipping with a hardcoded \u003ccode\u003eAPP_SECRET=change_this_to_something_unique\u003c/code\u003e environment variable, which is a known secret. This \u003ccode\u003eAPP_SECRET\u003c/code\u003e is used by the underlying Symfony framework to HMAC-sign sensitive data such as the \u003ccode\u003eKIMAI_REMEMBER\u003c/code\u003e cookie, login links, and password reset URLs. If a Kimai instance is deployed via Docker without explicitly overriding this default \u003ccode\u003eAPP_SECRET\u003c/code\u003e, an attacker can leverage this known value to forge valid authentication tokens. This allows them to bypass authentication and log in as any user, including \u003ccode\u003esuper_admin\u003c/code\u003e, provided the attacker knows the username, can guess the sequential user ID, and the target account does not have 2FA enabled. The vulnerability affects Kimai versions up to and including 2.57.0.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eReconnaissance\u003c/strong\u003e: An unauthenticated attacker identifies an internet-exposed Kimai instance.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerability Identification\u003c/strong\u003e: The attacker determines that the Kimai instance is running the official Docker image with the default, known \u003ccode\u003eAPP_SECRET\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTarget Identification\u003c/strong\u003e: The attacker identifies a target username (e.g., \u003ccode\u003esuper_admin\u003c/code\u003e) and guesses the corresponding sequential user ID (often 1 for the initial admin account).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eToken Forgery\u003c/strong\u003e: Using the publicly known default \u003ccode\u003eAPP_SECRET\u003c/code\u003e (\u003ccode\u003echange_this_to_something_unique\u003c/code\u003e), the attacker crafts a valid HMAC-signed \u003ccode\u003eKIMAI_REMEMBER\u003c/code\u003e cookie or a login link URL for the target user ID.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAuthentication Bypass\u003c/strong\u003e: The attacker sends the forged cookie in an HTTP request to the Kimai instance or navigates directly to the forged login link.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAccount Takeover\u003c/strong\u003e: The vulnerable Kimai instance validates the forged cookie or login link using the default \u003ccode\u003eAPP_SECRET\u003c/code\u003e and grants the attacker authenticated access to the target user's account without requiring valid credentials.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePost-Exploitation\u003c/strong\u003e: The attacker gains full control over the compromised user's account, potentially performing further actions like privilege escalation, data exfiltration, or establishing additional persistence.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eAny Kimai instance deployed via its official Docker image without overriding the default \u003ccode\u003eAPP_SECRET\u003c/code\u003e is critically vulnerable to unauthenticated account takeover. An attacker can compromise \u003ccode\u003esuper_admin\u003c/code\u003e accounts, leading to full control over the Kimai application, its data, and potentially integrated systems. This can result in unauthorized access to sensitive project and user data, manipulation of timesheets, or disruption of business operations. The attacker only needs to know a username, guess a sequential user ID, and the account must not have active two-factor authentication. This vulnerability affects a broad range of organizations using Kimai for time tracking and project management.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ePatch CVE-2026-52824\u003c/strong\u003e: Immediately update all Kimai instances to a patched version (newer than 2.57.0), which includes updates to \u003ccode\u003eentrypoint.sh\u003c/code\u003e to generate a random \u003ccode\u003eAPP_SECRET\u003c/code\u003e and removes the default from the Dockerfile.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eConfigure APP_SECRET\u003c/strong\u003e: For all Kimai Docker deployments, explicitly set a unique and strong \u003ccode\u003eAPP_SECRET\u003c/code\u003e environment variable using Docker secrets or Kubernetes secrets management. Do not rely on the default value.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReview Documentation\u003c/strong\u003e: Refer to the updated Kimai security documentation (linked in references) for best practices regarding \u003ccode\u003eAPP_SECRET\u003c/code\u003e configuration.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEnable Multi-Factor Authentication\u003c/strong\u003e: For critical accounts, enable 2FA where available to add an additional layer of security, as the attack is mitigated if 2FA is active.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-14T00:08:54Z","date_published":"2026-07-14T00:08:54Z","id":"https://feed.craftedsignal.io/briefs/2026-07-kimai-docker-app-secret/","summary":"A critical vulnerability, CVE-2026-52824, in the official Kimai Docker image allows unauthenticated attackers to forge authentication tokens and achieve account takeover, including super_admin accounts, due to the image shipping with a default, publicly known APP_SECRET environment variable used by Symfony to HMAC-sign session cookies and login links.","title":"Kimai Docker Image Default APP_SECRET Allows Account Takeover (CVE-2026-52824)","url":"https://feed.craftedsignal.io/briefs/2026-07-kimai-docker-app-secret/"}],"language":"en","title":"CraftedSignal Threat Feed - Kimai","version":"https://jsonfeed.org/version/1.1"}