Inference Server CVEs: vLLM, Ollama, llama.cpp, Triton

Most published guidance on ML security is still about model files. That was the right emphasis in 2023, when the dangerous act was loading a checkpoint someone else produced. It is no longer where the volume is. The runtimes that serve those models — vLLM, Ollama, llama.cpp, NVIDIA Triton — are network daemons, and their CVE record now reads like the CVE record of any other network daemon: unauthenticated endpoints, hand-rolled binary parsers, and internal transports that were never meant to face a hostile peer.

The difference that matters operationally is reachability. A malicious checkpoint has to be pulled by someone. An inference server bound to 0.0.0.0 is reachable by anything that can route to it, and these processes usually sit on the most privileged hardware in the estate with the fewest network controls in front of them.

vLLM: object serialization used as a transport

vLLM’s critical entries are almost entirely one defect wearing different clothes: Python objects moved between processes over ZeroMQ with pickle or cloudpickle, on a socket that ended up reachable.

• CVE-2024-9053 (CVSS 9.8): in vLLM 0.6.0 the AsyncEngineRPCServer() entrypoints call _make_handler_coro(), which uses cloudpickle.loads directly on data from the socket.
• CVE-2024-11041 (9.8): in v0.6.2, MessageQueue.dequeue() uses pickle.loads to parse received sockets directly.
• CVE-2025-29783 (9.0) and CVE-2025-32444 (9.8; GitHub scored it 10.0, NVD 9.8): the Mooncake integration deserialized over ZMQ/TCP sockets that were set to listen on all network interfaces. 32444 affects 0.6.5 through 0.8.4 and is patched in 0.8.5. Deployments not using Mooncake are not affected — a rare case where the advisory’s scoping is precise enough to act on directly.
• CVE-2025-47277 (9.8): the PyNcclPipe KV-cache transfer integration on the V0 engine, 0.6.5 through 0.8.4.
• CVE-2025-30165 (8.0) and CVE-2025-30202 (7.5): multi-node V0 deployments where secondary hosts open a SUB ZeroMQ socket, giving both code execution and data exposure paths.

Two entries break the pattern and are worth separating out. CVE-2025-24357 (8.8, fixed in 0.7.0) is a model-file bug, not a transport bug: hf_model_weights_iterator in vllm/model_executor/weight_utils.py called torch.load with weights_only left at its default of False. And CVE-2026-22807 (9.8, 0.10.1 to before 0.14.0) records vLLM loading Hugging Face auto_map dynamic modules during model resolution without gating on trust_remote_code, with CVE-2026-27893 (8.8) covering two model implementation files that hardcoded trust_remote_code=True. Those belong to a family this site has covered separately in trust_remote_code and the ML orchestration CVE class.

The practical reading: if you run single-node vLLM with no Mooncake, no PyNcclPipe and no KV-transfer backend, most of the 9-and-above entries above do not apply to you at all. If you run multi-node, the ZeroMQ surface is the thing to segment, and version currency is not optional.

Ollama: an unauthenticated API with a parser behind it

Ollama’s record splits into three groups, and only one of them is about model content.

Path and file handling. CVE-2024-37032 (8.8, before 0.1.34) is the anchor entry: Ollama did not validate that a digest was sha256 with 64 hex digits when deriving the model path, so a crafted manifest could push writes outside the intended directory. CVE-2024-45436 (7.5, before 0.1.47) is the classic zip-slip variant — extractFromZipFile in model.go could extract members outside the parent directory. CVE-2024-39722 (7.5) leaks which files exist on the host through path traversal in api/push.

Exposure and authentication. CVE-2024-28224 (6.6, before 0.1.29) is a DNS rebinding flaw that hands a browser-side attacker the full API. CVE-2025-63389 (9.8, up to and including v0.12.3) is more blunt: multiple API endpoints exposed with no authentication requirement at all. CVE-2026-5757 (7.5) allows unauthenticated remote heap-memory disclosure through the quantization engine.

GGUF parsing. A dense cluster of denial-of-service entries lands on the /api/create path where a crafted GGUF file is accepted: CVE-2024-39720 (8.2, a four-byte file is enough), CVE-2024-12055, CVE-2025-0312, CVE-2025-0315 and CVE-2025-0317 — those four all scored 7.5 and all cite versions at or below 0.3.14, while 39720 is fixed in 0.1.46. The class has not closed: CVE-2026-7482 (9.1, before 0.17.1) is a heap out-of-bounds read where a GGUF file declares tensor offsets and sizes exceeding the file’s real length.

A fourth group is easy to miss because it is not about the server at all. CVE-2026-42248 and CVE-2026-42249 (both 9.8) are in the Windows updater: the update-verification routine unconditionally returned success, and local file paths were constructed from attacker-controllable HTTP response headers. Desktop installs of inference tooling carry desktop-software risk.

llama.cpp: a C++ parser fed untrusted binaries

llama.cpp’s CVE history is the cleanest example in the ML stack of what happens when a hand-written binary parser meets files from the internet. The 2024 GGUF cluster — CVE-2024-21802, CVE-2024-21825, CVE-2024-21836, CVE-2024-23496 and CVE-2024-23605, each 9.8 — are five heap-based buffer overflows in five different fields of the same header format, all disclosed against one commit, all described as leading to code execution. These five are also the clearest illustration of why the scoring source matters: Cisco Talos, the CNA, scored each at 8.8 assuming user interaction; NVD re-scored all five at 9.8 with no interaction required. This site publishes the NVD analysis, so a scanner quoting the Talos numbers will disagree by a full point.

