CVE-2026-116502 in ExLlamaV2info

Summary

by MITRE • 10/26/2026

A flaw has been found in turboderp-org ExLlamaV2 up to 0.3.2. The impacted element is the function QMatrix::make_sequential of the file exllamav2/exllamav2_ext/cuda/q_matrix.cu of the component GPTQ Index Handler. Executing a manipulation of the argument g_idx can lead to out-of-bounds write. The attack needs to be launched locally. The project was informed of the problem early through an issue report but has not responded yet.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/26/2026

The vulnerability identified in turboderp-org ExLlamaV2 versions up to 0.3.2 represents a critical memory safety defect within the GPTQ Index Handler component, specifically located in the QMatrix::make_sequential function found in the cuda/q_matrix.cu source file. This flaw arises from an insufficient validation of input arguments passed during the initialization or manipulation of quantized matrix structures used for efficient large language model inference on GPU hardware. The core technical issue is a lack of rigorous bounds checking when processing the g_idx argument, which serves as an index mapping mechanism for group-wise quantization data. When this argument contains values that exceed the allocated memory boundaries of the underlying buffer, it triggers an out-of-bounds write operation. This type of error allows malicious or malformed input to overwrite adjacent memory locations, potentially corrupting program state, causing application crashes through segmentation faults, or in more severe scenarios, enabling arbitrary code execution if the overwritten data includes control flow pointers such as return addresses or function pointers within the CUDA kernel context.

From a technical perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write, which describes situations where software writes to a memory location outside of the intended buffer boundary. In the specific context of ExLlamaV2, which is designed for high-performance inference using quantized weights, the g_idx array typically maps token indices to their corresponding weight groups. If an attacker can control or influence this index mapping through local input vectors, they can force the CUDA kernel to write data beyond the allocated memory space associated with the matrix structure. This exploitation vector requires local access because it involves interacting directly with the application's execution environment rather than exploiting a remote network service. The attack surface is thus confined to scenarios where an adversary has already gained some level of system access, such as through a compromised user account or via social engineering tactics that lead to the execution of malicious scripts invoking this library function.

The operational impact of this vulnerability extends beyond simple application instability. While immediate exploitation may result in denial of service due to process termination, the deeper risk lies in potential privilege escalation if the vulnerable component runs with elevated privileges or is integrated into a larger system where memory corruption can be chained with other vulnerabilities. For organizations deploying ExLlamaV2 for local inference tasks, this flaw poses a significant security risk, particularly in multi-tenant environments or when processing untrusted model inputs. The lack of response from the project maintainers to early issue reports exacerbates the exposure window, leaving users without official patches or workarounds. This delay highlights the importance of proactive vulnerability management and the need for organizations to monitor upstream repositories closely for security advisories that may not be immediately publicized through standard channels like CVE assignments.

Mitigation strategies must focus on both immediate defensive measures and long-term remediation steps. Since no patch has been released, users should consider restricting local access to systems running vulnerable versions of ExLlamaV2 until an update is available. Implementing strict input validation at the application layer before passing arguments to the QMatrix::make_sequential function can help prevent exploitation by ensuring that g_idx values remain within expected bounds. Additionally, enabling memory protection mechanisms such as Address Sanitizer during development and testing phases can aid in detecting similar issues early. For production environments, isolating inference workloads using containerization or virtualization limits the blast radius of any potential compromise. Organizations should also engage with the open-source community to encourage timely responses from maintainers and consider contributing patches if they have the expertise to address the root cause directly by adding proper bounds checks in the CUDA kernel code.

This incident underscores broader industry challenges regarding security hygiene in specialized AI libraries that prioritize performance over rigorous input validation. It relates to ATT&CK technique T1059: Command and Scripting Interpreter, as local attackers might leverage such vulnerabilities to execute further commands after gaining initial access through memory corruption. Furthermore, it reflects CWE-20: Improper Input Validation, emphasizing the need for robust defensive programming practices in low-level systems code. As AI models become more integrated into critical infrastructure, ensuring the security of inference engines like ExLlamaV2 is paramount. Stakeholders must remain vigilant and adopt a zero-trust approach to local execution environments, recognizing that even locally hosted services can serve as entry points for broader system compromise if foundational vulnerabilities are left unaddressed by upstream developers.

Responsible

VulDB

Disclosure

10/26/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!