Agent-mode npm `vex` hashes only the first installed copy of a package, so it attests not_affected while another nested copy of the same name@version is unpatched

[mikolalysenko]

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

Summary

In agent mode, vex checks only the first installed copy of each manifest PURL (crates/socket-patch-cli/src/commands/vex.rs:556, let package_paths = collapse_to_first(copies.clone());). Hosted-basis PURLs are checked against every copy (vex_consumed::hosted_consumed_copies), but agent records are not. When an npm tree holds several nested copies of the same name@version and only some of them are patched, the verdict depends on crawl order:

• first copy patched, another copy unpatched → not_affected (wrong);
• first copy unpatched, another copy patched → not_applied (right, by luck).

The Deno routine found this (handover on #302). I confirmed it with plain npm, where the trigger is common: apply patches every copy present, and a later npm install of a new dependent extracts a fresh, unpatched nested copy while leaving the patched one alone.

Impact

The VEX document says not_affected while an unpatched copy of the vulnerable code is still in node_modules and gets loaded by its dependent (is-accessor-descriptor here). apply is fine: re-running it patches the new copy. Only the attestation is wrong.

Repro (real npm, Linux, main 61cfb9b)

SP=/path/to/target/release/socket-patch
mkdir npmdup && cd npmdup && echo '{"name":"npmdup","version":"1.0.0"}' > package.json
npm install kind-of@6.0.3 is-number@3.0.0      # nests kind-of@3.2.2 under is-number
# Hand-stage .socket/manifest.json + .socket/blobs with a patch for pkg:npm/kind-of@3.2.2
# that changes package/index.js (beforeHash = pristine, afterHash = pristine + a comment line),
# with one vulnerability carrying a CVE. Any free patch works too.
$SP apply --offline                            # 1 of 1 targeted patch applied
npm install is-accessor-descriptor@0.1.6       # adds is-accessor-descriptor/node_modules/kind-of@3.2.2, unpatched
$SP vex --offline -O v.json; echo $?           # exit 0, 1 statement: not_affected

State after the second install:

node_modules/is-number/node_modules/kind-of              3.2.2 patched
node_modules/is-accessor-descriptor/node_modules/kind-of 3.2.2 UNPATCHED
node_modules/kind-of                                     6.0.3 (not targeted)

vex output: Wrote OpenVEX document with 1 statement to v.json, status not_affected.

Crawl-order check on the same tree: restore the is-number copy to pristine and patch the is-accessor-descriptor copy instead, and vex omits the PURL (not_applied) and exits with "No applied patches with vulnerability metadata to attest."

Expected vs actual

• Expected: CLI_CONTRACT.md's verification table (crates/socket-patch-cli/CLI_CONTRACT.md:390) says an agent record is verified against "the installed tree". An attestation should hold only when every installed copy the crawler finds for that PURL hashes to the patched bytes, as the hosted path already requires. Otherwise the PURL should be omitted (not_applied / hash_mismatch).
• Actual: only the first copy is hashed, and not_affected is emitted with exit 0.

Matrix

OS	npm	Node	main 61cfb9b	v4.0.0 (with setup.manual: ["npm"])
Linux	8.19.4	22.22	reproduces	not run
Linux	10.9.4	22.22	reproduces (2/2)	reproduces
Linux	12.2.0	22.22	reproduces	not run
macOS / Windows	—	—	not probed (the logic isn't OS-specific)	—

First bad version

This isn't a v5 regression: v4.0.0 emits the same single not_affected statement once setup.manual is set. I didn't bisect further.

Suspect code

• crates/socket-patch-cli/src/commands/vex.rs:556: collapse_to_first(copies.clone()) feeds applied_patches_with_vendor, which hashes one path per PURL for agent records.
• crates/socket-patch-cli/src/ecosystem_dispatch.rs:401: collapse_to_first.

The same pattern probably hits every npm-family layout that can hold several copies of one version (yarn classic and bun hoisted, Deno's hoisted linker, pnpm peer variants), but this issue covers npm only.

Related but different: #325 (bundled copies, hosted in-run --vex), #435 (pnpm global), #405 (bun isolated).

[mikolalysenko]

[agent] Triaged as priority:p1 (npm). Not a duplicate, and there's no fix PR. I confirmed on main 61cfb9b: crates/socket-patch-cli/src/commands/vex.rs:556 collapses the crawler's per-PURL copy list with collapse_to_first before the agent-record hash check. Only hosted-basis PURLs go through vex_consumed::hosted_consumed_copies, which checks every copy. Related but separate: #325 (bundled copies, hosted path), #435 (pnpm global apply misses copies), and #405 (bun isolated store, in PR #496).

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue. Root cause: agent-record VEX verification hashes only the first crawled copy (collapse_to_first). Branch: agent/fix-vex-agent-all-copies. Claim-ID: 2026-10-02T00:21:14Z-69672a

---

Generated by Claude Code

[mikolalysenko]

[agent] The fix is in progress in draft PR #517.

---

Generated by Claude Code

[mikolalysenko]

[agent] Deno bug-hunt routine (ledger #308). One more trigger to cover in the fix: Deno's isolated nodeModulesDir copy-index variants (node_modules/.deno/<name>@<ver>_1). Once #496 (the #373 fix) lands, they're patched like pnpm peer variants.

Real Deno 2.9.7, Linux, PR #496 head 7f41839, reproduced 2/2. deno.json imports npm:ajv@6.12.0, npm:ajv-keywords@3.5.2 and npm:schema-utils@2.7.1, which gives .deno/ajv-keywords@3.5.2 and .deno/ajv-keywords@3.5.2_1. apply patches both. Then:

• revert only .deno/ajv-keywords@3.5.2_1/node_modules/ajv-keywords/index.js → vex --offline --product pkg:deno/r@1.0.0 -O v.json exits 0 with not_affected, while schema-utils loads the unpatched _1 copy at runtime.
• revert only the root-linked @3.5.2 copy → exit 1, no attestation.

Same crawl-order dependence as the npm and hoisted-Deno cases. A test for the fix could add a .deno/<name>@<ver>_1 layout next to the nested-npm one.

---

Generated by Claude Code

[mikolalysenko]

[agent] Deno bug-hunt routine (ledger #308). Follow-up to my last comment: PR #517 at 0f45d24 does not cover the Deno .deno/<name>@<ver>_1 trigger, even with #496 merged on top.

What I did: real Deno 2.9.7 on Linux, a local merge of #517 (0f45d24) and #496 (7f41839) with no conflicts, reproduced 2/2 from clean projects:

echo '{ "nodeModulesDir": "auto" }' > deno.json
echo '{ "dependencies": { "ajv": "6.12.0", "ajv-keywords": "3.5.2", "schema-utils": "2.7.1" } }' > package.json
deno install            # .deno/ajv-keywords@3.5.2 and .deno/ajv-keywords@3.5.2_1
# offline manifest + blobs for pkg:npm/ajv-keywords@3.5.2 (index.js), then:
socket-patch apply --offline --json     # patches both copies (combined build)
# revert only .deno/ajv-keywords@3.5.2_1/node_modules/ajv-keywords/index.js
deno run -A su.ts                       # import "schema-utils" -> loads the unpatched _1 copy
socket-patch vex --product pkg:deno/x@1 -O v.json --json   # rc=0, not_affected / inline_mitigations_already_exist

Cause: #517 switches VEX to find_manifest_package_copies_reusing, which goes through NpmCrawler::find_by_purls. That function's doc comment says it deliberately does not enumerate store peer-variant copies when a copy was already found in the importer tree. Those copies are only reached by the apply engine's find_store_peer_variant_copies fan-out. With #496, Deno's _N copy-index folders take that fan-out path, so apply patches them but vex never hashes them. pnpm .pnpm/<name>@<ver>_<peer-hash> peer variants of a direct dep probably go the same way (I haven't verified that; it's outside Deno).

Suggested fix: have VEX gather copies the same way apply does (find_by_purls plus the store peer-variant fan-out), and add a regression test with a .deno/<name>@<ver>_1 layout next to the nested-npm one.

---

Generated by Claude Code

[mikolalysenko]

[agent] More evidence from the Pipenv bug-hunt routine (ledger #313): the same collapse_to_first path hits PyPI / Pipenv on main d63ae5f. #538 made agent apply patch every PyPI copy, so a Pipenv project with both ./.venv and a $WORKON_HOME/<name>-<hash> venv now has two copies of one purl. vex still hashes only the first one (WORKON_HOME).

Repro (real Pipenv on Linux, local mock API, agent patch for six@1.16.0):

export WORKON_HOME=$PWD/workon PIPENV_IGNORE_VIRTUALENVS=1; unset PIPENV_VENV_IN_PROJECT
mkdir proj && cd proj
pipenv install six==1.16.0                              # $WORKON_HOME/proj-XXXX
PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy        # ./.venv; `pipenv --venv` = ./.venv on 2018–2025
socket-patch scan --mode agent --yes --json $API        # both copies patched (#538)
# later: .venv is recreated (rm -rf .venv && PIPENV_VENV_IN_PROJECT=1 pipenv sync), so its six.py is pristine again
socket-patch vex --product pkg:pypi/app@0.1.0 -O vex.json $API   # exit 0, not_affected / inline_mitigations_already_exist
pipenv run python -c 'import six'                        # loads the UNPATCHED .venv copy

Pipenv	copy reset to pristine	vex on main d63ae5f
2018.11.26 (py3.8)	.venv (the one Pipenv runs)	not_affected (wrong), 1/1
2023.12.1 (py3.11)	.venv (the one Pipenv runs)	not_affected (wrong), 2/2
2023.12.1	WORKON_HOME	omitted, not_applied (right, by crawl order)
2026.8.0 (py3.12)	WORKON_HOME (the one Pipenv runs)	omitted, not_applied (right, by crawl order)

A re-run of apply patches the pristine copy correctly. Only the attestation is wrong. PR #517 swaps in applied_patches_with_copies for every ecosystem, so it should cover this as well. A PyPI multi-venv case in its tests would lock that in.

---

Generated by Claude Code