CVE-2026-84286 in ExLlamaV3info

Summary

by MITRE • 10/12/2026

ExLlamaV3’s EXL3 loader uses an untrusted, model-supplied index to select a CUDA kernel without first verifying that the index is within bounds. A malicious model can force the code to read and invoke an out‑of‑range function pointer, resulting in a reproducible crash. Under specific conditions involving certain host memory layouts, it may be possible for an attacker to exploit this vulnerability to achieve controlled indirect kernel dispatch during model load.

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

Analysis

by VulDB Data Team • 10/13/2026

The vulnerability identified within the ExLlamaV3 library’s EXL3 loader represents a critical failure in input validation and bounds checking mechanisms when handling external resources. Specifically, the flaw resides in the logic responsible for selecting CUDA kernels based on an index provided by the loaded model file. This design decision assumes that all indices embedded within untrusted model data are valid and correspond to existing kernel functions within the application’s memory space. However, this assumption is fundamentally flawed as it fails to account for maliciously crafted inputs designed to exploit trust boundaries between the library code and external model files. The absence of rigorous validation allows an attacker who controls or influences the content of a loaded model file to manipulate internal control flow by supplying arbitrary index values that fall outside the expected range of valid kernel identifiers.

From a technical perspective, this issue classifies as CWE-129: Improper Validation of Array Index and CWE-843: Access of Resource Using Incompatible Type if interpreted broadly regarding type safety in system calls, though it most directly aligns with CWE-787: Out-of-bounds Write or Read depending on the specific memory access pattern triggered. When an out-of-range index is processed, the application attempts to dereference a function pointer located at an invalid memory address relative to the kernel dispatch table. In many scenarios, this results in immediate program termination due to segmentation faults or similar operating system-level protection mechanisms triggering upon illegal memory access. This behavior confirms that the vulnerability can be reliably reproduced by simply providing a malformed model file with extreme index values, leading to denial of service conditions for any user or automated pipeline attempting to load such models.

However, the severity escalates significantly under specific environmental conditions related to host memory layout and process state. If an attacker can carefully craft the out-of-bounds access so that it lands on a valid function pointer within adjacent memory regions, they may achieve controlled indirect kernel dispatch. This scenario transforms a simple crash into a potential code execution vulnerability. By controlling which arbitrary function is invoked through the manipulated index, an attacker could potentially execute unintended operations or leverage existing functions in the binary to perform actions outside their intended scope. While achieving reliable exploitation requires precise knowledge of memory layout and may be mitigated by modern protections like ASLR (Address Space Layout Randomization), the theoretical possibility remains a serious security risk, particularly in environments where model files are sourced from untrusted third parties or generated dynamically without integrity verification.

In terms of operational impact, this vulnerability affects any system integrating ExLlamaV3 for large language model inference, especially those operating in multi-tenant cloud environments or automated ML pipelines that accept user-uploaded models. A successful exploitation could lead to unauthorized code execution, privilege escalation if the process runs with elevated permissions, or complete service disruption through repeated crashes. The reliance on untrusted input without validation violates fundamental secure coding principles and exposes infrastructure to remote attack vectors via malicious model files distributed across public repositories or shared datasets.

To mitigate this risk, immediate remediation should focus on implementing strict bounds checking for all indices derived from external sources before they are used as array subscripts or function pointer selectors. Developers must validate that any index provided by a loaded model file falls within the predefined range of supported kernels and reject inputs that exceed these limits with appropriate error handling rather than proceeding to memory access operations. Additionally, adopting defense-in-depth strategies such as enabling full ASLR on target systems can reduce the likelihood of successful exploitation even if bounds checking is bypassed or missed in edge cases. Regular security audits focusing on input validation patterns in libraries processing untrusted data are essential to prevent similar vulnerabilities from persisting in critical AI infrastructure components.

Responsible

Certcc

Reservation

09/01/2026

Disclosure

10/12/2026

Moderation

accepted

EPSS

0.00589

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!