Kimai, Username Enumeration via Timing Oracle, CVE-2024-XXXX (Medium)

By /

Listen to this Post

The vulnerability exists in the legacy API authentication mechanism used by Kimai versions prior to 2.x. The `TokenAuthenticator` class handles authentication via the `X-AUTH-USER` and `X-AUTH-TOKEN` headers. The flaw is a timing side-channel that allows an unauthenticated attacker to enumerate valid usernames.

The vulnerable code in `src/API/Authentication/TokenAuthenticator.php` follows this logic:

  1. It calls `loadUserByIdentifier()` to fetch a user object based on the provided username.
  2. If a user is found, it proceeds to verify the password (using the Argon2id hasher).
  3. If the username does not exist, it skips the password hashing step entirely and immediately returns a 403 error.
    Because the password hashing operation is computationally expensive, the server’s response time differs significantly between a valid and an invalid username. The observed difference is approximately 25 milliseconds. The response body and HTTP status code are identical in both cases ({"message":"Invalid credentials"}, HTTP 403), so the only observable difference is the response latency.
    The `/api/` firewall does not implement any login throttling, allowing unlimited probing attempts. Furthermore, the legacy `X-AUTH-USER` and `X-AUTH-TOKEN` headers are still accepted by default in version 2.x, and no prior authentication, API token, or session cookie is required to trigger this behavior.
    The proof of concept is a Python script that:

– Sends multiple requests with a candidate username and a dummy token.
– Measures the response time for each request.
– Compares the median response time to a baseline established with a guaranteed non-existent username.
– Flags any username whose median response time exceeds the baseline by a configurable threshold (e.g., 15 ms) as valid.
The fix involves modifying `TokenAuthenticator::authenticate()` to always execute the password hasher, even when the user is not found. This is done by generating a dummy hash (using the same algorithm and parameters as real user hashes) and passing it to the `verify()` method when the user is not found. This ensures that the response time is constant regardless of username validity.
The practical impact is limited because the timing difference is small and network jitter can obscure it. Additionally, the vulnerable authentication method has been deprecated since April 2024 and is scheduled for removal after Q2 2026.

DailyCVE Form:

Platform: `Kimai`
Version: `2.x`
Vulnerability: `Username enumeration`
Severity: `Medium`
Date: `2026-04-17`

Prediction: `Expected patch: Q2 2026`

What Undercode Say:

This vulnerability highlights the importance of constant-time operations in authentication logic. While the impact is low due to network variability, the existence of a timing oracle is a design flaw that can be exploited in controlled environments. The recommended fix—using a dummy hash—is a standard mitigation for such side-channel attacks.

Analytics:

  • Attack Complexity: Low (requires network access, but no authentication)
  • Exploitability: High (unbounded probes, no rate limiting)
  • Impact: Limited (username enumeration only, not password brute-forcing)

Bash Commands and Code:

Clone the vulnerable version (example)
git clone https://github.com/kimai/kimai.git
cd kimai
git checkout 2.x
Run the proof-of-concept script
python3 timing_oracle.py -u https://target.kimai.com -l usernames.txt -n 15

Exploit:

The exploit is a timing attack that requires:

1. A list of candidate usernames.

  1. A baseline measurement using a guaranteed non-existent username.
  2. Multiple samples to account for network jitter (e.g., 15 requests per username).
  3. A threshold to distinguish valid from invalid usernames (e.g., 15 ms).

Protection from this CVE:

  • Apply the official patch that introduces the dummy hash verification.
  • Upgrade to a version where the legacy API authentication is removed (planned for after Q2 2026).
  • Implement login throttling for the `/api/` firewall.
  • Disable the legacy X-AUTH-USER/X-AUTH-TOKEN headers if not required.
  • Use a Web Application Firewall (WAF) to detect and block timing-based probing attempts.

Impact:

  • Confidentiality: Low (only username existence is revealed).
  • Integrity: None.
  • Availability: None.
  • Attack Vector: Network.
  • Privileges Required: None.
  • User Interaction: None.
  • CVSS Base Score: 5.3 (Medium) – AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top