Ollama Agent Mode Bash Approval Bypass - CVE-2026-102697
The short version: Ollama's experimental agent mode could run commands you never approved. CVE-2026-102697 affects Ollama 0.14.0 up to 0.31.2 when ollama run --experimental is used, and it is fixed in 0.31.2. If you run Ollama anywhere, upgrade it. If you do not know where Ollama runs, that is the first gap to close.
The CVE record was published on September 29, 2026 and credits Akıner Kısa. GitHub's advisory database rates it High, CVSS 3.1 7.8 (CWE-863, incorrect authorization). VulnCheck lists a CVSS 4.0 score of 8.5. The fix itself is older: it shipped in 0.31.2 on July 6, 2026.
What to do first
- Upgrade Ollama to 0.31.2 or later on every machine, and restart running
ollamaprocesses. - Find the developers who use agent mode (
--experimental) and confirm they are on a fixed build. - Treat any local agent loop with a Bash tool as able to run commands on that laptop, whatever the approval prompt says.
- Add local LLM runtimes to the same inventory and patch process as coding agents and MCP servers.
How Anomity surfaces and governs it
See it. The Endpoint Sensor inventories local LLM runtimes, including Ollama, alongside coding agents, CLIs, MCP servers, extensions and secrets, with versions per endpoint. An Ollama below 0.31.2 shows up as a named machine and a named version, which a network scan of developer laptops will not give you. Secrets are redacted on the endpoint and only metadata leaves it.
Enforce it where a hook exists. For agents that expose a pre-execution hook, such as Claude Code PreToolUse, Anomity returns allow, deny or log before a tool call runs. That decision is made on the call, not on a string prefix a session remembered. Decisions and inventory changes land in a 90-day audit trail and route to SIEM, Slack, email or Jira.
What happened
ollama run <model> --experimental turns on what the CLI describes as an "experimental agent loop with tools," including a Bash tool. Before running a command, Ollama asks the user to approve it, and the user can allow it for the rest of the session. For a set of read-oriented commands (cat, ls, head, tail, grep, find, sed and a few others), the vulnerable code did not remember the exact command. It remembered a prefix made of the command name and the directory of its first path argument, such as cat:tools/, and auto-approved any later command that produced the same or a child prefix.
The flaw was in how the prefix was extracted. The code took the text before the first |, split it on whitespace and read the first word as the command. It never treated ;, && or || as the end of a command. So once cat tools/main.go was approved, a later command shaped like this still produced the prefix cat:tools/ and ran without a prompt:
# approved once for the session
cat tools/main.go
# later, injected into the model's output: same prefix, no new prompt
cat tools/main.go; <any command the attacker wants>Commands with no path argument fell back to the current directory, so approving something as plain as cat README.md produced the prefix cat:./. The advisory describes the result directly: attackers who can influence model output through prompt injection can append control operators to approved commands and bypass the session approval requirement.
Why string-matching approvals keep failing
This is the same family of bug that keeps appearing in coding agents: an approval or deny decision made on a text pattern while the shell executes a grammar. Claude Code's changelog for the first days of October lists fixes for deny rules missing commands behind an environment-variable prefix, covered in our CVE-2026-103012 analysis. Different products, same gap between what the matcher reads and what the shell runs.
Local runtimes make it worse in one respect. Ollama is often installed by a developer, not by IT, and its agent mode is an opt-in flag on a laptop. Hosted-model safeguards do not apply to a local model, a point we made about open-weight models running on local runtimes. The only control left is the one on the tool call.
A quiet fix, a late CVE
The patch is commit a2b3a5e, titled "agent: harness core", which removed the experimental approval code and replaced it with a new agent package. It shipped in 0.31.2 on July 6, 2026. The 0.31.2 release notes list GPU, model-loading and engine changes, and do not call out a security fix. The CVE arrived about twelve weeks later.
That pattern is common, and it is why version inventory beats advisory-watching. A team that only patches on CVE publication had no reason to move off 0.31.1 until September 29. A team that knows every Ollama version on every endpoint can answer "are we exposed?" in minutes. For Ollama's earlier issues in the same runtime, see Bleeding Llama, CVE-2026-7482 and the model-pull SSRF, CVE-2026-5530.
What to check across your fleet
- Every Ollama install and version, including machines where it was installed by hand.
- Which users run agent mode or the
--experimental-yoloflag, which skipped all tool approvals by design in the affected releases. - What a command on that laptop could reach: secrets, cloud CLI sessions, SSH keys and source code.
- Whether your other agents make approval decisions on command strings, and where a hook-level allow, deny or log decision is available instead.
CVE-2026-102697 is a reminder that "approved for this session" is a policy, and policies need an enforcement point that understands what will actually run. For the wider control set around agents on developer machines, see securing AI coding agents and CLIs. To find every local LLM runtime on your endpoints, book a 30-minute demo.
Frequently asked questions
Am I affected by CVE-2026-102697?
You are affected if a machine runs Ollama 0.14.0 or later but earlier than 0.31.2 and someone uses the experimental agent loop, started with ollama run and the --experimental flag. Serving models through the API without that flag does not use this approval code. The practical problem is that the flag is a per-user choice on a developer laptop, so the only reliable answer comes from an endpoint inventory of Ollama versions.
What exactly was bypassed?
The session approval. In agent mode, the Bash tool asks before running a command, and a user can allow a command for the rest of the session. For common read commands such as cat, ls, grep, find and sed, Ollama remembered a command-plus-directory prefix instead of the exact command. It derived that prefix from the text before the first pipe character only, so a command like cat on an approved path followed by a semicolon and a second command still matched and ran without asking.
Who can exploit it?
Anyone who can influence what the model outputs, which in an agent loop includes the content of files, web pages and search results the agent reads. The advisory frames it as prompt injection: the attacker does not need access to the machine, only to text the model will process after the user has approved one matching command. GitHub scores it CVSS 3.1 7.8 with user interaction required; VulnCheck's CVSS 4.0 score is 8.5.
Why did the fix land months before the CVE?
Ollama 0.31.2, released July 6, 2026, includes a commit titled agent: harness core that removed the experimental approval code entirely and replaced it with a new agent package. The release notes do not mention a security fix. The CVE record followed on September 29. Anyone who upgraded for other reasons is already covered; anyone pinned to an older build has had no security signal until now.
What about the --experimental-yolo flag?
In the vulnerable releases, a separate --experimental-yolo flag skipped all tool approval prompts by design. That is not a vulnerability, but it means approval prompts were never the only thing standing between a model and the shell. Treat any local agent loop with tools as able to run commands, and decide by policy which machines may run one at all.
What should we do now?
Upgrade Ollama to 0.31.2 or later everywhere it is installed, starting with developer machines where people experiment with agent mode. Then review which local LLM runtimes are installed across the fleet, which of them can run tools, and whether any agent sessions ran with broad session approvals before the upgrade.
How does Anomity help with this?
The Anomity Endpoint Sensor inventories local LLM runtimes such as Ollama, along with coding agents, CLIs and MCP servers, with their versions on every managed endpoint. That turns this advisory into a named list of machines below 0.31.2. For agents that expose a pre-execution hook, such as Claude Code PreToolUse, Anomity returns allow, deny or log before a tool call runs, and decisions land in a 90-day audit trail that routes to SIEM, Slack, email or Jira.