That class is still producing entries two years later: CVE-2025-49847 (8.8) in vocabulary loading, CVE-2025-53630 (8.9) an integer overflow in gguf_init_from_file_impl giving heap out-of-bounds read and write, and CVE-2026-33298 (7.8) bypassing memory validation through ggml_nbytes.

The RPC backend is a separate and worse surface. CVE-2024-42479 is scored 9.8 by NVD (10.0 in the GitHub advisory): an unsafe data pointer in the rpc_tensor structure permitting arbitrary address writing, fixed in b3561. CVE-2026-34159 (9.8, fixed in b8492) is the same lesson relearned — deserialize_tensor() skips all bounds validation when a tensor’s buffer field is 0, reachable unauthenticated. Like PyTorch’s distributed RPC, this backend assumes a trusted network and should never be exposed.

More recent entries have moved to llama-server itself: CVE-2026-43631 and CVE-2026-43632 (8.1) are unauthenticated use-after-free bugs in the idle-sleep path and six tokenization endpoints, and CVE-2026-43629 (8.1) is a heap overflow in KV-cache state restore. If you expose llama-server, build currency is a security control, not housekeeping.

One entry sits in the Python bindings rather than the C++ core and is frequently mislabelled: CVE-2024-34359 (9.6) is server-side template injection through the Jinja2 chat template in llama-cpp-python, not a GGUF parsing bug.

Triton: entries that arrive in coordinated batches

NVIDIA Triton Inference Server is the one runtime here whose entries arrive as coordinated vendor bulletins rather than as a trickle of individual advisories, which changes how you consume them: a single NVIDIA security bulletin can move a dozen IDs at once, so the useful unit of attention is the bulletin date, not the CVE. The August 2025 group alone included CVE-2025-23310 and CVE-2025-23311 (both 9.8, stack buffer overflow reachable through crafted input and crafted HTTP requests) and CVE-2025-23317 (9.8), described plainly as an attacker starting a reverse shell by sending a specially crafted HTTP request.

The Python backend is its own cluster: out-of-bounds writes in CVE-2025-23318 and CVE-2025-23319 (9.8 each at NVD, 8.1 in NVIDIA’s own bulletin), shared-memory limit and out-of-bounds read issues in CVE-2025-23320 and CVE-2025-23334, and memory corruption through the backend’s shared-memory region in CVE-2025-23329. The September 2025 batch topped it with CVE-2025-23316 (9.8): remote code execution by manipulating the model name parameter in the model control APIs.

That last one rhymes with CVE-2023-31036 (8.8), which required the non-default --model-control explicit flag and let an attacker use the model load API to write to an arbitrary path, and with CVE-2024-0087 (8.8), where the logging location could be set to an arbitrary file. Triton’s model-control plane is a code-execution surface by construction. It should not be reachable from anywhere a request can originate.

The three defects behind all of it

Runtime	Dominant defect class	Worst verified entry	The control that actually helps
vLLM	Object serialization as an internal transport	CVE-2025-32444, 9.8	Segment the ZeroMQ/KV-transfer plane; disable unused integrations
Ollama	Unauthenticated API plus GGUF parsing	CVE-2025-63389, 9.8	Bind to loopback; front it with authentication; upgrade
llama.cpp	Untrusted binary parsed in C++	CVE-2024-42479, 9.8	Never expose the RPC backend; track builds, not releases
Triton	Model-control plane that loads by name and path	CVE-2025-23316, 9.8	Disable explicit model control; isolate the HTTP endpoint

Read down the middle column and the ML-specific framing falls away. These are an insecure IPC transport, a missing authentication requirement, a memory-unsafe file parser, and a control API that turns a string into a filesystem operation. None of that is new; the novelty is only that it is now sitting on GPU hosts that many organisations treat as internal compute rather than as internet-facing services.

Three rules follow, and they generalise better than any per-CVE patch list:

1. The serving port is the perimeter. Every runtime here defaults to a listener. Decide deliberately what interface it binds to, and put authentication in front of anything that is not on loopback. A large share of the entries above are unexploitable against a service that is not reachable.
2. The model-control API is a code-execution API. Load, create, quantize, and update endpoints all turn attacker-influenced strings into file operations. Disable them in production, or restrict them to a separate authenticated path.
3. Currency is a control, and for llama.cpp it is build-level. Affected ranges here are given in build numbers (b3561, b8492, b9058), not semantic versions. A pinned container image from last quarter is a pinned vulnerability set.

For triage sequencing once you have a specific advisory in hand, the ML-stack CVE triage workflow covers how to decide whether an entry reaches your deployment before you schedule the patch, and reading an ML library CVE beyond the CVSS score covers why the base score is usually the wrong starting point for these.

Checking your own stack

To see which of these apply to the runtimes you actually run, with severity, fix availability and affected-version ranges side by side, use the ML stack CVE filter and select vLLM, Ollama, llama.cpp or Triton — or paste a requirements.txt and let it match packages for you. Three of the four runtimes discussed here publish affected ranges that do not map cleanly onto pip versions, so read the range text rather than trusting a scanner’s version comparison.

See also

• trust_remote_code and the ML orchestration CVE class
• LangChain security vulnerabilities: CVEs and what to patch — the same CWE-94 family one layer up the stack
• PyTorch security: notable CVEs and hardening the loading path
• AI CVEs in CISA KEV: Ray, LiteLLM, and what’s missing
• ML model CVE tracking across your AI stack