CVE-2026-93544 in libXi
Summary
by MITRE • 09/24/2026
An out-of-bounds read in libXi's XI2 XIQueryDevice reply parsing in libXi before 1.8.4 can be used by a malicious X server to crash an attached X client.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified as CVE-2023-5679 resides within the libXi library, specifically affecting versions prior to 1.8.4. This security flaw is categorized as an out-of-bounds read, which corresponds to CWE-125 in the Common Weakness Enumeration standard. The issue occurs during the parsing of XIQueryDevice replies generated by the X Input Extension version two protocol implementation. In this context, libXi acts as a client-side library that communicates with the X server to retrieve information about input devices such as keyboards, mice, and touchscreens. When an application requests device details using the XI2 extension, it sends a query request and expects a structured reply from the server. The vulnerability arises because the parsing logic within libXi fails to adequately validate the length or bounds of the data received in this reply before attempting to read specific fields.
From a technical perspective, the flaw allows for an out-of-bounds memory access when processing malformed or maliciously crafted responses. If a compromised or hostile X server sends a reply where the reported size of device information exceeds the actual buffer allocated by libXi for parsing, the library will attempt to read data beyond the end of the valid memory region. This behavior is characteristic of CWE-125, which involves reading past the end of a buffer. The consequence of this improper validation is typically immediate program termination due to a segmentation fault or similar access violation error. For an X client application relying on libXi for input device management, such as a graphical user interface toolkit or a specialized accessibility tool, this results in a denial of service condition where the application crashes unexpectedly.
The operational impact of this vulnerability is primarily centered around availability and stability rather than confidentiality or integrity. Since the attack vector requires interaction with an X server that can send arbitrary replies, it implies a threat model involving untrusted display servers or compromised environments within the local graphical session. An attacker controlling the X server could exploit this flaw to crash any attached client application that utilizes libXi for device queries. This disruption affects users by forcing them to restart their applications and potentially lose unsaved work. While the primary impact is denial of service, in more complex scenarios involving memory corruption exploitation techniques, out-of-bounds reads can sometimes leak sensitive information from adjacent memory locations, although the description emphasizes crashing as the main outcome.
This vulnerability aligns with ATT&CK technique T1499, Endpoint Denial of Service, specifically under sub-techniques related to application crash or resource exhaustion. It also reflects weaknesses in input validation and boundary checking that are common in legacy C-based libraries handling network or inter-process communication data. The lack of robust bounds checking during the parsing phase highlights a critical gap in defensive coding practices for low-level system libraries.
Mitigation strategies focus on updating the underlying library to a patched version. Users running systems with libXi versions earlier than 1.8.4 should upgrade immediately to version 1.8.4 or later, where this out-of-bounds read has been corrected through improved validation of reply lengths and safer parsing routines. System administrators managing environments with untrusted X servers should consider isolating such sessions or restricting access to prevent malicious actors from injecting crafted replies into the communication stream between clients and the display server. Additionally, employing runtime protection mechanisms like Address Sanitizers during development can help detect similar issues in other parts of the codebase before they reach production deployments.