`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).

Reproduce the issue with the pnpm v9 lockfile shown, then inspect stripPnpmPeerSuffix in dist/utils.js and its use through extractPurlsFromPnpmLockfile and getAlertsMapFromPnpmLockfile in dist/shadow-pnpm-bin2.js. Done means underscore-named packages retain their full names and versions in submitted purls, while peer suffixes are still handled for the relevant lockfile format and the reproduction no longer reports the unrelated string alert.