CVE-2025-69263: Pnpm Package Manager RCE Vulnerability

CVE-2025-69263 Overview

CVE-2025-69263 affects pnpm, a widely used JavaScript package manager. Versions 10.26.2 and below store HTTP tarball dependencies and git-hosted tarballs in the lockfile without integrity hashes. Remote servers can serve different content on each install, even when a lockfile is committed to source control. An attacker who publishes a package containing an HTTP tarball dependency can serve distinct payloads to different users or CI/CD pipelines. The victim's lockfile provides no protection against this substitution. The vulnerability is classified under [CWE-494] (Download of Code Without Integrity Check) and requires the victim to install a package that transitively pulls an HTTP or git tarball dependency.

Critical Impact

Attackers can deliver tailored malicious code to specific developers or build environments through dependency substitution, bypassing lockfile-based supply chain controls.

Affected Products

• pnpm versions 10.26.2 and below
• Node.js projects using pnpm with HTTP tarball dependencies
• CI/CD environments resolving dependencies via pnpm

Discovery Timeline

• 2026-01-07 - CVE-2025-69263 published to NVD
• 2026-01-12 - Last updated in NVD database

Technical Details for CVE-2025-69263

Vulnerability Analysis

The defect lives in how pnpm records non-registry dependencies in its lockfile. When a dependency is specified as an HTTP tarball URL or a git-hosted tarball, pnpm stores only the URL reference in pnpm-lock.yaml and omits the cryptographic integrity hash (sha512/sha1) that registry-sourced packages receive. On subsequent installs, pnpm re-fetches the tarball from the remote URL and accepts whatever content the server returns. Because no integrity comparison occurs, the lockfile cannot detect content drift between installs. This breaks the core trust guarantee that lockfiles provide: reproducible, verifiable dependency resolution.

Root Cause

The root cause is the absence of integrity metadata for HTTP and git tarball entries in the lockfile schema and resolution pipeline. Registry dependencies are recorded with content-addressable hashes derived at first resolution. HTTP and git tarball resolvers skipped the same hash-capture step, leaving installs dependent on transport-layer trust alone.

Attack Vector

A malicious package author publishes a package whose dependency tree includes an HTTP tarball URL pointing to an attacker-controlled server. Victims add the top-level package and commit the resulting lockfile. The attacker's server then performs request fingerprinting on each install — inspecting User-Agent, IP range, or CI environment headers — and returns benign code to most callers while delivering a malicious tarball to targeted developers or build runners. The result is selective code execution at install time with full privileges of the install process.

The upstream fix adds integrity registration through the package store. See the relevant patch in pkg-manager/get-context/src/index.ts:

 } from '@pnpm/types'
 import pathAbsolute from 'path-absolute'
 import clone from 'ramda/src/clone'
+import { registerProject } from '@pnpm/package-store'
 import { readLockfiles } from './readLockfiles.js'

Source: pnpm commit 0958027

Detection Methods for CVE-2025-69263

Indicators of Compromise

• Lockfile entries containing tarball: or raw http(s):// URLs in pnpm-lock.yaml without an adjacent integrity: field
• Outbound install-time network requests to non-registry hosts during pnpm install
• Unexpected post-install script execution or file writes outside node_modules
• Build artifacts that differ across CI runs despite an unchanged lockfile

Detection Strategies

• Audit pnpm-lock.yaml across all repositories for dependencies resolved via HTTP or git tarball URLs
• Compare tarball content hashes captured from multiple install runs against the same lockfile to detect drift
• Run pnpm version checks in CI to flag installs executed on vulnerable releases (pnpm --version less than or equal to 10.26.2)

Monitoring Recommendations

• Log and alert on outbound network connections from build agents to hosts outside approved registries
• Track process activity spawned by pnpm, node, and lifecycle scripts during install for anomalous executions
• Capture and retain full pnpm install logs in CI for forensic review of resolution sources

How to Mitigate CVE-2025-69263

Immediate Actions Required

• Upgrade pnpm to the patched release referenced in the GitHub Security Advisory GHSA-7vhp-vf5g-r2fw
• Inventory all projects for direct or transitive dependencies that resolve via HTTP or git tarball URLs and replace them with registry-published versions
• Pin and mirror critical dependencies to an internal registry that enforces integrity hashing

Patch Information

The pnpm maintainers released a fix that registers project context with the package store and ensures integrity handling for non-registry tarballs. Review the upstream change in the pnpm commit 0958027 and the advisory at GHSA-7vhp-vf5g-r2fw for upgrade guidance.

Workarounds

• Block install-time egress from build agents to all hosts except your approved package registries
• Replace HTTP tarball dependencies with versions published to a trusted registry
• Use a private registry proxy that caches and pins tarball content by hash on first fetch

# Verify pnpm version and audit lockfile for unhashed tarball entries
pnpm --version
grep -nE 'tarball: https?://|resolution:.*http' pnpm-lock.yaml

# Upgrade pnpm to the patched release
npm install -g pnpm@latest