`socket pnpm install` fabricates alerts for packages not in the tree: pnpm v9 lockfile keys are truncated at the first underscore
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 66/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- typescript
Rechercherichtung
Reproduziere das Problem mit der gezeigten pnpm-v9-Lockdatei und untersuche stripPnpmPeerSuffix in dist/utils.js sowie dessen Verwendung über extractPurlsFromPnpmLockfile und getAlertsMapFromPnpmLockfile in dist/shadow-pnpm-bin2.js. Als erledigt gilt die Aufgabe, wenn Pakete mit Unterstrichen in den eingereichten purls ihre vollständigen Namen und Versionen behalten, Peer-Suffixe für das relevante Lockdateiformat weiterhin verarbeitet werden und die Reproduktion den nicht verwandten String-Alert nicht mehr meldet.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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 [email protected] — 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/[email protected]). In lockfile v9, package keys are plain name@version, where _ is an ordinary legal character in npm package names. So extractPurlsFromPnpmLockfile maps:
| Lockfile key (v9) | Submitted purl |
|---|---|
[email protected] |
pkg:npm/string (versionless, wrong package) |
[email protected] |
pkg:npm/evp |
@types/[email protected] |
pkg:npm/@types/babel |
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 [email protected] surfaces.
Reproduction
mkdir repro && cd repro
npm init -y > /dev/null
printf 'lockfileVersion: "9.0"\npackages:\n [email protected]:\n resolution: {integrity: sha512-zOgAKMkjXbleOl9U5k7DBVdNwCRJW8ANhbJpEbriDmqu3nrOJPVHHqAmU7hBVBkoGuZbSpUnGdgOSg74RSPikw==}\nsnapshots:\n [email protected]:\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 [email protected]'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/[email protected], [email protected], and [email protected] (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 installfails 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).
- Vorherrschende Sprache
- TypeScript
- Sterne
- 320
- Forks
- 66
- Ø Merge
- 2 Std. 21 Min.
- Gemergte PRs (30 T.)
- 30
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus SocketDev/socket-cli
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
SocketDev/socket-cli#1160 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
SocketDev/socket-cli#1547 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
SocketDev/socket-cli#1525 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 45/100
SocketDev/socket-cli#1517 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
SocketDev/socket-cli#1498 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in SocketDev/socket-cli
Ähnliche Issues
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
aiko-chan-ai/DiscordBotClient#380 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
vercel/ai-elements#507 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
Maintainer antworten meist innerhalb von 2 Tagen
-
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 84/100
anaclumos/qa-interns#148 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag