CVE-2026-44367
Inconsistent Username Handling Causes DoS in Klaw
Publication date: 2026-06-02
Last updated on: 2026-06-02
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| aiven | klaw | to 2.10.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-178 | The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results. |
| CWE-20 | The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not include any details on how this vulnerability affects compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
The vulnerability exists in Klaw versions 2.10.3 and earlier in the user registration and login mechanisms due to inconsistent handling of username case sensitivity.
Specifically, the registration process uses case-sensitive validation, while the login process uses case-insensitive lookups. This discrepancy allows an attacker to register a username with different casing (for example, "victiM" when "victim" already exists).
This creates two conflicting accounts that become inaccessible to both users and breaks administrative tools, leading to a targeted Denial of Service (DoS) and complete account lockout.
The issue was fixed in version 2.10.4 by enforcing case-insensitive username handling.
How can this vulnerability impact me? :
This vulnerability can impact you by causing a Denial of Service (DoS) through account lockout.
An attacker can exploit the inconsistent case sensitivity to create conflicting user accounts that lock out legitimate users, including administrators.
This results in loss of access to affected accounts and breaks administrative tools, potentially disrupting management and governance of Kafka topics.
There are no workarounds; upgrading to version 2.10.4 is necessary to prevent future occurrences, and administrators must manually resolve existing locked accounts by editing the database.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves inconsistent case sensitivity handling in user registration and login, leading to conflicting accounts with different username casing that cause account lockout.
Detection involves identifying duplicate usernames that differ only in letter casing (e.g., "victiM" vs "victim") in the Klaw user database.
Since the issue is related to database entries, you can detect it by querying the user table for usernames that are duplicates ignoring case.
- Run a SQL query to find usernames differing only by case, for example (syntax may vary depending on your database):
- SELECT LOWER(username), COUNT(*) FROM users GROUP BY LOWER(username) HAVING COUNT(*) > 1;
No specific network commands or logs are mentioned for detection, as the vulnerability is at the application and database level.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade Klaw to version 2.10.4 or later, where the vulnerability is fixed by enforcing case-insensitive username handling.
Since the application interface cannot delete duplicate locked accounts, administrators must manually resolve existing locked accounts by editing the database to remove or merge conflicting usernames.
No workarounds exist other than upgrading and manual database cleanup.