# Breaking Local AI Runtimes: 10 llama.cpp flaws, five unpatched

> Five of the ten llama.cpp flaws Cyera reported were still unpatched when the researchers re-checked in June 2026.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Talk, Vulnerability
- **Published by:** DEF CON
- **Disclosed:** 2026-11-06
- **CVE:** CVE-2026-43631
- **CVSS:** 9.2
- **Affects:** llama.cpp, llama-server
- **Research by:** [Vladimir Tokarev](https://github.com/Vladimir-tokarev-cyera) (Cyera), Ofek Itach (Cyera)
- **Primary source:** https://www.youtube.com/watch?v=_FKX5hDwgVE
- **Page:** https://theinjection.dev/items/cyera-breaking-local-ai-runtimes/

Breaking Local AI Runtimes is a DEF CON 34 talk by Cyera's Vladimir Tokarev and Ofek Itach on 10 llama.cpp vulnerabilities. Five were still unpatched at their June 2026 re-check. DEF CON published the video on November 6.

## What happened

DEF CON published the video of Breaking Local AI Runtimes on November 6, 2026. Vladimir Tokarev and Ofek Itach of Cyera Research presented 10 llama.cpp vulnerabilities at DEF CON 34 and released a companion white paper on August 7, 2026. Cyera says it could not complete coordinated disclosure with the maintainers, so VulnCheck assigned the CVE ids.

## How it works

The sharpest flaw is a use-after-free on llama-server's cached vocabulary pointer. When the idle-sleep feature calls destroy(), that pointer is left dangling, and a request that already passed the sleep check then tokenizes through freed memory an attacker can reclaim with controlled data. A second flaw is a race in the Android JNI wrapper: process-global native pointers are shared across JNI calls, so freeing the context while a background thread runs inference frees memory still in use.

## Who is affected

Operators who run llama-server with the idle-sleep feature turned on face the unauthenticated use-after-free, and Android apps built on an older llama-android.cpp wrapper face the JNI race. Build ranges are listed below. Cyera describes llama.cpp as the engine behind Ollama, LM Studio, Jan and GPT4All, so a downstream tool can ship the vulnerable code.

## What to do

Do not enable --sleep-idle-seconds on a llama-server host that accepts untrusted HTTP, and do not expose the API on 0.0.0.0 without an authenticating reverse proxy. Replace any llama-android.cpp wrapper older than build b7446. Do not restore slot or state blobs from untrusted sources, because Cyera reports CVE-2026-43629 is still open.

## Watch

[DEF CON 34, DEF CON on YouTube](https://www.youtube.com/watch?v=_FKX5hDwgVE)

## Quick facts

- **Affected:** llama.cpp builds b7492 to b9060 for the llama-server sleep use-after-free; builds b1886 to b7445 for the Android JNI race
- **CVEs:** CVE-2026-43622 to CVE-2026-43632, excluding CVE-2026-43625, which Cyera says was not used
- **Fixed in:** gguf-v0.19.0 fixes CVE-2026-43630; Cyera reports five of the ten still unpatched at its June 1, 2026 re-check
- **CVSS:** 9.2 CVSS v4.0 and 8.1 CVSS v3.1 for CVE-2026-43631, assigned by VulnCheck
- **Found by:** Vladimir Tokarev and Ofek Itach, Cyera Research
- **Talk:** DEF CON 34, video published November 6, 2026
- **Mitigation:** Cyera published patches for the five findings the maintainers left open

## Questions

### Is llama.cpp patched against the llama-server use-after-free?

No. Cyera reports that CVE-2026-43631 remained unpatched when the researchers re-checked llama.cpp at build b9445 on June 1, 2026, and the advisory lists no fixed release. Only CVE-2026-43630 has a fix, in gguf-v0.19.0. Cyera published its own patches for the five findings the maintainers left open, so operators can apply those or avoid the idle-sleep feature.

### Am I affected if I run Ollama or LM Studio instead of llama.cpp directly?

Cyera describes llama.cpp as the inference engine behind Ollama, LM Studio, Jan and GPT4All, so a downstream tool can ship the vulnerable code. The white paper measures the flaws against llama.cpp builds, not against each downstream product, so check which llama.cpp build your tool bundles rather than assuming a packaged release carries the fix.

### How do I tell whether a llama-server crash is the sleep use-after-free?

Cyera advises treating repeated worker crashes at low memory addresses after idle periods as a possible sleep use-after-free signal. The bug only fires when the --sleep-idle-seconds flag is set, so check the server's launch arguments first. Cyera also notes llama-server runs without authentication by default and binds to 0.0.0.0:8080, which decides who can reach the endpoint at all.

## Sources

1. [Watch The Talk](https://www.youtube.com/watch?v=_FKX5hDwgVE)
2. [Cyera White Paper](https://www.cyera.com/research/breaking-local-ai-runtimes-10-vulnerabilities-in-the-engine-behind-your-open-source-models)
3. [CVE-2026-43631](https://www.cve.org/CVERecord?id=CVE-2026-43631)
4. [Cyera Patches](https://github.com/Vladimir-tokarev-cyera/llama-cpp-security-patches)