llama.cpp (GGUF vocabulary parsing, llama_vocab::impl::print_info): MALICIOUS MODEL FILE CRASHES THE SERVER: the GGUF

CVSS 6.6NCVD-2025-020-llama-cpp-gguf-vocabulary-parsinAI/ML frameworks & servingGHSA-g4cc-763q-h9h6curated

Impact

MALICIOUS MODEL FILE CRASHES THE SERVER: the GGUF parser reads special token IDs without bounds-checking them against the vocabulary. special_bos_id defaults to 1, so a model whose vocabulary contains a single token makes print_info index id_to_token[1] out of bounds on the heap and segfault. Any deployment that loads user-supplied or third-party GGUF files — a model-hosting service, a shared inference gateway that lets tenants bring their own weights, a self-service fine-tune endpoint — can be taken down by uploading a small crafted file. It is a heap over-read rather than a write, so the realistic ceiling is denial of service, but on a GPU serving node that means the accelerator sitting idle and every co-tenant on that replica losing service until the process is recycled.

Who can reach it

Local to the loading process, reached remotely wherever the model path is attacker-influenced: the victim runs llama.cpp against a crafted GGUF file. Any bring-your-own-model or shared model-cache workflow puts this within reach of a tenant.

What to do

Update llama.cpp past the fixed commit and restart the servers. Validate GGUF files before loading — reject models whose declared vocabulary size is smaller than the special token IDs they reference — and load only from model stores whose writers you trust. Set pod restart policies so a crashed serving process is recycled rather than leaving the GPU stranded.

References

https://github.com/ggml-org/llama.cpp/security/advisories/GHSA-g4cc-763q-h9h6

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.