Cyera Discloses 10 llama.cpp Memory-Safety Vulnerabilities
Cyera disclosed 10 vulnerabilities in llama.cpp, the inference engine embedded in many local AI tools, after presenting the research at DEF CON 34. VulnCheck assigned 10 CVEs, and Cyera says five remained unpatched in its June 1 check, including two llama-server use-after-free flaws scored 9.2 under CVSS 4.0. Operators should inventory downstream use and restrict untrusted network access.
What the research found
Cyera published research presented at DEF CON 34 describing 10 vulnerabilities in llama.cpp, a widely integrated C and C++ inference engine used by local-model tools and applications. VulnCheck allocated 10 CVEs across the range CVE-2026-43622 through CVE-2026-43632, with CVE-2026-43625 unused, according to Cyera.
The findings span three trust boundaries: Android JNI integrations, the llama-server HTTP lifecycle, and GGUF model metadata processing. Cyera reports use-after-free conditions, integer-overflow bugs, and out-of-bounds memory access. Two llama-server findings, CVE-2026-43631 and CVE-2026-43632, received CVSS 4.0 scores of 9.2.
Cyera says that, as of a June 1 check against llama.cpp build b9445 and gguf-v0.19.0, five of the 10 findings remained unpatched. The researchers published their own patches for those five issues; that is not the same as confirmation that every downstream product has adopted an upstream fix.
Where the exposure comes from
One class of bugs involves native object lifetime. Cyera describes Android integrations in which one thread can continue using a native context while another frees it. A related llama-server race can occur when the --sleep-idle-seconds feature unloads model and vocabulary state while another request still depends on that memory.
Other findings concern metadata and size handling in GGUF and state-processing paths. These bugs matter beyond developers who compile llama.cpp directly because the library sits underneath desktop, mobile, and server products. Whether a particular product is exposed depends on its bundled version, enabled features, network configuration, and ability to accept untrusted model files, state, or HTTP requests.
What operators should do
Cyera recommends not enabling --sleep-idle-seconds on hosts that accept untrusted HTTP until the relevant use-after-free flaws are fixed and the deployed build is verified. It also advises against exposing llama-server on 0.0.0.0 without an authenticating reverse proxy or equivalent control, and urges Android integrators using the older JNI wrapper to move away from builds before b7446.
For platform teams, the immediate task is inventory: identify products and services that embed llama.cpp, record their bundled build, and determine whether untrusted traffic or artifacts can reach the vulnerable paths. Local inference keeps prompts on infrastructure you control, but it also moves responsibility for native-code patching, isolation, authentication, and monitoring onto the operator.
Key Points
- 1Cyera reported 10 llama.cpp vulnerabilities across Android JNI, llama-server lifecycle, and GGUF metadata paths.
- 2Five findings remained unpatched in Cyera's June 1 build check, including two server use-after-free flaws scored 9.2 under CVSS 4.0.
- 3Teams should inventory embedded llama.cpp versions, limit untrusted network exposure, and verify fixes rather than assuming local inference is inherently isolated.
Scoring Rationale
Ten disclosed native-code vulnerabilities in a widely embedded local-inference engine create material patching and exposure-management work, with several findings still unpatched in the researcher's latest stated check.
Sources
Primary source and supporting public references used for this report.
Practice interview problems based on real data
1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with.
Try 250 free problems
