With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671

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

Summary

When a Poetry project sets virtualenvs.create = false (in poetry.toml, config.toml or POETRY_VIRTUALENVS_CREATE=false, which is the usual container setup), Poetry installs into the system interpreter (EnvManager.get() → get_system_env()). The only exception is an existing ./.venv when virtualenvs.in-project isn't explicitly false. Poetry never uses ./venv.

socket-patch's crawler has step 3 to stop a stray .venv / venv from shadowing Poetry's env. With create = false, though, poetry_virtualenvs_root returns None, step 3 finds nothing, and step 4 then probes ./.venv and ./venv. If one of them exists (for example, a developer's local venv copied into an image by COPY . .), socket-patch patches that tree and never reaches the global fallback. The site-packages Poetry installed into, and that poetry run imports, stays unpatched. socket-patch vex then attests not_affected / inline_mitigations_already_exist.

Impact

The vulnerable copy stays in use, socket-patch reports success (exit 0), and the VEX document claims the vulnerability is mitigated. That's a false attestation.

Repro (Linux, real Poetry 2.5.1 and 1.8.5)

SYS is a standalone CPython 3.12 (a copy of a uv-managed interpreter) standing in for a container's system Python, with Poetry pip-installed into it and first on PATH. The patch API is a local mock that serves a six.py patch for six@1.16.0, using the same routes as tests/vex_pypi_real_common.

export PATH=$SYS/bin:$PATH
mkdir demo && cd demo
cat > pyproject.toml <<'EOF'
[tool.poetry]
name = "demo"
version = "0.1.0"
description = ""
authors = ["x <x@x.x>"]
package-mode = false

[tool.poetry.dependencies]
python = ">=3.9"
six = "1.16.0"
EOF
printf '[virtualenvs]\ncreate = false\n' > poetry.toml      # or: export POETRY_VIRTUALENVS_CREATE=false
python3.11 -m venv venv && venv/bin/pip install six==1.16.0  # stray venv Poetry never uses
poetry install                                              # installs six into $SYS site-packages
socket-patch scan --mode agent --yes --api-url $MOCK --api-token fake --org test-org
poetry run python -c "import six; print(six.__file__, getattr(six, 'SOCKET_PATCHED', 0))"
socket-patch vex -O v.json --api-url $MOCK --api-token fake --org test-org

Actual:

Summary: 1 of 1 targeted patch applied, 0 already patched, 0 not found on disk
system copy patched: 0   stray venv copy patched: 1
poetry run imports …/sys/lib/python3.12/site-packages/six.py SOCKET_PATCHED= 0
VEX: not_affected inline_mitigations_already_exist

Expected

The docs, docs/testing/poetry-compatibility.md ("Mode notes"), say: "virtualenvs.create = false (containers) means Poetry installed into the system interpreter, which the project-marker global fallback covers." The crawler's own step-3 comment says that "a stray .venv / venv left by another tool does not shadow the env Poetry installed into". So with create = false, agent mode should patch the env Poetry uses: ./.venv only when in-project isn't false and .venv is a directory, otherwise the system interpreter. It should never patch ./venv. vex must not attest a patch that the installed copy doesn't carry.

Matrix (Linux, main 045d7ec)

Each failing cell reproduced at least twice. Poetry 1.8.5 and 2.5.1 have the same EnvManager.get() order: in_project_venv_exists(), then if not create_venv: return self.get_system_env(). macOS and Windows weren't tested (probe branches are blocked for this routine), but the code path isn't platform-specific.

First bad version

Release 4.0.0 already patches the stray ./venv. Its vex was blocked by the old setup gate (ecosystem_not_setup), so the false VEX attestation is new on main now that setup is gone. 3.3.0's agent scan didn't patch either copy in this layout. Open PR #644 (data-dir and placeholder model) doesn't change this: I built its head and both stray layouts still fail the same way.

Suspect code

• crates/socket-patch-core/src/crawlers/python_crawler.rs:401: step 3 is skipped (it returns empty) when create == Some(false) (poetry_virtualenvs_root, line 982), so control falls through.
• crates/socket-patch-core/src/crawlers/python_crawler.rs:408: step 4 probes ./.venv and ./venv for a Poetry project whose config rules both out. For a Poetry project with create = false, it should return the in-project .venv only when in_project_venv_exists, otherwise go straight to the global fallback.