Arbitrary command execution via crafted staged filenames in `harness check`

[VikramNehreTR]

Summary

harness check (cli pre-commit mode) is vulnerable to arbitrary shell command execution via a crafted staged filename. Confirmed live, not just from reading the code.

Root cause

src/cli/run.ts:

export function stagedContent(path: string): string {
  return execSync(`git show ":${path}"`, { encoding: "utf8" });
}

path comes from stagedFiles(), which is just git diff --cached --name-only --diff-filter=ACMR output — i.e. the literal names of staged files. Interpolating that into a shell string handed to execSync means any staged filename containing shell metacharacters runs as shell syntax.

Git's default core.quotepath=true does escape filenames containing an embedded " or \, which neutralizes the most obvious injection attempt (and is why my first try, using an embedded quote, didn't fire). But it does not escape backticks or $(...), so those go through untouched.

Reproduction (safe — uses touch, tested in a throwaway repo)

mkdir /tmp/harness-poc && cd /tmp/harness-poc && git init -q
npm i @fusengine/harness

FILENAME='x`touch pwned.txt`.ts'
echo "content" > "$FILENAME"
git add -- "$FILENAME"

npx harness check
# git then fails on the mangled remaining path ("x.ts" doesn't exist), but
# by that point the backtick command substitution has already run:
ls pwned.txt   # <- exists

Tested against 0.1.79 (latest as of 2026-07-20).

Impact

Anyone running harness check as a pre-commit hook (per the README's own .husky/pre-commit example) against a repo whose staged file list isn't fully trusted — e.g. right after checking out a contributor's branch/PR and running git add . — gets arbitrary command execution. This is exactly the scenario a pre-commit check is usually run in.

Suggested fix

Use execFileSync with an argv array instead of a shell string, so the filename is never parsed by a shell regardless of its content:

import { execFileSync } from "node:child_process";

export function stagedContent(path: string): string {
  return execFileSync("git", ["show", `:${path}`], { encoding: "utf8" });
}

Happy to send a PR for this if useful — just didn't want to open one unprompted before flagging the issue itself.

[fusengine]

Thanks for the report — the reproduction, the root-cause analysis (including why core.quotepath doesn't neutralize backticks/$(...)), and the suggested fix were all accurate and made this straightforward to act on. Apologies for the two-week gap before a response.

Fixed in 0.1.89 (PR #98, commit 194170e). The fix matches what you proposed: stagedContent() and stagedFiles() (src/cli/run.ts) now use execFileSync with an argv array instead of an interpolated shell string, so a staged filename is passed to git show/git diff as a single literal argument and never reaches a shell, regardless of its content.

A regression test (test/staged-content-shell-injection.test.ts) exercises stagedContent() against an isolated repo with a backtick-laden staged filename; it was confirmed to fail against the previous execSync form before the fix, and pass after. We also audited the other 8 command-execution sites in src/ for the same interpolated-shell-string pattern — this was the only one that took untrusted input.

Please upgrade to >=0.1.89.