CVE-2026-21869 is an out-of-bounds write in the llama.cpp server, scored 8.8 (High). A negative n_discard value in a completion request is not rejected, which can corrupt memory, crash the process or lead to code execution. The advisory lists commit c78fb90 or later as patched, so rebuild from a current commit and keep the server off untrusted networks.
What's affected
- Product: llama.cpp, the llama-server component (ggml-org)
- Affected: builds at commit 55d4206c8 and earlier
- Fixed: commit c78fb90 and later, per the GitHub advisory
- Entry points named in the advisory: the completions and chat completions endpoints and the slots restore path, anything that parses request parameters through the shared completion code
- Status: not in the CISA Known Exploited Vulnerabilities catalog
The NVD record said no fix was available at publication. The GitHub advisory, which we checked, now lists the patched commit. Note the advisory itself rates the issue Low in its own header, while NVD scores it 8.8. Read both when you set priority.
How to check if you're exposed
llama.cpp is usually built from source or pulled as a container image, so the version is a commit, not a release number. Ask the binary what it was built from:
llama-server --version
Recent builds print a build number and a commit hash. If the commit is 55d4206c8 or older, or you cannot tell, treat it as affected. For container images, check the tag or digest against the project's repository and rebuild if it predates the fix.
Then check exposure. The risk is highest when the server listens on a non-local address, or when it sits behind a gateway that passes request bodies through unchanged. Look at the bind address and any reverse proxy in front of it.
What to do now
- Find every llama-server instance, including those started by wrappers, notebooks and containers.
- Rebuild from commit c78fb90 or later, or pull an image built from one. Confirm with the version output.
- Bind the server to localhost or a private network, and put an authenticating proxy in front of anything shared.
- If requests are filtered upstream, reject a negative n_discard value as a stopgap, but do not rely on it in place of the update.
- Restart the process after updating and watch for crashes in the meantime, since a crash is a likely sign of malformed input.
Why it matters
The context window of a language model fills up as a conversation grows. When that happens, the server can discard part of the history and shift the rest to make room. The number to discard comes from the request. The advisory says the server read n_discard straight from the JSON body and never checked that it was non-negative.
With a negative value, the shift routine received a reversed range and a negative offset. That caused writes outside the intended memory region while the server evaluated tokens, which is the pattern behind CWE-787, out-of-bounds write. The advisory describes the result as deterministic, so a crash is easy to trigger, and the record says it can enable remote code execution too.
This is a general warning for AI infrastructure. Inference servers are native code that parses request fields from the network. They deserve the same patching and exposure review as any other network service, and they are often deployed without either.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is a negative number in the request the only trigger?
The advisory names the n_discard parameter and a full context as the conditions. Treat any request path that reaches the shared completion parser as in scope until you have updated.
Can I just block it at the proxy?
You can reject a negative n_discard as a temporary measure, but updating to the patched commit is the real fix.
Sources
Last reviewed: 19 October 2026.