EUVD-2026-120505Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessHost crafted ExLlamaV3 model checkpoint
-
DeliveryVictim loads untrusted model
-
ExploitOut-of-range tid2eid value reaches routing kernel
-
ExecutionKernel reads past score row bounds
-
ImpactLeak adjacent GPU memory or crash
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Bounds checking, read limits
MITRE ATT&CK
1 technique across 1 tactic: Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the victim to load and run a crafted model checkpoint that uses the hash-MoE / block-sparse routing path, where the tid2eid table (or selected-expert values) contain expert ids outside the valid [0, num_experts-1] range; in vulnerable builds (≤1.6.3) routing_sel_norm_kernel consumes that id directly as an index into the score row, causing the out-of-bounds read. Limiting factors: the attacker must get the target to load an untrusted/malicious model (UI:P - passive interaction), the code path is specific to hash-routing MoE models (not all models exercise it), and impact is a bounded over-read (Low C/I/A), not arbitrary code execution. After 1.6.4 the table is rejected at load time, so a malformed checkpoint fails before reaching the kernel. |
| Impact | This is a medium-severity issue (vendor CVSS 4.0 base 5.3) and the available decision signals argue against treating it as an emergency. There is no EPSS score and no CISA KEV listing in the input, and the vuln.today priority is 'this_month' rather than act_now or emergency - consistent with a moderate, non-urgent fix. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P) pairs a network vector with passive user interaction and only Low confidentiality/integrity/availability impact, which matches an out-of-bounds read (CWE-125) of limited scope rather than code execution. One signal conflicts and should be read carefully: VulDB's phrase 'Remote exploitation of the attack is possible' overstates the practical vector. The source-code evidence shows the real trigger is a model checkpoint - the hash-MoE routing table (tid2eid) is validated only at load after the patch - so exploitation requires a victim to load a crafted/untrusted ExLlamaV3 model, which is why UI:P is present. In other words this behaves more like an untrusted-model-file / supply-chain input issue than an unauthenticated network-service bug. Net priority: schedule the upgrade, but it is not a drop-everything item absent evidence of exploitation. |
| Exploit ScenarioDerived | An attacker publishes a crafted ExLlamaV3 model whose hash-MoE routing table (tid2eid) contains expert ids outside the valid range. When a victim loads and runs that model, routing_sel_norm_kernel in routing.cu uses the unchecked id as an index and reads past the end of the score row in GPU memory, potentially leaking adjacent memory contents or crashing the process. No verified working exploit code is confirmed; GitHub issue #526 documents the flaw and the fixing commit. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 09, 2026
Out-of-bounds read in ExLlamaV3 through 1.6.3 affects the CUDA kernel routing_sel_norm_kernel used by hash-MoE routing, which indexes a score row with an expert id taken from the gate.tid2eid table without validating it against num_experts. The practical trigger is a victim loading and running a crafted or malformed model checkpoint that contains expert ids outside the valid range on the hash-MoE / block-sparse path (UI:P in the vendor CVSS 4.0 vector), yielding a bounded over-read with Low confidentiality, integrity and availability impact. Vendor CVSS 4.0 base score is 5.3, the decision label is this_month, and no public exploit code or active exploitation (KEV) is identified at time of analysis.
RemediationAI
Upgrade ExLlamaV3 to version 1.6.4, which contains commit c9a57ae832a3035e264e0a412e1daf4ebb699b98; the release is published at https://github.com/turboderp-org/exllamav3/releases/tag/v1.6.4, so pinning the dependency to >=1.6.4 resolves both the kernel-side clamp and the load-time validation of the tid2eid table. Until the upgrade is deployed, the effective control is to avoid loading untrusted or unverified model checkpoints on the hash-MoE / block-sparse routing path, since the out-of-bounds read is only reachable through a malicious or malformed checkpoint rather than through ordinary inference requests; the trade-off is that this restricts model sourcing and shared-checkpoint workflows rather than fixing the code. Note that after 1.6.4 a malformed checkpoint fails with a ValueError at load time instead of reaching the kernel, so models that were silently accepted by 1.6.3 may be rejected after the upgrade and should be re-validated against their expert-id ranges before rollout.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ExLlamaV3 is a Python/CUDA inference library for large language models, and its MoE implementations dispatch routing work to hand-written CUDA kernels compiled from exllamav3/exllamav3_ext/routing.cu. In routing_sel_norm_kernel the selected-expert array is used directly as an index (selected[row * K + lane]) into per-expert score data; in the hash-MoE/block-sparse configuration those ids can originate from a checkpoint-supplied tid2eid mapping table rather than from the router's own computation. Because the vulnerable build performs no bounds check, a table entry outside [0, num_experts-1] produces a read past the end of the score row, the classic CWE-125 out-of-bounds read pattern. The upstream commit c9a57ae832a3035e264e0a412e1daf4ebb699b98 addresses this in two layers: it clamps the index in the kernel (max(0, min(selected[...], num_experts - 1))) as defense in depth, and it adds a load-time check in modules/block_sparse_mlp.py that rejects a checkpoint whose tid2eid values span outside the routed expert count with a ValueError. The same commit also hardens an adjacent, separately tracked issue (#525) in ngram.cu and ngram_embedding.py, bounding head ids in ngram_dequant_kernel and asserting that head_offsets and head_bias row counts match num_heads. Exploitation therefore depends on the deployment mode: models that never use hash-MoE or block-sparse routing do not exercise the affected kernel, while services or users that load third-party checkpoints on that path are exposed; the required interaction is loading the malicious model, not a network-facing request.
Know when Exllamav3 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Triggered by loading a crafted model checkpoint so UI:R and PR:N; the out-of-bounds read can leak limited memory (C:L) or crash the process (A:L) with no integrity impact.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
DescriptionCVE.org
A weakness has been identified in Turboderp-org ExLlamaV3 up to 1.6.3. The impacted element is the function routing_sel_norm_kernel of the file exllamav3/exllamav3_ext/routing.cu of the component hash-MoE routing. This manipulation of the argument gate.tid2eid causes out-of-bounds read. Remote exploitation of the attack is possible. Upgrading to version 1.6.4 is sufficient to resolve this issue. Patch name: c9a57ae832a3035e264e0a412e1daf4ebb699b98. Upgrading the affected component is recommended.
Threat Intelligence Overview
NVD
CVE.org
GitHub
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
A buffer overflow occurs when a program writes more data to a memory buffer than it was allocated to hold, causing the excess data to spill into adjacent memory regions.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB