chore(deps): update pnpm to v10.27.0 [security] #136

renovate · 2026-01-08T06:25:28Z

This PR contains the following updates:

Package	Change	Age	Confidence
pnpm (source)	`10.15.1` → `10.27.0`

Warning

Deprecated preset: `Kong/public-shared-renovate:kong-frontend-config`

Your config references a deprecated preset. To prevent disruption, this file now composes the org default building blocks and layers a few tweaks so behavior stays close to the historical frontend configuration.

Recommended migration

Prefer switching to the frontend base config, which already extends the default preset:

{
  "extends": [
    "Kong/public-shared-renovate//scoped/frontend/base",
   ],
  }

This compatibility preset will be removed in January 2026. Please migrate to the default preset with local overrides before then.

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 v10+ Bypass "Dependency lifecycle scripts execution disabled by default"

CVE-2025-69264 / GHSA-379q-355j-w6rj

More information

Details

pnpm v10+ Git Dependency Script Execution Bypass

Summary

A security bypass vulnerability in pnpm v10+ allows git-hosted dependencies to execute arbitrary code during pnpm install, circumventing the v10 security feature "Dependency lifecycle scripts execution disabled by default". While pnpm v10 blocks postinstall scripts via the onlyBuiltDependencies mechanism, git dependencies can still execute prepare, prepublish, and prepack scripts during the fetch phase, enabling remote code execution without user consent or approval.

Details

pnpm v10 introduced a security feature to disable dependency lifecycle scripts by default (PR #8897). This is implemented by setting onlyBuiltDependencies = [] when no build policy is configured:

File: pkg-manager/core/src/install/extendInstallOptions.ts (lines 290-291)

if (opts.neverBuiltDependencies == null && opts.onlyBuiltDependencies == null && opts.onlyBuiltDependenciesFile == null) {
  opts.onlyBuiltDependencies = []
}

This creates an allowlist that blocks all packages from running scripts during the BUILD phase in exec/build-modules/src/index.ts.

However, git-hosted dependencies are processed differently. During the FETCH phase, git packages are prepared using preparePackage():

File: exec/prepare-package/src/index.ts (lines 28-57)

export async function preparePackage (opts: PreparePackageOptions, gitRootDir: string, subDir: string) {
  // ...
  if (opts.ignoreScripts) return { shouldBeBuilt: true, pkgDir }  // Only checks ignoreScripts, not onlyBuiltDependencies

  const execOpts: RunLifecycleHookOptions = {
    // ...
    rawConfig: omit(['ignore-scripts'], opts.rawConfig),  // Explicitly removes ignore-scripts!
  }

  // Runs npm/pnpm install
  await runLifecycleHook(installScriptName, manifest, execOpts)

  // Runs prepare scripts
  for (const scriptName of PREPUBLISH_SCRIPTS) {  // ['prepublish', 'prepack', 'publish']
    await runLifecycleHook(newScriptName, manifest, execOpts)
  }
}

The ignoreScripts option defaults to false and is completely separate from onlyBuiltDependencies. The onlyBuiltDependencies allowlist is never consulted during the fetch phase.

Affected scripts that execute during fetch:

prepare
prepublish
prepack

Attack vectors:

git+https://github.com/attacker/malicious.git
github:attacker/malicious
gitlab:attacker/malicious
bitbucket:attacker/malicious
git+ssh://[email protected]/attacker/malicious.git
git+file:///path/to/local/repo

PoC

Prerequisites:

pnpm v10.0.0 or later (tested on v10.23.0 and v11.0.0-alpha.1)
git

Steps to reproduce:

Extract the attached poc.zip
Run the PoC script:
```
cd poc
chmod +x run-poc.sh
./run-poc.sh
```
Verify the marker file was created by the malicious script:
```
cat /tmp/pnpm-vuln-poc-marker.txt
```

Manual reproduction:

Create a malicious package with a prepare script:

{
  "name": "malicious-pkg",
  "version": "1.0.0",
  "scripts": {
    "prepare": "node -e \"require('fs').writeFileSync('/tmp/pwned.txt', 'RCE!')\""
  }
}

Initialize it as a git repo and commit the files
Create a victim project that depends on it (just have to make sure it actually git clones and not just downloads a tarball):
```
{
  "dependencies": {
    "malicious-pkg": "git+file:///path/to/malicious-pkg"
  }
}
```
Run pnpm install - the prepare script executes without any warning or approval prompt

Impact

Severity: High

Who is impacted:

All pnpm v10+ users
Users who believed they were protected by the v10 "scripts disabled by default" feature
CI/CD pipelines

Attack scenarios:

Supply chain attack: An attacker compromises a dependency, adding to it a malicious git dependency that executes arbitrary code during pnpm install

What an attacker can do:

Execute arbitrary code with the victim's privileges
Exfiltrate environment variables, secrets, and credentials
Modify source code or inject backdoors
Establish persistence or reverse shells
Access the filesystem and network

Why this bypasses security expectations:

pnpm v10 changelog explicitly states "Lifecycle scripts of dependencies are not executed during installation by default"
Users expect git dependencies to follow the same security model as npm registry packages
There is no warning that git dependencies are treated differently
The onlyBuiltDependencies configuration does not affect git dependencies

Severity

CVSS Score: 8.8 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/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).

Release Notes

pnpm/pnpm (pnpm)

chore(deps): update pnpm to v10.27.0 [security] #136

chore(deps): update pnpm to v10.27.0 [security] #136

Conversation

renovate bot commented Jan 8, 2026

Deprecated preset: Kong/public-shared-renovate:kong-frontend-config

Recommended migration

pnpm Has Lockfile Integrity Bypass that Allows Remote Dynamic Dependencies

Details

Summary

Details

PoC

Impact

Severity

References

pnpm v10+ Bypass "Dependency lifecycle scripts execution disabled by default"

Details

pnpm v10+ Git Dependency Script Execution Bypass

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

Release Notes

v10.26.2: pnpm 10.26.2

Patch Changes

Platinum Sponsors

Gold Sponsors

v10.26.1: pnpm 10.26.1

Patch Changes

Platinum Sponsors

Gold Sponsors

v10.23.0: pnpm 10.23

Minor Changes

Patch Changes

Platinum Sponsors

Gold Sponsors

v10.22.0: pnpm 10.22

Minor Changes

Patch Changes

Platinum Sponsors

Gold Sponsors

Minor Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Patch Changes

Minor Changes

Patch Changes

Configuration

Deprecated preset: `Kong/public-shared-renovate:kong-frontend-config`

`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