CVE-2026-80199
Executive Summary
CVE-2026-80199 is a timing oracle vulnerability in Kimai, an open-source time-tracking application, affecting all versions prior to 2.54.0. The flaw exists within the TokenAuthenticator component, where the authentication mechanism leaks information about the existence of user accounts through measurable response-time differences when unauthenticated requests are submitted with an X-AUTH-USER header. Attackers can exploit this to enumerate valid usernames remotely without authentication, and because no login throttling protection is in place, enumeration can be performed in bulk. While the confidentiality impact is limited to username disclosure (CVSS 3.7), this information serves as a critical reconnaissance primitive for targeted password-spraying or credential-stuffing campaigns against the affected application.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability resides in the authentication workflow of Kimai versions prior to 2.54.0, specifically within the TokenAuthenticator class. The mechanism is a classic timing-based side-channel or "timing oracle" vulnerability classified under CWE-208 (Observable Timing Discrepancy).
Vulnerability Mechanism: When an unauthenticated HTTP request is made to the application with an X-AUTH-USER header specifying a username, the TokenAuthenticator processes the request. The key implementation flaw is that the password hasher execution is conditional on the user existing in the system. For valid usernames, the authentication flow proceeds to invoke the password hashing function to verify the provided credentials; for invalid usernames, the hasher is never invoked because the user lookup fails. Because password hashing operations (e.g., bcrypt, Argon2, PBKDF2) are computationally expensive and deliberately slow, requests targeting valid usernames take measurably longer to process than those targeting non-existent accounts. This timing differential creates an observable oracle that can be exploited to determine whether a given username is valid.
Attack Surface: The attack surface is the public-facing HTTP interface of the Kimai application. The exploitation vector is entirely remote (AV:N) and requires no authentication (PR:N) and no user interaction (UI:N). An attacker only needs the ability to send HTTP requests to the application and measure response times with sufficient instrumentation. The attack complexity is rated High (AC:H) in the CVSS scoring, reflecting the requirement for precise timing measurements, which can be noisy over the network and may require multiple samples per username with statistical analysis (e.g., median or mean comparison against baseline invalid-username timings).
Conditional Logic Flaw: The conditional execution of the password hasher is a direct violation of secure coding practices. A constant-time or constant-work authentication path should execute the same operations regardless of whether the user exists, typically by hashing a dummy value when the user is not found. The failure to do so introduces the observable timing discrepancy.
No Throttling Protection: The NVD description explicitly states "with no login throttling protection," meaning an attacker can send a large volume of timing probes without being rate-limited, account-locked, or IP-blocked. This materially increases the practical viability of the enumeration attack, as large sample sizes can be collected to overcome network jitter and noise.
Data Available for Exploitation: The attacker obtains a binary outcome per queried username: valid or invalid. This is the definition of a username enumeration vulnerability. While the direct confidentiality impact is limited to the disclosure of account names, the resulting username list is high-value intelligence for downstream attacks.
Exploitation Scenarios
The attack chain for CVE-2026-80199 proceeds in four stages. Since no public PoC or exploit code exists at the time of this report, the attack chain is inferred from the vulnerability class (timing oracle / username enumeration).
Stage 1: Reconnaissance / Target Identification
The attacker identifies Kimai instances exposed to the internet. This can be accomplished via Shodan queries such as http.title:"Kimai" or http.html:"Kimai" to locate login portals. Alternatively, the attacker may footprint the application via its distinctive login page, favicon hash, or HTTP response headers. Target identification includes confirming the application version to verify it is below 2.54.0 (e.g., via a version disclosure in the login page footer or changelog endpoints), though the timing oracle itself can be confirmed regardless of exact version.
Stage 2: Triggering the Flaw
The attacker constructs HTTP requests to the application's authentication endpoint, each bearing an X-AUTH-USER header with a candidate username. The request is sent without valid credentials or with a deliberately bogus password. The attacker measures the server's response time for each request. The attack is performed programmatically: a script iterates over a candidate username list (e.g., derived from common employee naming conventions, corporate email patterns, or leaked credential corpora).
Stage 3: Payload / Execution Method (Vulnerability-Class Level)
At the vulnerability-class level, this is a timing-based oracle attack. The attacker sends multiple requests per candidate username (typically 10–50 samples) and records round-trip times. Statistical analysis (median, trimmed mean, or interquartile range) is applied to filter outliers from network jitter. For each username, the measured response time is compared against the baseline timing of known-invalid usernames. A statistically significant elevation indicates the username is valid, because the application executed the expensive password hashing routine for that account before (hypothetically) rejecting the wrong password. No payload in the traditional sense is required — the malicious input is the probe request itself, and the "signal" is derived from server latency.
Stage 4: Post-Exploitation Impact
The attacker compiles a list of valid usernames. This list is then leveraged for targeted credential attacks:
- Password Spraying: Attackers attempt a small set of common passwords (e.g., seasonal passwords, company name + year) across all enumerated accounts, relying on the absence of account lockout or throttling.
- Credential Stuffing: If the attacker has access to breached credential corpora from other platforms, they can match the enumerated usernames against known password pairs.
- Phishing: Valid usernames enable highly targeted phishing that appears internally legitimate.
- Social Engineering: Username enumeration is often the first stage of broader business email compromise (BEC) campaigns.
The practical risk is elevated because the same absent login-throttling mechanism that enables enumeration also provides no defense-in-depth against the subsequent credential attacks.
Given there is no public PoC and no exploit code, the exploitation scenarios above represent the plausible attacker workflow derived from the vulnerability description. The attack is fully remote and unauthenticated, and the only requirement is network access to the Kimai instance.
Impact Assessment
CVSS Breakdown Reference: The CVSS base score is 3.7 (Low) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N.
- Attack Vector: Network (AV:N): The vulnerability is exploitable remotely over the network.
- Attack Complexity: High (AC:H): Successful exploitation requires an attacker to overcome network timing noise with sufficient sampling and statistical analysis. Success is not deterministic in a single probe.
- Privileges Required: None (PR:N): Pre-authentication exploitation.
- User Interaction: None (UI:N): No victim interaction is required.
- Confidentiality Impact: Low (C:L): The vulnerability discloses confirmations of valid usernames, which is low-sensitivity information on its own.
- Integrity & Availability Impact: None (I:N/A:N): The flaw itself does not allow data modification or denial of service.
Business Impact: The direct impact is account enumeration. In an enterprise context, the disclosure of valid usernames may feed subsequent targeted attacks, raising the overall risk posture of the organization. The absence of login throttling compounds this, allowing enumeration at scale and enabling brute-force credential attacks to proceed unimpeded.
Affected Systems: Any self-hosted or managed deployment of Kimai running version 2.53.x or earlier. Kimai is a widely used open-source time-tracking tool deployed by SMBs and enterprises, commonly exposed to the internet for employee time logging.
Blast Radius: The blast radius is the exposed user base of the affected Kimai instance. In the worst case where the instance holds administrative accounts, enumeration could be a stepping stone to full account takeover and application compromise. Compliance considerations arise where the enumeration targets PII-bearing accounts (e.g., in regulated environments subject to GDPR or similar).
Detection Guidance
The following detection signatures target the behavior associated with exploiting CVE-2026-80199 — specifically, a series of unauthenticated requests to an authentication endpoint bearing different X-AUTH-USER header values in rapid succession.
Sigma Rule
title: Kimai Username Enumeration via X-AUTH-USER Timing Oracle (CVE-2026-80199)
id: e3a8f4c2-9b1d-4f6e-8a2c-7d5b9e1f4a8c
status: experimental
description: Detects a series of unauthenticated requests to a Kimai instance with varying X-AUTH-USER headers, indicating possible username enumeration via the timing oracle vulnerability (CVE-2026-80199).
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-80199
author: valtersit.com Threat Intelligence
date: 2026/02/15
logsource:
category: webserver
product: apache
service: http
detection:
selection:
cs-method: 'GET' # or POST; adjust to actual auth endpoint method
cs-uri-query|contains: 'api' # Kimai API endpoints typically under /api
filter:
c-user-agent|contains: 'kimi' # legit clients; tune as necessary
condition: selection and not filter
timeframe: 60s
condition-agg:
# More than 20 distinct username values in X-AUTH-USER header within 60s
'X-AUTH-USER'|re: .+
distinct_count: >= 20
falsepositives:
- Load balancer health checks replaying headers
- Legitimate API clients with distinct user tokens (rare)
level: medium
tags:
- attack.t1190
- attack.t1589.001
- cve.2026.80199
- cwe.208
YARA Rule
rule Kimai_TokenAuthenticator_Username_Enumeration_CVE_2026_80199
{
meta:
author = "valtersit.com Threat Intelligence"
date = "2026-02-15"
description = "Detects exploit attempts or enumeration tooling signatures targeting CVE-2026-80199 in Kimai"
cve = "CVE-2026-80199"
cwe = "CWE-208"
score = "60"
strings:
$x_auth_user = "X-AUTH-USER" ascii nocase
$auth_header = "Authorization" ascii nocase
$api_path = "/api/" ascii nocase
$user_agent_hack = "curl" ascii nocase
$user_agent_go = "Go-http-client" ascii nocase
condition:
uint16(0) == 0x0D0A and filesize < 1MB and
$x_auth_user and (
(#x_auth_user > 5) or // multiple occurrences of the header within the same artifact
($user_agent_hack or $user_agent_go)
)
}
Note: This rule is designed to detect artifacts (PCAP extracts, proxy logs, or HTTP request bundles) that contain multiple occurrences of the X-AUTH-USER header typical of an enumeration script. In a file-based scanning context, the rule flags samples that reflect enumeration traffic.
Suricata IDS Rule
alert http any any -> $HOME_NET any (msg:"KIMAI CVE-2026-80199 Username Enumeration Attempt - X-AUTH-USER Header Variation"; flow:to_server,established; content:"X-AUTH-USER"; http_header; nocase; pcre:"/X-AUTH-USER\s*:\s*[^\r\n]+/iH"; threshold:type both, track by_src, count 20, seconds 60; classtype:attempted-recon; reference:cve,2026-80199; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-80199; sid:3018999; rev:1;)
Explanation: The rule flags HTTP traffic where the X-AUTH-USER header is present and applies a threshold to detect at least 20 occurrences from the same source IP within 60 seconds — indicative of username enumeration.
Elastic Detection
// EQL query for Elasticsearch - detected on the web server or reverse proxy logs
sequence by source.ip with maxspan=60s
[network where destination.port == 443 and http.request.headers["X-AUTH-USER"] != null]
[network where destination.port == 443 and http.request.headers["X-AUTH-USER"] != null]
[network where destination.port == 443 and http.request.headers["X-AUTH-USER"] != null]
[network where destination.port == 443 and http.request.headers["X-AUTH-USER"] != null]
[network where destination.port == 443 and http.request.headers["X-AUTH-USER"] != null]
Explanation: This EQL sequence requires five or more HTTP requests from the same source IP within 60 seconds, each bearing the X-AUTH-USER header. Tune the count/threshold to reduce noise in production.
Splunk SPL Query
index=web sourcetype=access_combined OR sourcetype=iis
| spath input=headers path=X-AUTH-USER output=x_auth_user
| where isnotnull(x_auth_user)
| eval _time_bucket = strftime(_time, "%Y-%m-%d %H:%M:%S")
| stats count as auth_header_count, dc(x_auth_user) as distinct_users by src_ip, _time_bucket
| where auth_header_count > 20 OR distinct_users > 10
| table _time, src_ip, auth_header_count, distinct_users
| sort - _time
Explanation: The query identifies source IPs that have sent more than 20 requests containing the X-AUTH-USER header within a single minute, or have used more than 10 distinct usernames — strong indicators of enumeration.
Wazuh OSSEC Rule
<group name="kimai,">
<rule id="923859" level="8">
<decoded_as>web-access</decoded_as>
<match>X-AUTH-USER</match>
<description>CVE-2026-80199: Kimai web request contains X-AUTH-USER header (potential username enumeration).</description>
<group>web_application_attack,kimai,</group>
<mitre>
<id>T1190</id>
<id>T1589.001</id>
</mitre>
<options>no_full_log</options>
</rule>
<rule id="923860" level="12" frequency="20" timeframe="60">
<if_matched_rules>1008999</if_matched_rules>
<description>CVE-2026-80199: High frequency of X-AUTH-USER requests from same source - active username enumeration in progress.</description>
<group>web_application_attack,kimai,</group>
<mitre>
<id>T1190</id>
<id>T1589.001</id>
</mitre>
</rule>
</group>
Explanation: The first rule flags individual requests with the X-AUTH-USER header. The second rule correlates 20 occurrences within 60 seconds from the same source and escalates to a higher severity alert.
Mitigation & Patch Guidance
Patch Status: UNPATCHED (Confidence 0/4). No patch evidence is available from any tracked source at the time of this report, and no vendor advisory has been published. The only version-level mitigation is an upgrade to Kimai 2.54.0 or later, which is presumed to contain the fix based on the NVD "before 2.54.0" phrasing.
Immediate Mitigations (while patch is pending):
- Rate-Limit Authentication Endpoints: Deploy a reverse proxy or WAF (e.g., Nginx, HAProxy, Cloudflare) that enforces strict rate limiting on the authentication endpoint. Limit to a small number of requests per minute per source IP and consider IP-based temporary blocking after threshold breach. This compensates for the missing application-level throttling for the
X-AUTH-USERheader probe traffic. - Modify Proxy Behavior: If possible, configure the reverse proxy to strip or validate the
X-AUTH-USERheader before it reaches the application. Because the header may be only required for trusted internal microservice calls, blocking it at the edge for external traffic may effectively neutralize the enumeration vector. - Monitor and Alert: Implement the detection signatures provided in the Detection Guidance section (Section 6) to alert on abnormal patterns of
X-AUTH-USERheader usage. Configure active blocking or SOAR-based responses for confirmed enumeration activity. - Restrict Network Exposure: If the Kimai instance is intended only for internal use, restrict access to the application via firewall rules, VPN, or SSO with MFA. Ensure the application is not directly reachable from the internet.
Patch / Upgrade Steps:
- Upgrade to Kimai 2.54.0 or the latest stable release as soon as it becomes available. Verify the release notes to confirm the fix for CVE-2026-80199 prior to deployment.
- Follow the vendor's official upgrade documentation. For Kimai, this typically involves taking a database backup, pulling the updated source from the official repository (GitHub:
kimai/kimai), running database migrations, and clearing caches. - Test the upgrade in a staging environment first, specifically verifying that the authentication response time is now consistent for valid and invalid usernames.
- After the upgrade, check that no unintended breaking changes affect existing API clients that relied on the
X-AUTH-USERheader behavior (in case the header is also used in ongoing legitimate integrations).
Long-Term Hardening:
- Application Security Review: Conduct a code review of the authentication module to ensure that the password hasher is executed unconditionally (e.g., hashing a dummy password when the user is not found), preventing regression of this timing oracle.
- Defense-in-Depth: Institute application-level login throttling and account lockout policies, even after the patch, to mitigate future authentication-related attacks (including brute force and credential stuffing).
- Web Application Firewall (WAF) Rules: Deploy WAF rules to flag unusual numbers of requests to authentication endpoints, regardless of the specific header, as a generalized defense against enumeration and credential attacks.
- Vulnerability Management: Subscribe to Kimai security advisories and the CVE feed to stay informed of any patch updates or revised advisories. Re-assess exploitation risk as new details emerge.
References
- NVD Entry for CVE-2026-80199 — https://nvd.nist.gov/vuln/detail/CVE-2026-80199
- Kimai Official Project Site — https://www.kimai.org/
- Kimai GitHub Repository (for version tracking and release notes) — https://github.com/kimai/kimai
- CWE-208: Observable Timing Discrepancy — https://cwe.mitre.org/data/definitions/208.html
- MITRE ATT&CK Technique T1190: Exploit Public-Facing Application — https://attack.mitre.org/techniques/T1190/
Threat Actor Campaigns: No known threat actor campaigns or exploit-in-the-wild evidence associated with CVE-2026-80199 at the time of writing. The absence of public exploit code and CISA KEV listing suggests low active exploitation as of the publication date; however, the ease of timing-oracle exploitation in unthrottled authentication paths makes active exploitation likely once the patch is widely deployed (as attackers target unpatched instances). Monitoring should continue via the detection rules provided.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.