• Fixes GHSA-qrv3-253h-g69c (CWE-22, High): config dependency names from pnpm-lock.yaml were used
 directly to build filesystem paths, allowing a malicious lockfile with a traversal-shaped name like
 ../../PWNED to create symlinks outside node_modules/.pnpm-config.
• Adds assertValidConfigDepNames (TS) and assert_valid_config_dep_names (Rust/pacquet) to
 validate every config dep name and optional subdep name as a valid npm package name before any path
 is constructed.
• Adds regression tests in both the TypeScript and Rust env-installer test suites asserting
 traversal-shaped names are rejected and no path escapes the config-dep directory.
• Adds a changeset entry marking @pnpm/installing.env-installer and pnpm as patched with a
 security advisory reference.

graph TD
    LF["pnpm-lock.yaml\n(attacker-controlled)"] --> NF["normalizeForInstall /\nnormalize_from_lockfile"]
    NF --> VG["assertValidConfigDepNames /\nassert_valid_config_dep_names"]
    VG -- "invalid name" --> ERR["ERR_PNPM_INVALID_DEPENDENCY_NAME"]
    VG -- "all names valid" --> FS["node_modules/.pnpm-config\n(filesystem writes)"]
    VG --> VAL["assertValidDependencyAliases /\nis_valid_old_npm_package_name"]
    VAL --> VG

    subgraph Legend
      direction LR
      _doc["pnpm-lock.yaml"] ~~~ _fn["Function"] ~~~ _err["Error"] ~~~ _fs[("Filesystem")]
    end

Loading

The following are alternative approaches to this PR:

1. Path canonicalization after construction

• ➕ Catches traversal even if validation is bypassed by an edge case
• ➖ More complex to implement correctly across both TS and Rust
• ➖ Harder to audit; easy to miss a code path
• ➖ Does not prevent the name from being used in other non-path contexts

2. Validate at lockfile-read layer

• ➕ Prevents invalid names from ever entering the system
• ➖ Requires changes in the lockfile parsing crate, a wider blast radius
• ➖ Would need to handle the legacy inline format separately
• ➖ Lockfile parsing is a lower-level concern; security policy belongs closer to the install logic

Recommendation: The PR's approach — validating at the chokepoint right after lockfile normalization, before any path is built — is the correct and minimal fix. An alternative would be to sanitize/canonicalize the path after construction (e.g., verify the resolved path is still under .pnpm-config), but that is more error-prone and harder to audit. Another alternative would be to validate at the lockfile-read layer, but that would require changes in more places and could miss the legacy inline format path. The current approach reuses the existing assertValidDependencyAliases / is_valid_old_npm_package_name validators, keeping the fix consistent with how pnpm validates user-supplied dependency names elsewhere.

Bug fix (3) +72 / -0

installConfigDeps.tsValidate config dep names before building filesystem paths (TS) +21/-0

Validate config dep names before building filesystem paths (TS)

• Imports 'assertValidDependencyAliases' from '@pnpm/installing.deps-resolver' and calls the new 'assertValidConfigDepNames' guard immediately after 'normalizeForInstall'. The guard validates every top-level config dep name and every optional subdep name as a valid npm package name, throwing 'ERR_PNPM_INVALID_DEPENDENCY_NAME' on any traversal-shaped or otherwise invalid name.

installing/env-installer/src/installConfigDeps.ts

errors.rsAdd 'InvalidDependencyName' error variant to 'ConfigDepError' (Rust) +17/-0

Add 'InvalidDependencyName' error variant to 'ConfigDepError' (Rust)

• Introduces a new 'InvalidDependencyName' variant with 'ERR_PNPM_INVALID_DEPENDENCY_NAME' diagnostic code, mirroring the TypeScript error thrown by 'assertValidDependencyAliases'. Includes a user-facing help message explaining valid npm package name rules.

pacquet/crates/env-installer/src/errors.rs

