CVE-2025-69263: pnpm Package Manager RCE Vulnerability

CVE-2025-69263 Overview

CVE-2025-69263 is a supply chain security vulnerability affecting pnpm, a popular Node.js package manager. Versions 10.26.2 and below fail to store integrity hashes for HTTP tarball dependencies and git-hosted tarballs in the lockfile. This critical oversight allows a remote server to serve different content on each installation, even when a lockfile is committed to the repository, effectively bypassing the lockfile's primary security guarantee.

Critical Impact

Attackers who publish packages with HTTP tarball dependencies can serve different malicious code to different users or CI/CD environments, enabling targeted supply chain attacks that bypass lockfile protections.

Affected Products

• pnpm versions 10.26.2 and below
• Applications using HTTP tarball dependencies in their dependency tree
• CI/CD pipelines relying on pnpm lockfile integrity

Discovery Timeline

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

Technical Details for CVE-2025-69263

Vulnerability Analysis

This vulnerability represents a Download of Code Without Integrity Check (CWE-494) in pnpm's lockfile handling mechanism. The core issue lies in how pnpm processes HTTP tarball dependencies and git-hosted tarballs. When these types of dependencies are resolved, pnpm fails to compute and store cryptographic integrity hashes in the pnpm-lock.yaml file.

Lockfiles serve as a critical security mechanism in modern package managers, ensuring that every installation reproduces the exact same dependency tree with identical package contents. Without integrity hashes, the lockfile becomes merely a list of URLs rather than a cryptographic commitment to specific package contents. This allows a malicious package maintainer or a compromised hosting server to serve different code to different users while the lockfile appears unchanged.

The attack surface is particularly concerning for enterprise environments where CI/CD pipelines may receive different code than developer machines, making traditional code review processes ineffective at detecting malicious modifications.

Root Cause

The root cause stems from incomplete integrity verification in pnpm's dependency resolution and lockfile generation logic. When processing HTTP tarball dependencies, the resolver retrieves and installs packages without computing SHA-512 or other integrity hashes. The lockfile writer then stores the dependency reference without the integrity field that would normally contain a Subresource Integrity (SRI) hash.

This architectural gap exists specifically for HTTP-based tarballs and git-hosted tarballs, while npm registry packages typically include integrity information from the registry itself.

Attack Vector

The attack exploits the network-based nature of HTTP tarball dependencies. An attacker can publish a legitimate-appearing package to npm that references an HTTP tarball they control. The attack flow proceeds as follows:

1. Attacker publishes a package with an HTTP tarball dependency to a public or private registry
2. Victim installs the package, and pnpm adds the dependency to the lockfile without an integrity hash
3. Victim commits the lockfile to version control
4. Attacker modifies the tarball content on their server
5. Subsequent installations (other developers, CI/CD) receive the modified malicious code
6. The lockfile provides no warning since no integrity hash was ever recorded

The vulnerability requires user interaction (installing the malicious package) and network access, with the attacker needing to control or compromise the HTTP tarball hosting location.

The fix introduces proper project registration and integrity tracking through the @pnpm/package-store module:

 } 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: GitHub Commit

The patch adds the package-store module as a dependency in the build configuration:

     {
       "path": "../../resolving/resolver-base"
     },
+    {
+      "path": "../../store/package-store"
+    },
     {
       "path": "../modules-yaml"
     },

Source: GitHub Commit

Detection Methods for CVE-2025-69263

Indicators of Compromise

• Lockfile entries for HTTP tarball dependencies lacking integrity field
• Dependencies with URLs starting with http:// or https:// pointing to non-registry hosts
• Discrepancies between installed package contents across different environments
• Git-hosted tarball references in pnpm-lock.yaml without cryptographic verification

Detection Strategies

• Audit pnpm-lock.yaml files for dependencies referencing HTTP tarballs or git-hosted packages
• Implement CI/CD checks that compare package checksums between development and deployment environments
• Monitor for unexpected network requests to non-standard package hosting locations during installation
• Use software composition analysis (SCA) tools to flag dependencies without integrity verification

Monitoring Recommendations

• Enable verbose logging during pnpm installations to track all dependency sources
• Implement network monitoring to detect connections to unexpected tarball hosting servers
• Configure alerts for lockfile modifications that remove or omit integrity hashes
• Review dependency trees for packages introducing HTTP tarball dependencies

How to Mitigate CVE-2025-69263

Immediate Actions Required

• Upgrade pnpm to version 10.26.0 or later immediately
• Audit existing pnpm-lock.yaml files for HTTP tarball dependencies without integrity hashes
• Re-generate lockfiles after upgrading to ensure integrity hashes are computed
• Review dependency trees for packages using HTTP or git-hosted tarballs

Patch Information

The vulnerability is fixed in pnpm version 10.26.0. The fix ensures that HTTP tarball dependencies and git-hosted tarballs are stored in the lockfile with proper integrity hashes, preventing content substitution attacks.

For detailed patch information, refer to the GitHub Security Advisory and the commit implementing the fix.

Workarounds

• Avoid using packages that depend on HTTP tarballs until upgrading is possible
• Manually verify package contents against known-good checksums before deployment
• Use private registries with integrity verification for all dependencies
• Implement strict network policies preventing installations from untrusted HTTP sources

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

# Verify pnpm version
pnpm --version

# Regenerate lockfile with integrity hashes
rm pnpm-lock.yaml
pnpm install

# Audit lockfile for missing integrity hashes
grep -B5 -A5 "tarball:" pnpm-lock.yaml | grep -L "integrity:"