GPU VulnDB

Database/AI/ML frameworks & serving

llama.cpp rpc-server: oversized RPC message length aborts the process, denying service to all clients

CVSS 8.7CVE-2026-119052AI/ML frameworks & servingcurated

Impact

An unauthenticated client that can reach a ggml rpc-server port can kill the process with a single malformed command. After the HELLO handshake, a SET_TENSOR (or similar) command declaring a length above std::vector::max_size() raises an uncaught std::length_error and aborts. On a GPU fleet the rpc-server is what stitches remote GPUs into a distributed llama.cpp inference job, so the abort takes down the shard and every client depending on it; in-flight work on that node is lost and the model has to be reloaded into GPU memory. The RPC backend has no authentication of its own, so anything that can route to the port can do this repeatedly.

Who can reach it

Anyone who can open a TCP connection to the rpc-server port. No authentication or credentials required - the HELLO handshake is not an authentication step. In practice this means any tenant or workload sharing the network segment the RPC port is bound to.

What to do

Upgrade to llama.cpp b11935 or later (fix in commit 7ecb57f) and restart the rpc-server processes - a daemon restart per serving node, no reboot. Until then, keep RPC ports bound to loopback or a trusted private subnet and never expose them to tenant-reachable networks; the ggml RPC backend is documented as not hardened for untrusted input.

References

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.