Agent-mode scan in a Pipenv project without a Pipenv venv patches the system Python's site-packages in place instead of the project's venv/ (regression from #388)

[mikolalysenko]

[agent] Found by the scheduled Pipenv bug-hunt routine (ledger #313).

Summary

Since #388 (ccd43f5), find_local_venv_site_packages returns early for any directory with a Pipfile or Pipfile.lock. It returns only the venv Pipenv itself would resolve, and never ./venv or an in-project .venv that Pipenv's settings rule out. The code comment there says: "When Pipenv has no venv yet there is nothing to patch, so the generic probes must not fall back to a tree Pipenv will never use."

But when that returns nothing, get_site_packages_paths (crates/socket-patch-core/src/crawlers/python_crawler.rs:1719-1724) sees is_python_project(cwd) and falls back to get_global_python_site_packages(). So an agent-mode scan --apply (no -g) in such a project:

• ignores the project's venv/, which is the environment the repo actually runs in (a Pipfile kept for dev while Docker/CI use python -m venv venv && pip install -r requirements.txt), and patched it before Fix Pipenv venv discovery order (#334, #384) #388;
• patches the system interpreter in place (/usr/lib/python3/dist-packages/six.py on Debian/Ubuntu), and records it in .socket/manifest.json;
• exits 0 with applied: 1, and vex --product … then attests not_affected while the project's venv still holds the vulnerable bytes.

The same fallback fires for an in-project .venv with PIPENV_VENV_IN_PROJECT=0 and no WORKON_HOME venv. There, skipping .venv is correct (#334), but falling through to the system Python isn't. It also fires for a fresh Pipenv checkout before pipenv install. #447 (2035cbb, egg-info discovery) widens the blast radius: apt-installed Debian packages such as python3-six are .egg-info installs and are now found and patched.

As a non-root user, the scan instead fails with Permission denied (os error 13) on the system path (exit 1), and the project's venv/ is still never patched.

Impact

• A project-scoped command (no -g) modifies files outside the project, in the OS Python, as root in Docker builds. rollback does restore them, but nobody expects a project scan to touch them.
• The environment the app actually runs in stays vulnerable, and both the exit code and VEX say it's fixed.
• Before Fix Pipenv venv discovery order (#334, #384) #388, the same project patched venv/ correctly, so this is a regression for any repo with a Pipfile (or a leftover Pipfile.lock) and a plain venv/.

Repro (Linux, Debian/Ubuntu Python with python3-six 1.16.0 installed; mock patch API serving six 1.16.0)

mkdir r1 && cd r1 && git init -q
printf '[[source]]\nurl = "https://pypi.org/simple"\nverify_ssl = true\nname = "pypi"\n\n[packages]\nsix = "==1.16.0"\n' > Pipfile
pipenv lock                                   # Pipfile + Pipfile.lock; no Pipenv venv
python3 -m venv venv && venv/bin/pip install six==1.16.0
export WORKON_HOME=$PWD/wh-empty              # no Pipenv venv exists
socket-patch scan --apply; echo "exit=$?"     # exit=0, "1 of 1 targeted patch applied"
grep -c SOCKET_PATCHED /usr/lib/python3/dist-packages/six.py      # 1  <- system Python patched
grep -c SOCKET_PATCHED venv/lib/python3.11/site-packages/six.py   # 0  <- project venv untouched
socket-patch vex --product pkg:pypi/app@0.1.0  # not_affected
socket-patch rollback                          # restores the system file

(The mock's patched six.py appends SOCKET_PATCHED = True.)

Expected vs actual

• Expected: CLI_CONTRACT.md ("cwd-only (single project)", line ~479) says "The crawler inspects only the project rooted at --cwd (pypi looks at $VIRTUAL_ENV, <cwd>/.venv / venv, then a Poetry project's out-of-tree virtualenv(s)…)". Global packages are the -g / --global-prefix surface. The Fix Pipenv venv discovery order (#334, #384) #388 comment itself says a Pipenv project with no Pipenv venv has "nothing to patch". So either the project's venv/ is patched, as before Fix Pipenv venv discovery order (#334, #384) #388, or nothing is patched and the scan says so. The system site-packages must never be patched without -g. Which of the two applies to venv/ is a maintainer call. The global write is the defect either way.
• Actual: the system Python is patched (as root) or the run fails on it (non-root), and the project's venv is never considered.

Cells (Linux; macOS/Windows probes blocked this run, see the ledger)

Shape (main 61cfb9b)	system six	project venv	exit	bae5d3a (pre-#388)
Pipfile + lock + venv/, no Pipenv venv (root)	❌ patched	not patched	0	✅ venv/ patched, system untouched (2/2)
same, non-root user	❌ Permission denied	not patched	1	(not run)
Pipfile + lock + .venv, PIPENV_VENV_IN_PROJECT=0, no WORKON venv	❌ patched	.venv not patched (correct per #334)	0	patched .venv (the #334 bug)
Pipfile + lock, no venv at all	❌ patched	n/a	0	system six not seen (egg-info, pre-#447)
Pipfile + lock with the Pipenv WORKON_HOME venv present (control)	✅ untouched	✅ Pipenv venv patched	0	—

Each main cell was reproduced twice (scan → rollback → scan).

First bad: ccd43f5 (#388) for the venv/ and .venv shapes, where bae5d3a is good. The global fallback itself is older. #447 (2035cbb) makes egg-info system packages visible to it.

Suspect code

• crates/socket-patch-core/src/crawlers/python_crawler.rs:362-364: if pipenv { return pipenv_project_site_packages(cwd, var).await; }. An empty result here means "nothing to patch", but the caller can't tell that apart from "no venv probed".
• crates/socket-patch-core/src/crawlers/python_crawler.rs:1719-1724: the is_python_project → get_global_python_site_packages() fallback in non-global mode.

[mikolalysenko]

[agent] Triaged as priority:p1 (Pipenv). Confirmed on main 61cfb9b: PythonCrawler::get_site_packages_paths (crates/socket-patch-core/src/crawlers/python_crawler.rs ~L1719-1724) falls back to get_global_python_site_packages() whenever find_local_venv_site_packages returns nothing and is_python_project(cwd) is true, and the Pipenv branch (~L362) returns an empty list by design when no Pipenv venv exists. Not a duplicate. Related but not clustered: #476 (Poetry) and #502 (PDM) also end in the same project-mode global fallback, but each needs its own probe fix (Poetry's out-of-tree env, .pdm-python), so one change would not resolve all three. A fix here that stops the global fallback for PM-managed projects would remove the system-Python write in those two as well. Whether ./venv should be patched again for a Pipfile project is the open maintainer call noted in the report. No open fix PR.

---

Generated by Claude Code