install_config_deps.rsValidate config dep names before building filesystem paths (Rust/pacquet) +34/-0

Validate config dep names before building filesystem paths (Rust/pacquet)

• Imports 'is_valid_old_npm_package_name' and calls the new 'assert_valid_config_dep_names' function immediately after 'normalize_from_lockfile'. The function iterates all config dep names and their optional subdep names, returning 'ConfigDepError::InvalidDependencyName' for any invalid name.

pacquet/crates/env-installer/src/install_config_deps.rs

Tests (2) +136 / -2

installConfigDeps.tsAdd regression tests for path-traversal config dep and subdep names (TS) +55/-0

Add regression tests for path-traversal config dep and subdep names (TS)

• Adds two new Jest tests: one asserting that a top-level config dep with a traversal-shaped name ('../../PWNED') is rejected before any filesystem write, and one asserting the same for an optional subdep name. Both tests verify no path is created outside 'node_modules/.pnpm-config'.

installing/env-installer/test/installConfigDeps.ts

tests.rsAdd regression tests for path-traversal config dep and subdep names (Rust) +81/-2

Add regression tests for path-traversal config dep and subdep names (Rust)

• Adds two async Tokio tests: 'rejects_config_dep_with_path_traversal_name' and 'rejects_optional_subdep_with_path_traversal_name'. Both construct a tampered env lockfile with a traversal-shaped name, call 'install_config_deps', assert the 'InvalidDependencyName' error variant is returned, and verify no file escaped the expected directory.

pacquet/crates/env-installer/src/tests.rs

Other (2) +20 / -13

config-deps-path-traversal.mdAdd changeset for GHSA-qrv3-253h-g69c security patch +6/-0

Add changeset for GHSA-qrv3-253h-g69c security patch

• Documents the security fix as a patch-level change for '@pnpm/installing.env-installer' and 'pnpm', linking to the GHSA advisory.

.changeset/config-deps-path-traversal.md

Cargo.tomlAdd 'pacquet-resolving-parse-wanted-dependency' dependency to env-installer crate +14/-13

Add 'pacquet-resolving-parse-wanted-dependency' dependency to env-installer crate

• Adds 'pacquet-resolving-parse-wanted-dependency' as a workspace dependency so the Rust env-installer can call 'is_valid_old_npm_package_name' for the new validation gate.

pacquet/crates/env-installer/Cargo.toml

Description

In pacquet’s legacy manifest (pnpm-workspace.yaml / inline-integrity) migration flow, the code
migrates configDependencies into the env lockfile and can write pnpm-lock.yaml before the newer
exact-semver validation runs. This allows an attacker-controlled invalid/traversal-shaped migrated
version (e.g., extracted from +) to be persisted to pnpm-lock.yaml before the run ultimately fails
with an invalid config dependency version error.

Code

pacquet/crates/env-installer/src/resolve_and_install_config_deps.rs[R35-47]

+    // Validate the manifest-sourced names before any lockfile mutation or
+    // write: migrating the legacy inline format records entries and writes
+    // pnpm-lock.yaml, so an invalid name must be refused first to avoid a
+    // pre-rejection write side effect.
+    for name in config_deps.keys() {
+        if !is_valid_old_npm_package_name(name) {
+            return Err(ConfigDepError::InvalidDependencyName {
+                description: "The configDependencies in pnpm-workspace.yaml".to_string(),
+                name: name.clone(),
+            });
+        }
+    }
+

Evidence

The cited legacy migration branches normalize/migrate configDependencies into lockfile state and, as
part of that migration, write pnpm-lock.yaml as a side effect (e.g., via env_lockfile.write(...) /
migrateConfigDepsToLockfile()) before control reaches the later validation step. In the Rust flow,
resolve_and_install_config_deps() writes the env lockfile prior to calling install_config_deps(),
where version validation occurs via node_semver parsing (assert_valid_config_dep_version), so
invalid versions can be written before being rejected; similarly in the TS flow, installConfigDeps()
runs normalizeForInstall() (which can invoke migrateConfigDepsToLockfile() and write
pnpm-lock.yaml/settings) before assertValidConfigDeps() checks versions, and
parseIntegrity()/parse_integrity() returns the raw version substring without semver validation,
enabling invalid/traversal-shaped versions to slip into the written lockfile prior to failure.

