# CVE-2026-52824: Kimai Docker Image Hardcoded APP_SECRET Enables Account Takeover

> The official Kimai Docker image shipped with a hardcoded default APP_SECRET ("change_this_to_something_unique") that the container entrypoint never validated or replaced. Because APP_SECRET is used as Symfony's kernel.secret to HMAC-sign remember-me cookies, login-link signatures, password-reset URLs, and CSRF tokens, any unauthenticated network attacker who knows a target's username and sequential user ID can forge valid authentication material and take over accounts, including super_admin, on any Docker deployment running the unmodified default.

- **Published:** 2026-07-20T00:00:00Z
- **Last reviewed:** 2026-07-20T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1556
- **Card image:** https://intel.threadlinqs.com/og/threat/threat-intel-kimai-default-app-secret-tl-2026-1556.webp?v=ac568bc0 (Threadlinqs threat intel: CVE-2026-52824 Kimai Default Secret: Detection & IOCs (TL-2026-1556) — High severity, 15 IOCs, 9 detection rules.)
- **ID:** TL-2026-1556
- **Severity:** HIGH (CVSS 7.4)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 (1 shown free below) · **IOCs:** 15
- **CVEs:** CVE-2026-52824

## Description

CVE-2026-52824 is an insecure-default (CWE-1188) vulnerability in the official kimai/kimai Docker image. Kimai is a PHP/Symfony open-source time-tracking application. The Docker image's Dockerfile and entrypoint.sh set APP_SECRET to the literal placeholder string "change_this_to_something_unique" and, prior to the fix, never enforced that operators override it before the application became reachable. APP_SECRET backs Symfony's kernel.secret, which is the cryptographic key used to sign and verify several security-critical, HMAC-protected tokens throughout the application: the KIMAI_REMEMBER remember-me cookie, LoginLink signed URLs (used for password reset and one-time login links), and CSRF tokens.

Because the default value is publicly documented in Kimai's own Docker Hub instructions, changelogs, and countless public docker-compose.yml examples, it functions as a de facto master key shared across every Kimai Docker deployment that was never explicitly reconfigured. An unauthenticated attacker who reaches a vulnerable instance over the network and knows (or discovers, e.g. via the related username-enumeration timing side channel GHSA-jrc6-fmhw-fpq2) a target's username and numeric user ID can independently compute valid HMAC signatures for that user's remember-me cookie or LoginLink, granting a fully authenticated session without ever supplying a password. Because Kimai assigns user IDs as small sequential integers, the platform's own super_admin account is trivially guessable, making full administrative takeover the realistic worst case. A companion advisory, GHSA-m492-gv72-xvxj (CWE-640, Weak Password Recovery Mechanism), compounds the impact: the LoginLink/password-reset signature historically covered only the user ID and not the current password hash, so a forged reset link remains valid even after the victim changes their password, and low signature entropy made the links themselves easier to guess independent of secret exposure.

The vulnerability was reported by security researcher AzureADTrent and coordinated with Kimai maintainer Kevin Papst. A working proof-of-concept demonstrating cookie/LoginLink forgery was initially published alongside the advisory and later withdrawn by the researcher to limit misuse, which the vendor and downstream reporting both treat as confirmation of practical exploitability rather than a theoretical weakness. The fix, shipped in Kimai 2.58.0, rewrites the Docker entrypoint to remove the hardcoded default entirely: if no APP_SECRET is supplied, the entrypoint now generates a cryptographically random 32-byte secret via bin2hex(random_bytes(32)), persists it to /opt/kimai/var/data/.appsecret so it survives container restarts, and writes it into /opt/kimai/.env.local. The fix also increases LoginLink signature entropy per GHSA-m492-gv72-xvxj. Any pre-2.58.0 Docker deployment that never set a custom APP_SECRET remains fully exploitable until upgraded or reconfigured, and instances that were exposed while vulnerable should be treated as potentially compromised: secrets must be rotated, all active sessions invalidated, and administrator account activity audited, since simply upgrading does not retroactively invalidate tokens forged with the old, known secret.

## MITRE ATT&CK

- T1595 Active Scanning
- T1592 Gather Victim Host Information
- T1588 Obtain Capabilities
- T1190 Exploit Public-Facing Application
- T1078 Valid Accounts
- T1552 Unsecured Credentials
- T1606 Forge Web Credentials
- T1539 Steal Web Session Cookie
- T1087 Account Discovery
- T1078 Valid Accounts
- T1078 Valid Accounts
- T1550 Use Alternate Authentication Material
- T1078 Valid Accounts
- T1589 Gather Victim Identity Information

## Free detection (Splunk SPL, Microsoft KQL, Sigma)

**Kimai Container Running With Default Hardcoded APP_SECRET (CVE-2026-52824)** (`TL-2026-1556-SPL-001`)

Detects Docker/container inventory or environment-inspection telemetry showing a Kimai container running with the publicly documented placeholder APP_SECRET=change_this_to_something_unique, confirming the instance is exploitable for remember-me cookie, LoginLink, and CSRF token forgery.

- **Languages:** Splunk SPL, Microsoft KQL, Sigma
- **ATT&CK:** T1552.001, T1588
- **Data sources:** docker_inspect_logs, cmdb_container_inventory
- **Severity:** critical
- **Confidence:** high

