On 6 August 2026, NVD published CVE-2026-43631, a use-after-free in llama-server, the HTTP server bundled with llama.cpp. A day later Cyera released its research, titled "Breaking Local AI Runtimes", covering ten llama.cpp vulnerabilities and presented at DEF CON 34. Two of them, 43631 and CVE-2026-43632, score 9.2 under CVSS 4.0 and 8.1 under CVSS 3.1, and both were still unpatched when Cyera re-checked on 1 June.
The GitHub advisory for 43631 lists no patched version. That makes configuration, not upgrading, your main defense for now.
What's affected
CVE-2026-43631 affects llama.cpp builds b7492 through b9060 when llama-server runs with the --sleep-idle-seconds option. In that mode the server unloads an idle model and reloads it on the next request. A request that arrives during the sleep transition can make worker threads dereference a freed vocab pointer. NVD says that pointer can be reclaimed with attacker-controlled data, which allows unauthenticated remote code execution. The weakness is a race condition, CWE-362.
CVE-2026-43632 is a second use-after-free in llama-server, in vocab access outside the main task queue. It is reachable through endpoints such as /tokenize, /detokenize, /infill, /apply-template, /rerank and /anthropic/count_tokens. Cyera tested master-tagged builds and checked against build b9445.
Cyera's findings run from CVE-2026-43622 to CVE-2026-43632 (43625 was not used). Its write-up gives details for these:
| CVE | Component | Type | Status at 1 June check |
|---|---|---|---|
| CVE-2026-43626 | Android JNI sample | Use-after-free race | Partially patched (b7446) |
| CVE-2026-43627 | llama_batch_init | Integer overflow | Unpatched |
| CVE-2026-43629 | KV cache slot restore | Overflow | Unpatched |
| CVE-2026-43630 | State save and restore | Out-of-bounds read | Patched in gguf-v0.19.0 |
| CVE-2026-43631 | llama-server sleep teardown | Use-after-free | Unpatched |
| CVE-2026-43632 | llama-server vocab access | Use-after-free | Unpatched |
Cyera says it reported issues through normal channels, several reports were closed without a fix, and CVE assignment stalled for months. It then worked with VulnCheck, which reserved the IDs on 7 May, and published its own patches for the open findings in a public repository.
How to check if you're exposed
Find llama-server instances and how they are started:
ps aux | grep -E "llama-server|llama_server" | grep -v grep
ps aux | grep -e "sleep-idle-seconds" | grep -v grep
Check the build number the server reports:
llama-server --version
Then check where it listens, because exposure depends on the bind address:
ss -ltnp | grep -E "llama|:8080"
A listener on 0.0.0.0 or a public interface with no authenticating proxy in front is the risky shape. Search your container images and compose files for the flag:
grep -rn "sleep-idle-seconds" docker-compose*.yml k8s/ helm/ 2>/dev/null
Many tools embed llama.cpp without saying so, so check your inference stack's SBOM for it, and for build numbers in the b7492 to b9060 range.
What to do now
- Remove
--sleep-idle-secondsfrom any llama-server that accepts requests from untrusted networks. This takes out the 43631 trigger. - Never expose the API on
0.0.0.0without an authenticating reverse proxy. Bind to loopback or a private address. - Put the server behind a proxy that blocks the tokenizer and template endpoints from untrusted callers if you cannot restrict the whole API.
- Do not restore slot or state blobs from untrusted writers (relevant to CVE-2026-43629).
- Watch for repeated worker crashes with low-address faults after idle periods. Cyera suggests they may signal a sleep-related use-after-free.
- Review Cyera's published patches for the five open findings before deciding whether to build with them.
- Track the project's builds for fixes and recheck after each update.
How this could have been avoided
- Do not expose inference servers directly. Both critical bugs are reachable over unauthenticated HTTP. An authenticating proxy and loopback binding would have put a gate in front of them.
- Keep experimental features off in production. The sleep-idle option is the entire trigger for 43631. Features that change object lifetimes deserve a staging period.
- Treat model runtimes as parsers of untrusted input. GGUF metadata, slot blobs and tokenizer requests all feed memory-sensitive code. Isolate them in a container with no secrets and read-only mounts.
- Fuzz and review concurrency in the server lifecycle. The race was introduced in December 2025 according to Cyera's timeline, and sat in the master branch for months.
- Have a path for orphaned disclosures. The project closed reports, and the CVE process went through VulnCheck. Consumers should track advisories from more than one source.
Why it matters
Local AI tooling often starts as a laptop experiment and then becomes a shared service on a team server. The security model shifts from "my machine" to "anyone who can reach this port", while the defaults stay the same.
The disclosure story matters as much as the bug. With no vendor patch and no clear fixed version, standard upgrade-driven vulnerability management stops working. You need an inventory of where llama.cpp runs, how it is configured and who can reach it, so that you can reduce exposure without waiting for a release.
The same applies to anything you pull in as a library. Applications that embed llama.cpp inherit these issues, and the vulnerable build number may not appear in their own version string.
Quick check
Which llama-server option triggers CVE-2026-43631?
--sleep-idle-seconds. The use-after-free happens when requests arrive while the server transitions to sleep.
Is there an upstream patched version for CVE-2026-43631?
The GitHub advisory lists none. Cyera published its own patches, and the safest steps are to disable the option and keep the server off untrusted networks.