pacquet/crates/env-installer/src/resolve_and_install_config_deps.rs[66-102]
pacquet/crates/env-installer/src/resolve_and_install_config_deps.rs[121-137]
pacquet/crates/env-installer/src/parse_integrity.rs[36-51]
pacquet/crates/env-installer/src/install_config_deps.rs[39-47]
pacquet/crates/env-installer/src/install_config_deps.rs[352-387]
installing/env-installer/src/installConfigDeps.ts[35-46]
installing/env-installer/src/installConfigDeps.ts[182-213]
installing/env-installer/src/migrateConfigDeps.ts[95-107]
installing/env-installer/src/parseIntegrity.ts[24-39]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Legacy inline-integrity configDependencies are migrated into the env lockfile and pnpm-lock.yaml can be written before config dependency versions are validated as exact semver. Update the migration/normalization paths so any invalid/traversal-shaped version extracted from legacy forms is rejected *before* any lockfile/settings write occurs, ensuring pnpm-lock.yaml is not created/modified on invalid input.
## Issue Context
- In the legacy migration branches, versions are parsed/migrated into lockfile state and a write to pnpm-lock.yaml can occur before the later version validation gate runs.
- `parse_integrity()` / `parseIntegrity()` returns the raw `<version>` substring (from `<version>+<integrity>`) without semver validation.
- In Rust, `env_lockfile.write(...)` can occur before calling `install_config_deps(...)`, while version validation is enforced inside `install_config_deps` via `assert_valid_config_dep_version` / `node_semver` parsing.
- In TS, `installConfigDeps()` validates versions only after `normalizeForInstall()`, but `normalizeForInstall()` may call `migrateConfigDepsToLockfile()` which writes the env lockfile/settings.
## Fix Focus Areas
- pacquet/crates/env-installer/src/resolve_and_install_config_deps.rs[66-138]
- pacquet/crates/env-installer/src/parse_integrity.rs[36-51]
- pacquet/crates/env-installer/src/install_config_deps.rs[39-45]
- pacquet/crates/env-installer/src/install_config_deps.rs[352-387]
- installing/env-installer/src/installConfigDeps.ts[35-45]
- installing/env-installer/src/installConfigDeps.ts[182-213]
- installing/env-installer/src/migrateConfigDeps.ts[35-108]
- installing/env-installer/src/parseIntegrity.ts[24-39]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

