EUVD-2026-110569
GHSA-3r8c-j789-2864
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPublish crafted GGUF model with <0x-1> token
-
DeliveryVictim loads model in llama.cpp
-
ExploitNegative index parsed in plamo2 tokenizer build
-
ExecutionOut-of-bounds write before bytes_ buffer
-
ImpactHeap corruption yielding crash or code execution
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Array index validation
|
| Exploitation Conditions | Exploitation requires the victim to load a crafted GGUF model whose PLaMo2 tokenizer (llm_tokenizer_plamo2::build path) includes a BYTE-typed token with an out-of-range value such as <0x-1>; the negative parsed value is used as an index into the bytes_ buffer, producing the out-of-bounds write during model loading. Limiting factors: the attack is local and model-load-driven (AV:L, UI:P) - the attacker must get the victim to load an untrusted/attacker-controlled model, so it does not apply to deployments that only load trusted, vendor-signed models; it is also specific to the PLaMo2 tokenizer code path and to builds from b5899 up to (not including) b10261. |
| Impact | Signals point to a real but conditional memory-corruption flaw rather than an urgent mass-exploitation threat. The CVSS 4.0 base score of 8.5 is driven by high confidentiality, integrity and availability impact (VC:H/VI:H/VA:H) reflecting potential code execution from a heap out-of-bounds write, but the same vector constrains real-world risk: AV:L means the attack is local (the malicious GGUF model must be loaded on the target), and UI:P means exploitation depends on the victim actively loading an attacker-supplied model. This is not remote-unauthenticated exploitation. Exploitation probability is low (EPSS 0.14%, 3rd percentile) and the CVE is not listed in CISA KEV, so there is no public evidence of active exploitation - consistent with a flaw that requires social-engineering a user into loading an untrusted model file rather than a wormable remote bug. The vuln.today decision label is 'this_week', aligning with a patch-promptly-but-not-emergency posture. Net: a genuine high-severity memory-safety defect whose practical risk is gated by the untrusted-model-loading precondition; prioritize patching for any workflow that ingests third-party or user-supplied GGUF models, but it is not a drop-everything internet-facing emergency. |
| Exploit ScenarioDerived | An attacker publishes a malicious GGUF model (e.g., on a model-sharing hub) whose PLaMo2 tokenizer contains a BYTE-typed token such as <0x-1>. When a victim loads that model in a vulnerable llama.cpp build, the negative value parsed from the token is used as an array index, writing token ids before the bytes_ buffer and corrupting heap memory, causing a crash or potentially code execution. No standalone public exploit was identified; the vulnerable code path and root cause are documented in the vendor fix diff. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 28, 2026
Heap out-of-bounds write in llama.cpp builds b5899 through b10260 lets an attacker corrupt heap memory when the victim loads a crafted GGUF model that uses the PLaMo2 tokenizer. A BYTE-typed token whose text parses to a negative value (for example <0x-1>) is used as an index into the tokenizer's bytes_ buffer during model loading, so the write lands before the buffer and can crash the process or potentially enable code execution. The flaw is local in nature (it triggers only when an untrusted model is loaded, per the assessed CVSS:3.1/AV:L/AC:L/PR:N/UI:R vector), a vendor patch is available in build b10261, no public exploit has been identified at time of analysis, and EPSS is low at 0.14% (3rd percentile) with a this_week priority label.
RemediationAI
Vendor-released patch: upgrade to llama.cpp build b10261 or later, which contains the validation added by PR 25969 and PR 26511 (commit cf06ad7dfe79e7bf2934150d4fefe1ce8db05490) and is published at https://github.com/ggml-org/llama.cpp/releases/tag/b10261; builds below b10261 and at or above b5899 remain affected. Because exploitation requires the victim to load a crafted model, a practical compensating control until upgrading is to load only GGUF models from trusted, verified sources and to reject models whose tokenizer vocabulary contains BYTE-typed entries with malformed or out-of-range <0xNN> values, with the trade-off that checking tokenizer metadata is a manual gate that does not protect against a trusted-looking but malicious model. Deployments that only ever load vendor-signed, first-party models are outside the assessed attack path, and per the advisory the code fix is the complete remediation.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected code lives in src/llama-vocab.cpp inside llm_tokenizer_plamo2::build, the vocabulary-construction path used for the PLaMo2 tokenizer. When a GGUF model declares a BYTE-typed token, the tokenizer text is expected to look like <0xNN> and is converted with std::stoi(hex_str, nullptr, 16); that parsed integer then serves directly as an index into the bytes_ lookup table. The root cause is CWE-129 (Improper Validation of Array Index): the parsed value is never range-checked, so <0x-1> yields -1 and bytes_[-1] writes one token id before the buffer, and non-hex input makes std::stoi throw an uncaught std::invalid_argument that aborts the process. Because the index is fully attacker-controlled through the model file's tokenizer metadata, a malicious GGUF can place a token id at a negative offset relative to bytes_, within the surrounding heap allocation's metadata or neighboring objects. The upstream fix (PR 25969, follow-up PR 26511, commit cf06ad7) constrains the parse to exactly two hex digits in [00,FF], rejects out-of-range or non-hex values, and skips the store instead of aborting.
Know when Llama Cpp 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:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Triggered by loading a malicious model file, so AV:L and UI:R; no privileges needed (PR:N); heap OOB write can yield code execution, so C/I/A:H.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
llama.cpp b5899 before b10261 contains a heap out-of-bounds write vulnerability in llm_tokenizer_plamo2::build that allows attackers to corrupt heap memory via crafted GGUF models. Attackers can supply BYTE-typed token text like <0x-1> whose negative parsed value writes token ids before the bytes_ buffer during model loading, causing crashes or potential code execution.
Executive ViewAI
A heap memory corruption vulnerability in llama.cpp, a widely used open-source library for running large language models, affects builds b5899 through b10260. When a user loads a crafted GGUF model file that uses the PLaMo2 tokenizer, an attacker can corrupt heap memory, potentially crashing the process or enabling code execution. Although exploitation requires local interaction (loading an untrusted model), the risk is significant for teams using llama.cpp to process third-party or user-supplied models, as a malicious model could compromise the host.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
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.
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
Arbitrary memory write in llama.cpp's RPC server allows remote unauthenticated attackers to corrupt arbitrary memory add
Remote code execution in llama.cpp (commit 18c2e17) is possible when a user opens a malicious .gguf model file, triggeri
Llama.cpp server endpoints fail to validate the n_discard parameter from JSON input, allowing negative values that trigg
Remote code execution in llama.cpp (commit 18c2e17) is possible when a victim loads a malicious .gguf model file, trigge
Remote code execution in llama.cpp (GGUF library) allows attackers to achieve arbitrary code execution by tricking a use
Remote code execution in llama.cpp (commit 18c2e17) occurs when the GGUF library's gguf_fread_str function parses a mali
Heap-based buffer overflow in llama.cpp's GGUF library header parser (commit 18c2e17) enables code execution when a vict
CVE-2025-52566 is a signed vs. unsigned integer overflow vulnerability in llama.cpp's tokenizer (llama_vocab::tokenize f
Remote code execution in llama.cpp RPC backend allows unauthenticated attackers with TCP access to achieve arbitrary mem
llama.cpp provides LLM inference in C/C++. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable,
Heap buffer overflow in llama.cpp's server KV cache state-restore path (builds b4882 through b9058) lets an attacker who
Stack-based out-of-bounds write in llama.cpp's ggml-rpc RDMA receive path (builds b8841 through b11865) lets unauthentic
Exploit-DB