CVE-2025-69263 in pnpm
Summary
by MITRE • 01/08/2026
pnpm is a package manager. Versions 10.26.2 and below store HTTP tarball dependencies (and git-hosted tarballs) in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed. An attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. 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. This issue is fixed in version 10.26.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 01/13/2026
The vulnerability described in CVE-2025-69263 represents a critical security flaw in the pnpm package manager affecting versions 10.26.2 and earlier. This issue stems from the improper handling of HTTP tarball dependencies within the package lockfile mechanism, creating a fundamental trust violation in the dependency resolution process. The core problem lies in the absence of integrity hashes for HTTP and git-hosted tarball dependencies, which should serve as cryptographic checksums to verify the authenticity and integrity of downloaded packages. Without these hashes, the package manager cannot validate that the content received matches what was originally intended, effectively nullifying the security guarantees provided by the lockfile system.
The technical implementation flaw manifests when pnpm processes dependencies that reference remote tarball locations through HTTP or git protocols. During the installation process, the system downloads these tarballs from remote servers without performing cryptographic verification against the expected content. This vulnerability creates a persistent attack surface where malicious actors can exploit the trust model by serving different content to different users or environments. The attack vector requires a victim to install a package that contains an HTTP or git tarball dependency in its dependency tree, making it particularly insidious as it can be hidden within legitimate package chains. The lockfile, which traditionally serves as a security control by ensuring reproducible builds, becomes ineffective in this scenario because it lacks the integrity verification mechanisms needed to detect content substitution attacks.
The operational impact of this vulnerability extends beyond simple code substitution, creating a complex attack surface that can compromise entire CI/CD pipelines and development environments. Attackers can exploit this weakness to deliver malicious code to specific users or environments while maintaining benign behavior for others, making detection extremely difficult. The vulnerability directly violates security principles outlined in CWE-284 Access Control and CWE-345 Insufficient Verification of Data Authenticity, as it fails to verify the authenticity of downloaded dependencies. In practice, this means that developers working with pnpm versions affected by this vulnerability face potential code injection, supply chain attacks, and credential theft scenarios where attackers can modify package contents without detection. The implications are particularly severe in enterprise environments where automated deployment systems rely on lockfiles for consistent and secure package installations.
The fix implemented in version 10.26.0 addresses this vulnerability by introducing proper integrity hash validation for HTTP and git-hosted tarball dependencies within the lockfile system. This update ensures that all tarball dependencies are cryptographically verified against their expected content, restoring the trust model that lockfiles are designed to provide. Organizations should immediately upgrade to version 10.26.0 or later to mitigate this risk, while also implementing additional security measures such as registry monitoring and dependency verification processes. The vulnerability aligns with ATT&CK technique T1133 External Remote Services, as it exploits the trust relationship between package managers and remote package repositories. Security teams should also consider implementing network-level monitoring to detect unusual package download patterns and establish automated verification processes for critical dependencies to prevent exploitation of similar vulnerabilities in other package management systems.