Vendored Hatch runs a `hatch` executable planted in the scanned project

[mikolalysenko]

[agent] Filed by the scheduled architecture audit routine (CLI and core). Register: discussion #560 register.

Kind: bug. Source: §1 #4; Part 7.3. Register row C04.

Problem

require_environment_context_support spawns the bare name hatch from inside the scanned project:
vendor/pypi_hatch.rs#L114-L135

tokio::process::Command::new("hatch")
    .arg("--version")
    .current_dir(root)

It runs whenever a vendored Hatch project has an environment dependency on the patched package (#L103-L105).``

utils/process.rs#L23-L42 documents this exact pattern as unsafe. A relative PATH entry (. or an empty component) resolves against the child's cwd, so a bare spawn runs a hatch file committed to the repository being scanned. Every other spawn uses resolve_tool and spawns the resolved path, for example git in vendor/npm_dir.rs#L453 and node in redirect/npmrc.rs#L315. This is the only production bare-name spawn left. #442 closed the global package-manager probes but didn't touch this one.

Reproduced twice on 045d7ec with a temporary unit test in pypi_hatch.rs (not committed):

• root/hatch is an executable script that touches root/PWNED and prints Hatch, version 1.13.0;
• PATH is set to .:$PATH, and no real hatch is installed;
• the test calls require_environment_context_support(root).

Output: result=Ok(()) pwned=true resolve_tool=None. The planted script ran, and its fake version also passed the >=1.2 gate. resolve_tool("hatch") returns None on the same PATH, so the shared helper would have refused it.

Symptoms

None filed. This is the same class as #421, #434 and #438 (bare spawns), which were fixed by #442 for the PM probes.

Impact

Arbitrary code execution from a scanned checkout when the user's PATH contains a relative entry, which is common in some CI images and dev shells. On macOS, posix_spawnp can run both the planted file and the real binary (see the process.rs doc). The fix is small.

Proposed change

• Resolve with crate::utils::process::resolve_tool("hatch"). When it returns None, take the existing "Hatch >=1.2 on PATH" refusal.
• Spawn the resolved path through process::command_for (lifted with tokio::process::Command::from), keeping current_dir(root), the null stdin, kill_on_drop and the 10 s timeout.
• Nothing else changes; the bare spawn is deleted.

Size and scope

crates/socket-patch-core/src/vendor/pypi_hatch.rs only, about 10 production lines plus tests. Out of scope: the Hatch {root:uri} issues #505 and #547.

Acceptance criteria

• No Command::new("hatch") remains in production code.
• A Unix regression test: a planted executable hatch in root with PATH=.:<dirs without hatch> is not executed (its marker file is absent), and the result is pypi_hatch_unsupported.
• A test where a real-looking hatch on an absolute PATH dir is used and passes the version gate.
• Optional: an architecture test banning Command::new("<literal>") in core/CLI production code outside utils/process.rs, so the next bare spawn fails CI.
• cargo test -p socket-patch-core vendor::pypi_hatch and the vendored Hatch e2e stay green.

Dependencies

None. No open PR touches pypi_hatch.rs.

[mikolalysenko]

[agent] Triaged as priority:p1 (Hatch / PyPI family, security). Confirmed on main 045d7ec: vendor/pypi_hatch.rs:118 is the only production Command::new("<bare tool>") spawn left in core/CLI. No open PR touches it.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause: bare-name hatch spawn in vendored Hatch bypasses resolve_tool). Branch: agent/fix-hatch-bare-spawn. Claim-ID: 2026-10-02T22:20:55Z-b96139

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #617

---

Generated by Claude Code