SHRIKEAfter Bleeding Llama, the Agent Still Has No Boundary
In February, Cyera's researchers reported an out-of-bounds read in Ollama's model creation path. An unauthenticated caller could upload a crafted model file to endpoints that shipped without authentication and read back the server's process memory: user prompts, system prompts, and environment variables, credentials included. Ollama acknowledged the report and proposed a fix on February 25; the CVE, CVE-2026-7482 at CVSS 9.1, was published on May 1. At disclosure, roughly 300,000 Ollama servers were reachable from the internet in the default configuration (Cyera's write-up has the full timeline).
If you run Ollama, you have patched by now, and if you have not, stop reading and do that. This post is about the two things that stay true after the patch.
The memory held the prompts
Bleeding Llama leaked what was in the process, and what was in the process was everything the agent had said to the model: the system prompt with its instructions, the user's messages with whatever they contained, the environment with its keys. None of that is unusual. A serving engine has to hold the prompt to serve it. The lesson is about everything else in the pipeline that also holds the prompt, and holds it longer.
Every component added around a local model, the classifier, the validator, the rails, the logger, sees the prompt too, and most of them keep a copy. Each copy is a Bleeding Llama waiting for its own CVE. The design question to ask of any governance layer is therefore not only "what does it catch" but "what does it keep". The answer we hold ourselves to: for a safe interaction, nothing. Shrike stores a hash plus metadata for safe scans and retains only violation records, encrypted, for audit. A governance layer that needs the prompt to decide does not need the prompt to remember.
The patch restored the engine, not the boundary
After the update, the server is whole again. The agent behind it is in exactly the state it was in before the vulnerability: a local model, serving completions to something that acts on them, with no screen between a poisoned input and the action. The vulnerability was in the engine. The exposure that matters day to day is in the agent, and no Ollama release addresses it because it was never Ollama's job.
This is the second half of self-hosted LLM security, and it is the half the patch cycle never touches. A local model ships with no provider guardrails: no policy check on what the agent is about to do, no scope for what it is for, no hold for a person before a consequential action, no record of what was decided. Those controls belong at the boundary the deployer owns, and they are the same controls a hosted model needs. The difference is that on a hosted API somebody was running a version of them, and on a local stack nobody is.
What to do this week
- Confirm the patch and the binding. Ollama on a private interface or behind authentication; the fix installed; the same check for vLLM and llama.cpp, which carried their own advisories this year.
- Inventory who else keeps the prompt. Every component in the pipeline that logs or caches request bodies is a second copy of the same exposure. Keep the ones that need it, and make the rest store a hash.
- Put a boundary behind the endpoint. A policy check before the action, a declared scope, an approval hold, and an evidence record. The local models guide shows the one-line integration; the reasoning is on self-hosted LLM security.
Ollama did the right thing with the report and the fix. The residual risk after a patch like this is not the vendor's to carry. It belongs to whoever put an agent behind the model, and it was there before the CVE and is there after it.