### Splunk SPL

```spl
index=containers sourcetype="docker:inspect" OR sourcetype="cmdb:container_env"
  (image="*kimai*" OR container_name="*kimai*")
  env="APP_SECRET=change_this_to_something_unique"
| eval risk="CVE-2026-52824: hardcoded APP_SECRET exposed"
| table _time, host, container_name, image, env, risk
| sort -_time
```

### Microsoft KQL

```kql
ContainerInventory
| where TimeGenerated > ago(24h)
| where Image has "kimai"
| where EnvironmentVariables has "APP_SECRET=change_this_to_something_unique"
| project TimeGenerated, Computer, ContainerName, Image, EnvironmentVariables
| extend Risk = "CVE-2026-52824: hardcoded APP_SECRET exposed"
```

### Sigma

```yaml
title: Kimai Default APP_SECRET Container Environment Exposure
id: 8f3e1c2a-1b4a-4e7c-9f21-cb1556aa0001
status: experimental
description: Detects a Kimai Docker container running with the publicly documented hardcoded default APP_SECRET (CVE-2026-52824), which enables cookie/LoginLink/CSRF forgery.
references:
    - https://github.com/kimai/kimai/security/advisories/GHSA-jr9p-4h4j-6c58
    - https://advisories.gitlab.com/composer/kimai/kimai/CVE-2026-52824/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-07-20
tags:
    - cve.2026.52824
    - attack.credential_access
    - attack.t1552.001
logsource:
    category: container_inspect
    product: docker
detection:
    selection:
        Image|contains: 'kimai'
        EnvironmentVariables|contains: 'APP_SECRET=change_this_to_something_unique'
    condition: selection
falsepositives:
    - Non-production/sandbox Kimai instances intentionally left on defaults with no network exposure
level: high
```

**Known false positives:**

- Isolated lab/sandbox Kimai containers with no network reachability that were never intended to be production-hardened

**Tuning notes:** Restrict scope to container inventory/CSPM sources that actually capture environment variables (avoid scanning secrets in cleartext logs beyond this narrow detection); extend the string match to catch partial/obfuscated variants of the placeholder if operators only masked part of it.

### 8 more detection rules (Splunk SPL, Microsoft KQL, Sigma), unlock with TL Creds

- Kimai Public-Facing Exploit Attempt — Unauthenticated Forged Token Submission (locked: unlock with TL Creds)
- Kimai Privileged Session Creation Without Corresponding Interactive Login Event (locked: unlock with TL Creds)
- Kimai Password-Reset Link Reused After Account Password Change (GHSA-m492-gv72-xvxj) (locked: unlock with TL Creds)
- X-AUTH-USER/X-AUTH-TOKEN Timing-Based Username Enumeration Preceding Token Forgery (GHSA-jrc6-fmhw-fpq2) (locked: unlock with TL Creds)
- Kimai LoginLink/Password-Reset Requests Enumerating Sequential Numeric User IDs (Sigma) (locked: unlock with TL Creds)
- Kimai Post-Fix APP_SECRET File Tampering or Unauthorized Read (Persistence/Lateral Movement) (locked: unlock with TL Creds)
- Kimai LoginLink/Password-Reset Enumeration of Low Sequential User IDs (locked: unlock with TL Creds)
- Kimai [indicator] Cookie Authentication From Previously Unseen Source Without Password Login (locked: unlock with TL Creds)

Sign up free to unlock the detection rules: https://threadlinqs.com/?modal=signup

## Sources

- [Cyber Security News: Kimai Docker Vulnerability](https://cybersecuritynews.com/kimai-docker-flaw/)
- [CVE-2026-52824: Kimai Default APP_SECRET in Docker Image Enables Cookie Forgery and Account Takeover](https://advisories.gitlab.com/composer/kimai/kimai/CVE-2026-52824/)
- [GHSA-jr9p-4h4j-6c58: Kimai Docker default APP_SECRET](https://github.com/kimai/kimai/security/advisories/GHSA-jr9p-4h4j-6c58)
- [Kimai Docker Vulnerability Exposes Default APP_SECRET, Enabling Account Takeover](https://gbhackers.com/kimai-docker-vulnerability-exposes-default-app_secret/)
- [GHSA-m492-gv72-xvxj: Kimai Password Reset Link Remains Valid After Password Change](https://advisories.gitlab.com/composer/kimai/kimai/GHSA-m492-gv72-xvxj/)
- [GHSA-jrc6-fmhw-fpq2: Kimai Username Enumeration via Timing on X-AUTH-USER](https://advisories.gitlab.com/composer/kimai/kimai/GHSA-jrc6-fmhw-fpq2/)
- [Kimai Official Security Advisory: GHSA-jr9p-4h4j-6c58](https://www.kimai.org/en/security/ghsa-jr9p-4h4j-6c58)
- [NVD entry for CVE-2026-52824 (reserved, pending publication)](https://nvd.nist.gov/vuln/detail/CVE-2026-52824)

## Full data

The other 8 detection rules (Splunk SPL / Microsoft KQL / Sigma) unlock with TL Creds; a free account includes daily creds: https://threadlinqs.com/?modal=signup
Indicator values unlock with TL Creds, at a lower price on Red and Purple; AI agents can query rules and IOCs through the Threadlinqs MCP server (Purple): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1556