llama.cpp: Unauthenticated RCE in HTTP Server and RPC Backend

llama.cpp has become the infrastructure layer under a large fraction of the local AI ecosystem. Ollama, LM Studio, Jan, and dozens of custom deployments all bundle it. The project’s HTTP inference server and RPC backend let users run models locally, expose them to LAN-connected applications, or distribute inference across multiple machines. Two new high-severity vulnerabilities — CVE-2026-21869 and CVE-2026-34159 — show that those network-facing components were built with an assumption of trusted callers that doesn’t hold once they’re reachable from a broader network.

CVE-2026-21869: The n_discard Negative-Value Path

The first vulnerability lives in the HTTP server’s completion pipeline. When the KV cache — the memory structure that stores the context for an ongoing inference — fills up during a long conversation, llama.cpp needs to decide what to do with the overflow. One option is to discard some older context tokens to make room. The parameter controlling this is n_discard, which the server reads from the JSON body of completion requests.

The problem is the absence of a validation step. n_discard should always be a non-negative integer — you can’t meaningfully discard a negative number of tokens. But the server parses this value directly from caller-supplied JSON in server_task::params_from_json_cmpl() without a sign check.

What happens next is architecture-dependent but consistent. When the context actually fills up and the discard path triggers, llama_memory_seq_rm and llama_memory_seq_add receive the negative value as part of a range calculation. Those functions compute sequence positions using arithmetic that assumes non-negative inputs. With a negative offset, the computed memory addresses fall outside the intended buffer boundaries, and the write goes there anyway — deterministic out-of-bounds memory corruption.

The attack is straightforward to trigger:

POST /completion HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/json

{
  "prompt": "<long prompt that fills context>",
  "n_discard": -1,
  "n_predict": 100
}

Every endpoint that calls into the completion pipeline is in scope: /completions, /chat/completions, and /slots/{id_slot}/action with the resume action. CVSS scores between sources range from 8.8 to 9.8, reflecting disagreement over whether exploiting past a crash requires attacker-controlled layout conditions. What’s agreed: no authentication, no session, no prior access required. Network reachability to the port is the only prerequisite.

As of the advisory publication, an official patch is tracked in the GitHub security advisory for ggml-org/llama.cpp. Operators should pull the latest release and verify the fix for n_discard validation is included. Interim mitigation is to block access to the llama.cpp HTTP port from untrusted hosts — something that should have been the default posture regardless.

CVE-2026-34159: RPC Backend Deserialisation Bypass

The second vulnerability takes a different path to the same outcome. llama.cpp includes an RPC backend that allows multiple machines to collaborate on a single inference: the coordinator machine holds the model weights in layers, and worker machines handle the computation for some layers over a dedicated TCP port.

The bug is in deserialize_tensor(), the function that reconstructs tensor objects from the wire format when a coordinator sends work to an RPC worker. Tensors have a buffer field identifying which memory buffer the tensor’s data lives in. The deserialisation code was written with a conditional validation check — but the check only applies when buffer != 0. When buffer is exactly zero, the validation branch is skipped.

An attacker who can reach the RPC port with a crafted GRAPH_COMPUTE message can set buffer=0 and provide arbitrary offset values. The result is that the worker reads and writes arbitrary locations in its process memory, guided by the attacker’s offsets, with no bounds enforcement. Combined with the ability to control the offset values, this is a primitive for arbitrary process memory access.

The severity is rated CVSS 9.8 Critical. The attack requires TCP access to the RPC port — which in distributed inference setups is typically a port exposed on the LAN rather than loopback — but no further authentication or valid session state.

The Local AI Trust Assumption Problem

Both vulnerabilities reflect a design assumption that’s been present across the local AI inference ecosystem from the beginning: that whoever can reach the server port is trusted. The HTTP server defaults to binding on localhost in fresh installations, but documentation, tutorials, and convenience defaults routinely expose it on 0.0.0.0 for LAN access. The RPC backend is specifically designed for multi-machine use, which means it’s by definition accessible from at least one remote host.

This assumption made sense when llama.cpp was a researcher’s tool run on a single machine. It doesn’t hold for team deployments, home lab setups exposed over VPN, cloud instances running self-hosted models, or any configuration where the server is reachable from more than one machine. Neither CVE requires the server to be internet-facing. LAN exposure with a misconfigured or trusted-but-compromised host on the same network is sufficient.

The downstream exposure is broad. Ollama bundles llama.cpp directly. LM Studio ships with it. Any tool in the local model ecosystem that doesn’t implement its own network isolation layer inherits these vulnerabilities.

Mitigation

For CVE-2026-21869: Update llama.cpp to a build that includes the n_discard validation fix. Confirm the fix is present in any downstream tool builds before considering them patched. Restrict HTTP API access to loopback or a controlled interface with firewall rules — treat the inference API like an internal service, not a public endpoint.

For CVE-2026-34159: The RPC backend should not be exposed to untrusted networks. If you’re using distributed inference across machines, isolate the RPC port at the network level. Apply the patch tracked in GHSA-8947-pfff-2f3c when available for your build. Until then, firewall the RPC port to only the coordinator machine’s address.

Neither server should be accessible from the public internet. If your deployment requires remote access, proxy through an authenticated reverse proxy rather than exposing llama.cpp directly.

References

• GitHub Security Advisory GHSA-8947-pfff-2f3c — llama.cpp OOB Write in llama-server
• CVE-2026-21869 — llama.cpp Server RCE: Negative Parameter Triggers OOB Write — TheHackerWire
• CVE-2026-34159 — llama.cpp Critical RCE via RPC Deserialization Bypass — TheHackerWire
• CVE-2026-21869 — SentinelOne Vulnerability Database
• CVE-2026-34159 — SentinelOne Vulnerability Database
• llama.cpp CVEs — OpenCVE