A crafted GGUF file can write past a heap buffer in llama.cpp on model load. The fix shipped in b10261 twelve weeks before the CVE; check your builds.
A crafted GGUF model file can corrupt heap memory in llama.cpp the moment it is loaded, before any prompt is processed. The flaw, CVE-2026-116816, affects llama.cpp builds from b5899 up to but not including b10261. The CVE is new, published to NVD on 27 October 2026, but the fix is not: it shipped in release b10261 on 4 August 2026, about twelve weeks earlier. The job for defenders is to confirm that every llama.cpp build they run, and every app that bundles one, is at b10261 or later.
Severity and who is affected
VulnCheck, the CNA that assigned the CVE, scores it 8.5 on CVSS 4.0 and 7.8 on CVSS 3.1. NVD has not scored it yet; the record is marked Awaiting Analysis. The vector is local with user interaction (AV:L/UI:P), because the victim has to load the file, and the impact on confidentiality, integrity and availability is high. The CVE description says the result is a crash or potential code execution.
Anyone who loads untrusted GGUF files with a build in the affected range is exposed. No exploitation in the wild has been reported.
The bug
The weakness is CWE-129, improper validation of an array index, in llm_tokenizer_plamo2::build(). According to the original report in PR 25969, the function parses the two characters in <0xNN> byte tokens and uses the result as an index into its bytes_ buffer without a range check. A byte-typed token whose text is <0x-1> parses to -1, so a token id is written four bytes before the start of the buffer. Texts from <0x-1> to <0x-f> give offsets of -4 to -60 bytes, so the write lands 4 to 60 bytes before the buffer, and the written value is a token id from the file, so the attacker controls both where the write lands and what it writes. A non-hex value such as <0xZZ> makes std::stoi throw an uncaught exception instead.
The reporter's AddressSanitizer run showed a 4-byte write landing four bytes before a 1024-byte region, triggered by a 297-byte proof-of-concept file. The code runs while the vocabulary is loaded, so no inference and no user prompt are needed.
VulnCheck credits Pedro Cruz (g4nkd), Jeongwoo Lee and CISC.
The fix
NVD and VulnCheck list both PR 25969 and PR 26511 as references, but only one of them is the fix. PR 25969, the original report and proposed patch, was closed without being merged. PR 26511, an alternative that simply checks the token is valid hex, was merged on 4 August 2026, and the b10261 release notes list it as "vocab : validate plamo2 byte tokens". After the fix, the reporter's crafted file is rejected with an error instead of corrupting memory.
The other five CVEs
VulnCheck published five more llama.cpp CVEs on the same day, covering older bugs. All are in NVD as Awaiting Analysis, so the scores below are VulnCheck's.
| CVE | Fixed in | Class | CVSS 4.0 |
|---|---|---|---|
| CVE-2024-58399 | b2731 | Out-of-bounds read from crafted GGUF tensor offsets | 6.9 |
| CVE-2024-58400 | b3701 | Out-of-bounds read from unvalidated token ids sent to llama-server /completion | 8.8 |
| CVE-2025-71439 | b5649 | Heap out-of-bounds read in vocab print_info() from a short tokens array in GGUF | 6.8 |
| CVE-2026-116829 | b11301 | Integer overflow in gguf_init_from_reader: a tensor shape wraps to zero | 6.9 |
| CVE-2026-116840 | b11275 | Integer overflow that bypasses the CVE-2025-53630 size check | 6.9 |
CVSS 4.0 scores assigned by VulnCheck as CNA; NVD lists all six as Awaiting Analysis.
CVE-2024-58400 is a different kind of bug from the rest. It is not triggered by a GGUF file: a remote, unauthenticated client sends integer-array prompts to llama-server with token ids outside the vocabulary range. That network reach is why its CVSS 4.0 score (8.8) sits above CVE-2026-116816's 8.5.
What defenders should do
- Update llama.cpp to b10261 or later. The two later GGUF parser overflows (CVE-2026-116829 and CVE-2026-116840) were fixed in b11301 and b11275, so b11301 or newer covers the whole set.
- Check what your tooling bundles. Desktop apps and runtimes that embed llama.cpp ship their own build; check each vendor's release notes for the llama.cpp version it includes rather than assuming it is current.
- Treat GGUF files from public registries as untrusted input. Load them in a container or as a low-privilege user, away from credentials and sensitive data.
- Do not expose llama-server to untrusted networks on builds before b3701 (CVE-2024-58400).