CVE-2026-118375 lets a peer advertising RDMA write 256 KiB into a 1-byte stack variable; CVE-2026-119052 aborts the server. Update every node to b11935 and keep the RPC port off open networks.
Two vulnerabilities in the RPC backend of llama.cpp let an unauthenticated network peer attack rpc-server, the worker process used to spread a model across several machines. CVE-2026-118375 is a stack buffer overflow in the RDMA transport that VulnCheck scores 9.2 (CVSS 4.0) and which could in principle lead to code execution. CVE-2026-119052 lets any peer crash the server with one oversized message. Both are fixed upstream: update to build b11935 or later, which covers both.
Who is affected
Anyone running ggml-rpc-server (the RPC worker) from llama.cpp builds in the affected ranges. CVE-2026-118375 covers b8841 up to, but not including, b11865. CVE-2026-119052 covers b2877 up to, but not including, b11935. The head node running llama-server with --rpc is the client; the workers listening on a port are the exposed side.
The typical user is someone pooling memory across boxes. One NVIDIA forum post from June describes two DGX Spark systems linked over a 200GbE ConnectX-7 port, running a roughly 188 GiB GGUF through llama.cpp RPC, and reports that "RoCEv2 RDMA auto-activated". That is exactly the transport involved in CVE-2026-118375. The README shows any multi-host setup through --rpc host:port,host:port; we found no source on Mac clusters specifically.
We found no source saying Ollama, LM Studio or other downstream apps bundle rpc-server or an affected build, so we make no claim either way. If you use a wrapper, check which llama.cpp build it ships and whether it exposes the RPC worker.
CVE-2026-118375: stack overflow in the RDMA receive path
The flaw is an out-of-bounds write (CWE-787) in rdma_recv() in the ggml-rpc RDMA transport. A peer that advertises RDMA capability in its HELLO message can send up to 256 KiB into a 1-byte stack variable in rpc_serve_client(). The advisory says this can crash the server or potentially execute code.
The scores are VulnCheck's: CVSS 4.0 9.2 Critical and CVSS 3.1 8.1 High. NVD had not yet analysed the record at last check. CISA's SSVC entry (3 November) lists exploitation as none, automatable as no, and technical impact as total. The attack needs the target to be reachable and to take the RDMA path, which is why the 3.1 vector rates complexity high.
The fix, PR #30399, merged on 24 October. The code copied each completion into the buffer without checking that wc.byte_len fits the remaining space. The patch adds that check, logs the error, reposts the receive slot and closes the connection. The author reproduced a stack-buffer-overflow under AddressSanitizer on SoftRoCE before the fix. VulnCheck lists no workaround.
CVE-2026-119052: one oversized message kills the server
After the HELLO handshake, an attacker can send a command such as SET_TENSOR with a length header above std::vector::max_size(). The server tried to resize its buffer, hit an uncaught std::length_error (CWE-248) and aborted, which drops every client. VulnCheck scores it 8.7 (CVSS 4.0) and 7.5 (3.1), availability only. CISA's SSVC entry marks it automatable, with no known exploitation.
PR #31204, merged 27 October, catches the exception, logs it and drops only the offending connection. The author tested with a maximal 64-bit size header in plain and ASan builds, and the server kept serving other sockets.
Both flaws are fixed in b11935, merged within three days of each other in late October.
What to do
- Update every node to b11935 or later. It contains both fixes. The RPC protocol version must match across nodes, so upgrade head and workers together.
- Do not expose the port. Upstream's README says "Never run the RPC server on an open network or in a sensitive environment!" and calls the backend a proof of concept. The project's security policy says not to use the RPC backend on untrusted networks. Put workers on a dedicated cluster link or VLAN and firewall the port (50052 in the examples) to the head node's address only.
- Check what the worker listens on. The README documents no bind-address flag and does not state the default, so verify with
lsoforssrather than assuming localhost. A single-machine setup should not need the port reachable from anywhere else. - Consider forcing TCP until patched. The README says setting
GGML_RPC_NO_RDMAon either peer forces TCP. This is our reading rather than vendor guidance: the overflow is reached by a peer advertising RDMA, so disabling it on the worker should avoid that path, but it does not help against CVE-2026-119052, and you should test it. Patching is the real fix. - Watch for unexpected worker exits. Repeated aborts of
rpc-serverare the visible symptom of CVE-2026-119052.
Neither CVE has known exploitation per CISA's entries, but the RPC server has no authentication to fall back on, so network placement is the control that matters. For another llama.cpp flaw fixed in October, see our coverage of CVE-2026-116816, a crafted GGUF file that corrupts the heap on load.