`socket pnpm install` fabricates alerts for packages not in the tree: pnpm v9 lockfile keys are truncated at the first underscore

Summary

The pnpm shadow wrapper's lockfile scan mangles the name of any package whose name contains an underscore, submitting a purl for a different, unrelated package. In any pnpm-v9 project that depends on string_decoder (i.e. effectively every project, via readable-stream), socket pnpm install reports a High CVE for string@3.3.3 — a package that is not in the dependency tree at all — and exits 1.

Mechanism

stripPnpmPeerSuffix truncates a lockfile package key at the first ( or _:

function stripPnpmPeerSuffix(depPath) {
  const parenIndex = depPath.indexOf('(');
  const index = parenIndex === -1 ? depPath.indexOf('_') : parenIndex;
  return index === -1 ? depPath : depPath.slice(0, index);
}

The _ case is the pnpm lockfile v5 peer-suffix convention (/foo/1.0.0_bar@2.0.0). In lockfile v9, package keys are plain name@version, where _ is an ordinary legal character in npm package names. So extractPurlsFromPnpmLockfile maps:

The batch purl endpoint resolves the versionless pkg:npm/string to the real (unrelated) string package, whose latest version 3.3.3 carries a High CVE — which the wrapper's default filter treats as fatal, regardless of org policy. The other two mangled names happen not to resolve to alerting packages, which is why only string@3.3.3 surfaces.

Reproduction

mkdir repro && cd repro
npm init -y > /dev/null
printf 'lockfileVersion: "9.0"\npackages:\n  string_decoder@1.3.0:\n    resolution: {integrity: sha512-zOgAKMkjXbleOl9U5k7DBVdNwCRJW8ANhbJpEbriDmqu3nrOJPVHHqAmU7hBVBkoGuZbSpUnGdgOSg74RSPikw==}\nsnapshots:\n  string_decoder@1.3.0:\n    dependencies:\n      safe-buffer: 5.2.1\n' > pnpm-lock.yaml
SOCKET_CLI_DEBUG=1 DEBUG='*' socket pnpm install 2>&1 | grep -A5 purls
# → purls include 'pkg:npm/string' (no version), and the run fails on string@3.3.3's High CVE

(Alternatively: any real pnpm-v9 project with string_decoder in its lockfile reproduces it — we hit it in a 1,500-package workspace.)

Versions

Observed identical in @socketsecurity/cli@1.1.85, socket@1.1.143, and socket@1.1.155 (latest as of 2026-08-08): dist/utils.js stripPnpmPeerSuffix, reached via extractPurlsFromPnpmLockfile → getAlertsMapFromPnpmLockfile in dist/shadow-pnpm-bin2.js's install path.

Suggested fix

Only apply the _ truncation to v5-style dep paths (those beginning with / and using /name/version shape), or key the suffix-stripping on the lockfile's lockfileVersion. For v9 name@version keys, peer suffixes only ever appear in parentheses.

Impact

• socket pnpm install fails spuriously (exit 1) for effectively any pnpm-v9 tree containing an underscore-named package that maps onto an alerting package name.
• The submitted purl set silently omits the real packages (string_decoder, evp_bytestokey, @types/babel__* are never actually checked).

Tái hiện vấn đề với lockfile pnpm v9 được hiển thị, sau đó kiểm tra stripPnpmPeerSuffix trong dist/utils.js và cách sử dụng của nó thông qua extractPurlsFromPnpmLockfile và getAlertsMapFromPnpmLockfile trong dist/shadow-pnpm-bin2.js. Được xem là hoàn tất khi các package có tên chứa dấu gạch dưới giữ nguyên tên và phiên bản đầy đủ trong các purl được gửi, các hậu tố peer vẫn được xử lý cho định dạng lockfile tương ứng và việc tái hiện không còn báo alert string không liên quan.