The pitch for running an AI model locally is straightforward: your prompts, your documents and your data never leave your machine, so a cloud provider's security posture, retention policy or breach history stops being your problem. Cyera's research into llama.cpp complicates that pitch without demolishing it - the risk hasn't moved to a cloud vendor, it just moved into a piece of C/C++ software that, as the researchers put it, "was never built for the weight it now carries."
One codebase, almost every local AI app
llama.cpp is not a niche dependency. Cyera's writeup lists Ollama, LM Studio, Jan and GPT4All as downstream consumers, alongside "hundreds of smaller projects" - which tracks with how the local-AI ecosystem has actually grown in 2026: very few teams write their own inference engine, almost everyone wraps llama.cpp in a friendlier interface and ships it. That concentration is exactly what makes a memory-safety bug in the underlying engine so disproportionate. A flaw here doesn't cost one vendor a bad week; it potentially touches every product built on top of it, on whatever release cadence each of those downstream projects happens to be running.
The bug that turns a power-saving setting into remote code execution
The clearest of the ten is CVE-2026-43631, a CVSS 9.2 use-after-free in llama-server's vocab pointer, tracked in GitHub's advisory database and affecting builds b7492 through b9060. It only triggers when the server's --sleep-idle-seconds option is enabled - a setting that exists purely to let an idle model release memory and save resources. An attacker who sends requests while the server is transitioning into that sleep state can cause a worker thread to dereference a vocab pointer that has already been freed, and reclaim that memory with attacker-controlled data. Turning on a resource-saving feature is, in other words, exactly what opens the door: no authentication required, network-reachable, and the researchers describe demonstrating exploitation by steering what ended up in the released memory once it was reclaimed - the foundation, as they frame it, for escalating from a crashed service to a controlled machine.
Two different ways to be exposed
Cyera's research splits the exposure into two distinct shapes, and they call for different responses. The first is the one most security teams would expect: a centralised server exposing model inference over an API, frequently without authentication and often running with more privilege than it needs. The second is easier to overlook - offline AI apps on mobile devices, where the vulnerable code executes with the full permissions and data access of the app itself. A memory-safety bug in an app that never touches the network still matters if the app it's embedded in can read your contacts, your files or your camera roll.
Half the fixes weren't ready when the research went public
The number that should concern anyone running local AI in production is not ten, it's five: at the time Cyera published, five of the ten vulnerabilities - including both critical, 9.2-rated flaws - remained unpatched. That is the awkward reality of responsible disclosure against a fast-moving open-source project maintained largely by volunteers: the research is thorough, the coordination happened, and the fix still isn't universally available the moment the advisory goes live. Anyone treating "we saw the CVE" as equivalent to "we're covered" is skipping the step that actually matters, which is checking whether their specific build has the patch yet.
- Inventory every product in your estate that bundles llama.cpp - directly or via Ollama, LM Studio, Jan, GPT4All or another wrapper - since the fix path runs through whichever of those you actually run, not through llama.cpp alone.
- Check your llama-server build against the b7492-b9060 range for CVE-2026-43631, and disable
--sleep-idle-secondson any exposed instance until you've confirmed a patched build. - Treat any llama.cpp-based inference server reachable without authentication as a priority fix regardless of which of the ten CVEs applies - the shared root cause across this research is exposure, not any single bug.
- For mobile or offline AI apps, remember the vulnerable code runs with the host app's own permissions - scope what that app can access as if the inference engine itself might be compromised.
- Track patch status individually rather than assuming disclosure equals remediation - five of Cyera's ten findings, both criticals included, were unpatched at publication.
Local AI was meant to be the option that sidesteps a whole category of vendor risk - a theme we've followed closely in our piece on NVIDIA NemoClaw's own local model server exposure. This research is a reminder that "runs on your own hardware" and "is somebody else's problem" were never the same claim. If you'd like help mapping where local AI tooling has quietly appeared in your estate, email sales@halfteck.com.