installConfigDeps validates attacker-controlled dependency names but still incorporates
attacker-controlled version strings from pnpm-lock.yaml into filesystem paths (GVS relPath uses
//), so a lockfile with version: "../../../PWNED" can normalize outside the intended store links
root and be written to during importPackage/materialize. The same gap exists in pacquet’s mirror
implementation.

Code

installing/env-installer/src/installConfigDeps.ts[R132-151]

+// Config dependency names are read from the committed env lockfile (and the
+// legacy inline format in pnpm-workspace.yaml), so they are attacker-controlled
+// input. Each name becomes a directory entry under node_modules/.pnpm-config and
+// inside the global virtual store, so a traversal-shaped name like
+// `../../PWNED` would let a malicious repository create symlinks outside the
+// config dependency root during install. Reject anything that is not a plain npm
+// package name before any path is built from it.
+function assertValidConfigDepNames (normalizedDeps: Record<string, NormalizedConfigDep>): void {
+  assertValidDependencyAliases(normalizedDeps, 'The configDependencies in the env lockfile (pnpm-lock.yaml)')
+  for (const [pkgName, pkg] of Object.entries(normalizedDeps)) {
+    if (!pkg.optionalSubdeps?.length) continue
+    // A null-prototype object so an attacker-controlled name of `__proto__`
+    // becomes an enumerable own key the validator rejects, rather than
+    // silently setting the prototype and slipping past `Object.keys`.
+    const subdepsByName: Record<string, true> = Object.create(null)
+    for (const subdep of pkg.optionalSubdeps) {
+      subdepsByName[subdep.name] = true
+    }
+    assertValidDependencyAliases(subdepsByName, `The optionalDependencies of config dependency "${pkgName}" in the env lockfile (pnpm-lock.yaml)`)
+  }

Evidence

The code reads version directly from the attacker-controlled env lockfile and later uses it as a
path segment in the computed global-virtual-store relative path. That relative path is then joined
onto the store links directory and passed to the package materialization/import routines, creating a
filesystem write primitive if version contains traversal components. The newly added validation
gate only checks dependency *names*, not versions, so it doesn’t block this vector.

installing/env-installer/src/installConfigDeps.ts[139-152]
installing/env-installer/src/installConfigDeps.ts[198-227]
installing/env-installer/src/installConfigDeps.ts[60-98]
deps/graph-hasher/src/index.ts[265-286]
installing/env-installer/src/installConfigDeps.ts[316-336]
installing/env-installer/src/resolveOptionalSubdeps.ts[33-42]
pacquet/crates/env-installer/src/install_config_deps.rs[63-97]
pacquet/crates/env-installer/src/install_config_deps.rs[342-372]
pacquet/crates/graph-hasher/src/global_virtual_store_path.rs[125-153]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The env lockfile (`pnpm-lock.yaml`) is attacker-controlled input. This PR adds validation for config dependency names and optional subdependency names, but it does **not** validate the corresponding `version` strings before they are used to form global-virtual-store relative paths (`<name>/<version>/<hash>`). A malicious `version` containing `../` can therefore still cause `path.join(storeDir/links, relPath, ...)` (or Rust `Path::join`) to normalize outside the intended store links directory and be written to during package materialization.
## Issue Context
- In TypeScript, `version` is read verbatim from `lockfile.importers['.'].configDependencies` and stored into `normalizedDeps`, then passed into `calcGlobalVirtualStorePathWithSubdeps(...)`, whose implementation formats a path string containing `${version}`.
- The resulting path is used as the target directory for `store.importPackage(...)`.
- Pacquet mirrors the same structure: `dep.version` is passed into `calc_global_virtual_store_path_with_subdeps(...)`, and the resulting path is joined onto `store_dir.links()` before materialization.
## Fix Focus Areas
- installing/env-installer/src/installConfigDeps.ts[132-152]
- installing/env-installer/src/installConfigDeps.ts[59-98]
- installing/env-installer/src/installConfigDeps.ts[190-229]
- pacquet/crates/env-installer/src/install_config_deps.rs[342-372]
- pacquet/crates/env-installer/src/install_config_deps.rs[63-97]
### Concrete fix
1. Extend the new chokepoint (`assertValidConfigDepNames` / `assert_valid_config_dep_names`) to also validate:
- each config dep `version`
- each optional subdep `version`
2. Prefer a strict semver parse/validation (since config deps are resolved to concrete versions anyway):
- TS: `semver.valid(version) != null` (or equivalent exact-version predicate used elsewhere in env-installer)
- Rust: use the existing `node-semver` workspace dependency (already present) to parse/validate versions.
3. Add regression tests for malicious traversal-shaped **versions** (both parent config dep and optional subdep) asserting the install is rejected and no escaped path is created.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

verifyEnvLockfile() destructures { version } from each configDependencies entry without
validating that the entry value is a non-null object, so a crafted pnpm-lock.yaml like
configDependencies: { foo: null } can throw a runtime TypeError during install. This bypasses the
intended controlled PnpmError path and yields an install-time crash (DoS) for malformed lockfiles.

Code

installing/env-installer/src/verifyEnvLockfile.ts[R15-25]

+  const configDeps = envLockfile.importers['.']?.configDependencies
+  assertValidDependencyAliases(configDeps, 'The configDependencies in pnpm-lock.yaml')
+  if (configDeps == null) return
+  for (const [name, { version }] of Object.entries(configDeps)) {
+    assertValidConfigDepVersion(name, version)
+    const optionalDeps = envLockfile.snapshots[`${name}@${version}`]?.optionalDependencies
+    if (optionalDeps == null) continue
+    assertValidDependencyAliases(optionalDeps, `The optionalDependencies of config dependency "${name}" in pnpm-lock.yaml`)
+    for (const [subdepName, subdepVersion] of Object.entries(optionalDeps)) {
+      assertValidConfigDepVersion(subdepName, subdepVersion)
+    }

Evidence

The verifier destructures { version } directly from untrusted lockfile entry values, while the
lockfile reader does not enforce any per-entry schema; the same destructuring pattern exists in
normalizeFromLockfile, so malformed values can crash the process instead of producing a controlled
pnpm error.

installing/env-installer/src/verifyEnvLockfile.ts[14-26]
lockfile/fs/src/envLockfile.ts[27-56]
installing/env-installer/src/installConfigDeps.ts[170-178]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`verifyEnvLockfile()` currently assumes `importers['.'].configDependencies[name]` is an object with a string `version`. If a malicious/garbled env lockfile contains `null` (or other unexpected types), destructuring `for (const [name, { version }] of Object.entries(configDeps))` can throw a `TypeError` before any `PnpmError` is raised, resulting in an uncontrolled install-time crash.
### Issue Context
`readEnvLockfile()` only validates top-level keys are objects; it does not validate the per-dependency entry shapes. Both `verifyEnvLockfile()` and `normalizeFromLockfile()` destructure the same `{ version }` shape.
### Fix Focus Areas
- installing/env-installer/src/verifyEnvLockfile.ts[14-27]
### Suggested fix
1. Before destructuring, validate that `configDeps` is a plain object (or at least `typeof === 'object' && !Array.isArray(...)`) and that each entry value is a non-null object.
2. Validate that `version` is a string before passing it to `assertValidConfigDepVersion`.
3. Similarly validate that `optionalDependencies` is an object and that each optional dep version is a string.
4. When any of these shape checks fail, throw a controlled `PnpmError('ENV_LOCKFILE_CORRUPTED', ...)` (or another appropriate pnpm error) rather than allowing a raw `TypeError` to bubble.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In assertValidConfigDepVersion/assert_valid_config_dep_version, the validator only checks that
the semver parses, but does not enforce that the input is already in canonical/exact form by
round-tripping back to the same string (an exactness policy enforced elsewhere in the repo). Because
the raw version string is embedded directly into // store paths and tarball URL/path
construction, accepting non-canonical-but-parseable versions can lead to inconsistent on-disk layout
or unexpected install failures despite passing validation.

Code

installing/env-installer/src/assertValidConfigDepVersion.ts[R8-15]

+export function assertValidConfigDepVersion (name: string, version: string): void {
+  if (semver.valid(version) == null) {
+    throw new PnpmError(
+      'INVALID_CONFIG_DEP_VERSION',
+      `The config dependency "${name}" has an invalid version "${version}"`,
+      { hint: 'A config dependency version must be an exact semver version.' }
+    )
+  }

Evidence

The cited validators currently treat “exact” as merely “parseable”: the TypeScript implementation
only checks semver.valid(version) != null (even though semver.valid() can effectively
canonicalize/clean input) and the Rust implementation only checks that version.parse::() succeeds,
without verifying that the parsed value serializes back to the original string. The repo already
demonstrates an explicit exact-version policy elsewhere (e.g., comparing a cleaned version against
the input in pnpm, and pacquet’s exact_version() helper enforcing `parsed.to_string() ==
version`), indicating that non-canonical forms are intentionally rejected in other paths;
additionally, both descriptions note that the raw version is used as a literal path segment in the
// store layout, making non-canonical acceptance directly observable as inconsistent store
paths/behavior.

installing/env-installer/src/assertValidConfigDepVersion.ts[1-16]
config/reader/src/index.ts[807-817]
deps/graph-hasher/src/index.ts[280-286]
pacquet/crates/env-installer/src/install_config_deps.rs[342-385]
pacquet/crates/cli/src/cli_args.rs[652-655]
pacquet/crates/graph-hasher/src/global_virtual_store_path.rs[142-153]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`assertValidConfigDepVersion()` / `assert_valid_config_dep_version()` currently accept any semver string that is parseable, but they do not ensure the input is already canonical/exact (i.e., that canonicalization or round-trip stringification yields the same string). We want these validators to enforce an *exact* version string before it is used as a filesystem path segment (and for related tarball URL/path construction), preventing inconsistent store layout and unexpected install behavior.
## Issue Context
- In the TS path, `semver.valid(version)` can return a cleaned canonical version that differs from the input; elsewhere in the repo, exactness is enforced by comparing the cleaned version to the original input and rejecting when they differ.
- In the Rust path, `version.parse::<node_semver::Version>()` only checks parseability; pacquet already has an `exact_version()` helper that enforces `parsed.to_string() == version`, indicating parseable-but-non-exact inputs exist and are intentionally rejected in other code paths.
- The raw `version` is embedded into `<name>/<version>/<hash>` store paths (and related tarball URL/path construction), so accepting non-canonical versions can change on-disk layout even when the semantic version is equivalent.
## Fix Focus Areas
- installing/env-installer/src/assertValidConfigDepVersion.ts[1-16]
- pacquet/crates/env-installer/src/install_config_deps.rs[374-385]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The pacquet InvalidConfigDepVersion diagnostic format string includes an extra trailing quote, so
the user-facing error message will end with an unintended ". This is a minor but user-visible
regression in error reporting for invalid config-dependency versions.

Code

pacquet/crates/env-installer/src/errors.rs[66]

+    #[display(r#"The config dependency "{name}" has an invalid version "{version}""#)]

Evidence

The #[display(...)] raw string literal for InvalidConfigDepVersion contains two consecutive
double quotes before the raw-string terminator (..."{version}""#), which means the rendered
message will include an unintended trailing quote.

pacquet/crates/env-installer/src/errors.rs[61-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ConfigDepError::InvalidConfigDepVersion` has a `#[display(...)]` raw string literal that contains an extra `"` at the end, which renders as a trailing quote in the displayed error message.
### Issue Context
This affects user-facing diagnostics when rejecting invalid config-dependency versions.
### Fix Focus Areas
- pacquet/crates/env-installer/src/errors.rs[66-66]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Walkthrough

Security fix that validates configDependencies and optional subdependency names and versions from pnpm-lock.yaml against valid npm package name rules and exact semver before constructing any filesystem paths. Both the TypeScript (pnpm) and Rust (pacquet) env-installer implementations are patched in parallel, with null-prototype object hardening and rejection of traversal-shaped and __proto__ keys. Validation gates are added at both the lockfile and manifest entry points, preventing side effects from partial processing.

Changes

TypeScript (pnpm) env-installer — validation gates and null-prototype hardening

Rust (pacquet) env-installer — validation at lockfile and manifest entry points

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~28 minutes

Possibly related PRs

• pnpm/pnpm#11725: Introduces optionalSubdepIds and optional subdependency filtering logic in installConfigDeps.ts that this PR now hardens with null-prototype objects and validates for traversal/__proto__ names.
• pnpm/pnpm#12285: Main PR's installConfigDeps now relies on assertValidDependencyAliases to validate config dependency names before path construction, which is directly aligned with the retrieved PR's changes that harden dependency alias validation to reject path-traversal segments used in symlink/path creation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

Full review finished.