Let me start with a confession. When I read that security researchers had found ten vulnerabilities in llama.cpp, my first thought wasn’t “how interesting.” It was “which one of these hits my box.”

I run llama.cpp. It’s the reason I can keep my documents on my own hardware and still have a model that reads them. So I read the full research report — Cyera’s, published 7 August 2026, the white paper behind their DEF CON 34 talk — and I’ll translate it here, because it was written for people whose first language is C++.

The thing under everything

If you’ve installed llama.cpp — I wrote a guide for that back in June (AI Guide: How to Install Llama.cpp onto your Desktop PC for Local AI) — you know it’s the engine. But the size of that “engine” is worth stating plainly. Ollama, LM Studio, Jan, GPT4All, a bunch of Android apps, and hundreds of smaller projects all run on top of it. More than 100,000 GitHub stars, and it’s the de facto standard for local inference.

That’s the car engine problem. Find a flaw in the engine and you’ve found a flaw in every car built on it. Patching one app doesn’t patch the others. They all call the same core, and it’s that core — where memory is allocated and freed by hand, with no garbage collector looking over the developer’s shoulder and, in a few places, no locking to stop one thread from tidying up while another is still working — that Cyera audited.

What they found, in plain English

Ten vulnerabilities, ten CVE numbers (CVE-2026-43622 through 43632, with 43625 skipped). Most of them are a bug class called use-after-free, and once you’ve seen it once you never forget it.

The mental model: a program has a notepad. It writes things on the notepad, finishes with it, and tosses the notepad into the recycling bin. All fine — except it keeps a pencil pointed at where the notepad used to be, and keeps writing there. The bin doesn’t stay empty for long. The program reuses that paper for the next job, so whatever is now written on the “notepad” belongs to somebody else.

An attacker who can control what gets written into the recycled paper controls what the program reads next. And in the worst case, that’s not a crash. That’s the attacker’s instructions.

Three families, roughly in order of how much I cared:

The nap bug. The worst one, and it’s in the server. llama-server has a power-saving feature: `–sleep-idle-seconds`. Leave it idle for N seconds and it unloads the model from memory to save RAM. Sensible. Except “unload” means free — that memory goes back into the bin. If a request arrives at the exact moment the server is going to sleep, a worker thread is still holding a pencil pointed at the freed model, and it goes to read the recycled paper. Cyera demonstrated they could plant their own data in that freed space — roughly once in every hundred attempts in their testing — and make the processor read attacker-controlled values. Both variants of this scored 9.2 out of 10 on the current severity scale. That’s “take it offline” territory.

The kicker: llama-server runs without authentication by default, and is commonly pointed at the whole network on port 8080. So the nap bug needs no password at all.

The phone bug. Android apps that run models locally lean on a shared sample integration, and it has the same toss-the-notepad-while-someone’s-reading-it problem — one part of the app frees the model while a background thread is still mid-inference. Cyera went further than showing a crash. They built a working takeover of the app, steering it toward the app’s private files and its stored credentials. Rated 7.3. If you’re running one of those “local, no cloud, no internet” Android apps — and there are several — that claim is worth a second look.

The file and math bugs. The rest of the list is smaller cousins: an unchecked multiplication that can overflow when the program sizes a buffer, an overflow when restoring saved model state, and an out-of-bounds read that’s since been patched upstream. The model-file one deserves a line for our readers: a .gguf model file tells the program how big its contents are, and the program historically trusted those numbers. A crafted model file can push the program past its fences. So treat a downloaded model file the way you’d treat an email attachment. Trusted sources only.

The part that made me shake my head

The bugs are one story. The response to them is the other.

Cyera first reported these to the llama.cpp project in July 2025. Over a year before this was published. GitHub security advisories were opened, and several were closed without a fix — one in January 2026, another in May. They chased MITRE, the body that hands out the CVE numbers, from October 2025 through months of follow-up, and collected request IDs but no numbers. In the end they went to VulnCheck, a commercial vulnerability firm, which assigned the ten CVEs on 7 May 2026.

Then they re-checked the latest build in June 2026, and five of the ten were still open — including both of the 9.2 server bugs. So Cyera did what any decent researcher does when the maintainers won’t: they published the fixes themselves. The patches are on GitHub, and the full exploitation detail is on stage at DEF CON 34.

I won’t sit on the blame question long. Open-source projects are staffed by volunteers juggling day jobs, and the sleep feature that created the nap bug only landed in December 2025 — months after the first report was already sitting in the project’s queue. That’s context, not an excuse. But it is the reminder: “open source” and “maintained” are not the same phrase.

What you should actually do

Depends on who you are.

If you’re a solo user — llama.cpp or LM Studio on a desktop, talking to your own machine.

Your risk is low, and a good chunk of it is already handled if you did the install the way I showed you: the server bound to localhost means nothing else on your network can reach it. Three habits:

1. Update when the apps you use — LM Studio, Ollama, Jan — ship a new llama.cpp build. That’s the only real fix for the rest of it.
2. Keep the port bound to localhost. The moment you point it at your LAN “just for convenience,” you’re no longer a solo user.
3. Download .gguf models from sources you’d trust with a USB stick. A Hugging Face page with thousands of downloads beats a random mirror site every time.

If you run a homelab — my category, a box in the rack.

This is where the nap bug bites. Check your launch command:

ps aux | grep llama-server

If you see `–sleep-idle-seconds`, make a decision. That feature exists for shared GPU boxes where models take turns using the VRAM. If you’re the only one on the box, it’s buying you nothing and handing out a 9.2-rated race window — pull the flag.

If you do need it — multiple models, tight VRAM — then the port needs a lock: an authenticating reverse proxy in front, or at minimum a VPN boundary so the people on your LAN can’t just talk to it. I run mine behind Tailscale, which is the difference between “the internet” and “people I’ve let in” — but the flag check is the part that matters. (I went through the server side of this in The Private Local AI Server Install.)

And update the build. If you’re on something older than the gguf-v0.19.0 era, the out-of-bounds read is at least fixed upstream; the five that are still open are covered by Cyera’s community patch repo, if you want to go that far.

If it’s a shared office environment — a team pointing their tools at one local endpoint.

Treat the box like any other server that people can touch. It ships with no authentication, and that “ships with” is going to survive a lot of deployments:

• Put it behind a lock. Reverse proxy, SSO, whatever the office already uses. Not “trust me, it’s internal.”
• Segment it. The AI box doesn’t need to sit on the same flat network as the guest Wi-Fi or the IoT devices.
• Patch on a schedule. The open CVEs will get fixed eventually; the version you’re on today might be the one with the holes in it.
• Watch for the tell. The nap bug’s signature is worker crashes at near-zero memory addresses after idle periods. If your logs show that pattern, you don’t have a flaky GPU. You have a use-after-free.

The honest asterisk

None of this changes the deal that made local AI worth it in the first place. Your prompts still don’t leave the building. Your documents still don’t end up in someone else’s datacentre. The privacy promise held — what failed was the lock on the door, not the walls.

That’s the distinction worth keeping straight. Local means your data doesn’t leave. It has never meant the software is unexploitable. Any C++ codebase is going to have these bugs; the interesting question was never whether llama.cpp had them. It was whether the people running a no-auth server on an open port got told about the worst of them, and given a chance to act.

They’ve been told now. The report’s out, the patches are out, the CVEs are real. So the only sin left to commit is running an old build with the nap switch on and the door open.

I’m checking my own box this week. I’ll let you know if the flag check turns up anything.