llama.cpp b5899 before b10261: a crafted GGUF model corrupts the heap while loading (CVE-2026-116816, 8.5); update to b10261 or later

View raw markdownEdit on GitHub ↗

TL;DR

llama.cpp builds b5899 through b10260 contain a heap out-of-bounds write in the plamo2 tokenizer builder: a GGUF file whose BYTE-typed token text parses to a negative value writes token ids before the vocabulary buffer during model loading, which VulnCheck's record (CVE-2026-116816, published 2026-10-27, CVSS 4.0 8.5) says causes crashes or potential code execution as the loading user. The fix, "vocab: validate plamo2 byte tokens" (PR #26511), shipped in release b10261; update any build or wrapper that bundles an older one, and treat a downloaded model file as untrusted input.

What happened

VulnCheck published CVE-2026-116816 on 2026-10-27 (credit Pedro Cruz (g4nkd), Jeongwoo Lee and CISC): llm_tokenizer_plamo2::build in src/llama-vocab.cpp trusted the parsed value of BYTE-typed token text, so a token such as a negative byte literal indexed before the bytes_ buffer and wrote a token id there while the model loaded. The record's vectors: CVSS 4.0 8.5 (AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H) and CVSS 3.1 7.8; the user interaction is opening the model. Affected b5899 before b10261 (the record's version type is "custom", meaning build numbers). The references are the two pull requests (#25969, #26511), the fix commit cf06ad7d, the vulnerable line range at b10259, and release b10261, whose notes read "vocab : validate plamo2 byte tokens (#26511)". The release page prints "04 Aug" with no year beside it; the fix therefore predates the record by about twelve weeks, and the date here is the CVE's, not the fix's.

Why it matters to this audience. The attack input is the model file. Local-inference stacks pull GGUF files from Hugging Face and other mirrors by name, and desktop wrappers, bindings and server images pin a llama.cpp build that lags upstream. The tokenizer type only matters to the attacker: a crafted file can declare whichever tokenizer reaches the bug. This sits beside the Unsloth loader findings (code in config.json) and the Pillow decoder records as the same class: a data file that a library parses on open.

Second source. The CNA record and the vendor's fix commit and release are the primaries; no outlet coverage existed when this was written. The record is counted as confirmed on the vendor's own fix evidence.

Am I affected?

llama-server --version 2>&1 | head -1      # or llama-cli --version; look for the build number
pip show llama-cpp-python 2>/dev/null | grep -i ^version   # the binding pins a llama.cpp build; check its changelog for the vendored commit
  • A build number from b5899 up to b10260 is affected. Wrappers (Ollama-style servers, desktop chat apps, Python and Node bindings) vendor a build; find the commit they pin before concluding you are past b10261.
  • Exposure needs an attacker-supplied model file. A model you converted yourself from weights you trust is outside the path.

If you are affected

  1. Update to b10261 or later, or to a wrapper release that vendors a commit at or after cf06ad7d.
  2. If a model file from an untrusted source was loaded on an affected build, treat the host as having run untrusted input and review it. If your local AI agent was exploited.

Prevention

  • Pin model downloads by hash and source, not by name, and load untrusted models in a sandbox first. Package vetting checklist applies to weights as well as packages.
  • Keep the inference runtime on the current build; llama.cpp ships fixes as numbered builds with no security label, so a version pin hides them.

Update 2026-10-29 — a second record: the ggml-rpc server aborts on an oversized message length (CVE-2026-119052, 8.7); fixed b11935

VulnCheck published CVE-2026-119052 on 2026-10-29: in llama.cpp b2877 before b11935, the ggml-rpc server's recv_msg does not catch the std::length_error thrown when a client sends a command such as SET_TENSOR with a length above std::vector::max_size() after the HELLO handshake, so an unauthenticated remote client aborts the rpc-server process and denies service to every connected client. CVSS 4.0 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H), CVSS 3.1 7.5. Fix: PR #31204, "rpc : catch std::length_error in recv_msg", commit 7ecb57f, released in b11935 (release page printed "27 Oct", pre-release, no year). Credit Sohaib Harraoui (Ostorlab). Exposure only exists where the RPC backend is built and rpc-server listens on a reachable interface; it is opt-in and the project documents it as having no authentication. The GGUF bug above is a different code path.

Sources for this update: CVE Services — CVE-2026-119052 — fetched 2026-10-29: CNA VulnCheck, published 2026-10-29, the range, the description, both scores, the PR, commit and release references, the credit. ggml-org/llama.cpp — release b11935 — fetched 2026-10-29: dated 27 Oct, pre-release, the single change "rpc : catch std::length_error in recv_msg" (#31204).

Sources