Path traversal in pnpm config dependency lockfile handling can create symlinks outside the intended directory

pnpm is a package manager. Prior to 10.34.4 and 11.8.0, pnpm accepts package names from the env lockfile configDependencies section and uses those names directly when creating config dependency symlinks under node_modules/.pnpm-config. A malicious repository can commit a crafted pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name. During pnpm install, pnpm installs the config dependency and creates a symlink at a path derived from that name. This vulnerability is fixed in 10.34.4 and 11.8.0.

• pnpm < 10.34.4: affected.
• pnpm >= 11.0.0, < 11.8.0: affected.
• The vendor advisory lists patched ranges as >= 10.34.4, < 11.0.0 and >= 11.8.0. The status of branches outside these stated ranges should not be inferred from this record.

The root cause is CWE-22: pnpm uses external data to construct a pathname without properly constraining it to the intended directory. pnpm reads package-name keys from the env lockfile configDependencies section and uses those keys directly as path components when creating symlinks under node_modules/.pnpm-config. If a package name contains .. components, the path join can resolve to a destination outside the intended directory. The attacker-controlled input is a crafted pnpm-lock.yaml committed to a repository, and the trigger is pnpm install. The vendor advisory confirms that the behavior works with --ignore-scripts and occurs in the config dependency installation path before ordinary dependency installation, so lifecycle scripts are not required. The reachable file impact depends on path permissions and platform behavior, and the available evidence does not establish every reachable target in every deployment.

The flaw can be reached remotely when an attacker supplies a malicious or compromised repository and the victim runs pnpm install. No prior privileges are required according to the supplied metrics, but user interaction is required to install the repository. Exploitation has low complexity because the malicious input is placed in pnpm-lock.yaml. The vendor advisory publishes a local-only proof of concept demonstrating symlink creation outside the intended directory, and the record marks a public exploit as available. The supplied evidence identifies a proof of concept but does not name a campaign or victim.

pnpm can create a symlink outside the intended config dependency directory, providing a filesystem write primitive in the project directory and, under some conditions, potentially affecting paths outside the project. The practical outcome depends on the pnpm process permissions, workspace location, and platform filesystem constraints. The demonstrated impact is primarily to file integrity; the record does not establish data reading or information theft. Because the victim must install the malicious repository, the main exposure is in developer workstations, build runners, and automation that processes untrusted source.

The flaw lets a malicious repository influence where pnpm creates a symlink in the installing environment's filesystem.

• A symlink can be created in the project directory instead of only under node_modules/.pnpm-config.
• With deeper traversal, the path may extend outside the project directory, depending on permissions and platform behavior.
• This could allow modification of files or affect the integrity of a workspace and build tooling that can access those paths.
• The record does not name a victim, campaign, or specific breach.

1. Upgrade pnpm to 10.34.4 within the 10.x branch or to 11.8.0 within the 11.x branch. The advisory confirms the patched ranges as >= 10.34.4, < 11.0.0 and >= 11.8.0.
2. Before upgrading, avoid running pnpm install on untrusted repositories in workspaces with broad write access or sensitive contents. This is a temporary precaution, not a replacement for the fix.
3. Review pnpm-lock.yaml files received from external sources and isolate repositories whose env-lockfile configDependencies contain invalid names, path separators, or traversal components.
4. After updating, recheck runners and developer machines to ensure they actually use a patched pnpm version rather than only updating a project dependency.
5. If installation has already been run on a suspicious repository, inspect for symlinks outside node_modules/.pnpm-config and unexpected file changes before continuing to use the workspace.

1. Inventory pnpm versions used on developer workstations, runners, and build pipelines, then compare them with the affected branches in affected_summary.
2. Inspect the env-lockfile document in pnpm-lock.yaml, especially configDependencies keys, for names containing .., . components, absolute paths, backslashes, or platform-specific path separators.
3. For untrusted repositories that have already been installed, inspect for new symlinks outside node_modules/.pnpm-config and determine whether their destinations derive from config dependency names in the lockfile.
4. Review for unexpected workspace file changes after pnpm install. This is a supplementary defensive check, not a vendor-confirmed indicator.
5. The advisory does not provide a specific log event or IOC. Absence of unusual log evidence does not demonstrate that a system is safe.