CVE-2026-116816 in llama.cpp
Summary
by MITRE • 10/27/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in llama.cpp versions prior to commit b10261 represents a critical heap-based out-of-bounds write flaw located within the llm_tokenizer_plamo2::build function. This specific component is responsible for parsing and constructing tokenizers from GGUF model files, which are binary formats used to store large language model weights and metadata. The root cause of this vulnerability lies in the improper handling of BYTE-typed token text during the loading process. Specifically, when a crafted GGUF file contains special tokens with negative values, such as those represented by strings like <0x-1>, the parser fails to correctly validate or clamp these integer values before using them as array indices.
During the execution of the tokenizer build routine, the system attempts to map token identifiers into an internal buffer known as bytes_. Because the parsed value is negative, it results in a pointer arithmetic operation that writes data at a memory address preceding the start of the allocated heap buffer. This constitutes a classic off-by-one or larger offset write error where the destination index falls outside the valid bounds of the allocated memory region. The lack of sufficient boundary checks allows an attacker to overwrite adjacent heap metadata, other objects in the heap allocator's free list, or critical application state variables stored immediately before the target buffer.
The operational impact of this vulnerability is severe and multifaceted. In its most immediate manifestation, the corruption of heap memory leads to instability within the inference engine, resulting in segmentation faults or abrupt crashes when loading maliciously crafted models. However, beyond simple denial-of-service conditions, the ability to write arbitrary data to a specific location relative to an allocated buffer significantly expands the attack surface for remote code execution. By carefully crafting the payload and controlling the heap layout through multiple model loads or subsequent allocations, an attacker could potentially overwrite function pointers, return addresses, or virtual table pointers. This capability allows for the hijacking of control flow, leading to arbitrary code execution with the privileges of the process running llama.cpp.
This vulnerability aligns closely with Common Weakness Enumeration (CWE) categories such as CWE-787: Out-of-bounds Write and CWE-125: Out-of-bounds Read, although the primary exploit vector here is write-based. From a threat modeling perspective, this flaw can be mapped to MITRE ATT&CK techniques related to memory corruption exploitation, specifically those involving heap spraying or targeted overwrites to achieve code execution. The vulnerability highlights the risks associated with parsing untrusted binary formats without rigorous input validation and bounds checking on integer values derived from external sources.
Mitigation strategies must focus primarily on updating llama.cpp to version b10261 or later, where this specific logic error has been addressed by implementing proper range checks for token identifiers before they are used as array indices. For environments unable to update immediately, defensive measures include restricting the execution of untrusted GGUF files and validating model inputs through sandboxing mechanisms such as containers or virtual machines with restricted privileges. Additionally, enabling heap protection features like Address Sanitizer during development and deployment testing can help detect similar out-of-bounds access patterns early in the software lifecycle. Security teams should also audit other tokenizer implementations within the codebase for similar parsing logic that handles negative integers without adequate validation against buffer boundaries.