Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2026-09-28

HighPrimary

code-ollama Read-Only Search Tool Could Execute Model-Supplied Shell Commands Without Approval

Analysis of GHSA-456v-xq2p-r4cj, where code-ollama treated grep_search as read-only while model-supplied arguments reached a shell command without approval.

code-ollamaTool execution / MCPModel-supplied shell command injection through an auto-approved read-only toolDeveloper workstations, CI runners, and IDE-integrated environments running code-ollama 0.36.0 or earlier with ripgrep available

What happened

In the controlled proof of concept, a fake Ollama server supplied a grep_search pattern containing shell command substitution, and code-ollama executed the injected id command as the local user without requesting approval.

Why it matters

The demonstration achieved arbitrary local command execution and wrote process identity data to a marker file. The advisory states that the same primitive could read or modify user-accessible files, expose secrets, terminate processes, or consume resources, but it reports no confirmed production exploitation.

Missing authorization check

Independent authorization bound to the exact grep_search tool name, arguments, caller, target path, and execution method before any model-originated value reaches a shell.

Would PP block it?

If code-ollama routes the call through an external gate before dispatch, the model-supplied tool name and arguments can be bound to a signed decision and the demonstrated request can fail closed. Permission Protocol does not repair the vulnerable interpolation, contain arbitrary commands after child_process.exec runs, or protect deployments that bypass the gate.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-06-24

    code-ollama 0.36.1 is released with a fix for grep_search command injection through unescaped shell substitution.

  2. 2026-09-28

    GHSA-456v-xq2p-r4cj is published with the vulnerable data flow, Docker proof of concept, impact analysis, and patched-version range.

Technical breakdown

  • A malicious or compromised Ollama backend could place attacker-controlled pattern and path values in a grep_search tool call.
  • The vulnerable implementation escaped backslashes and double quotes but left shell command substitution and backtick expansion active.
  • grep_search assembled a shell command string and passed it through execShell to child_process.exec, allowing the shell to interpret model-supplied metacharacters.
  • The tool appeared in the runtime's read-only tool list, so Plan mode dispatched it automatically without presenting an approval prompt.
  • The published proof of concept used a fake Ollama server and a command-substitution payload that wrote id output to a marker file.
  • Version 0.36.1 changed grep_search to invoke ripgrep with an argument vector instead of constructing a shell command string.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
code-ollama tool dispatcher immediately before grep_search invokes the filesystem search implementation
Still needs
The code-ollama patch is still required. Permission Protocol cannot make an already executing shell command safe or contain local process compromise.
Receipt required for
Executing grep_search with the exact pattern, path, caller, runtime identity, and target workspace

A Tool-Call Gate can require a receipt before grep_search executes and can reject a request whose arguments contain an unapproved command-substitution payload.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop