GHSA-7VHP-VF5G-R2FW
Vulnerability from github – Published: 2026-01-07 19:06 – Updated: 2026-01-08 20:05Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pnpm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69263"
],
"database_specific": {
"cwe_ids": [
"CWE-494"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-07T19:06:59Z",
"nvd_published_at": "2026-01-07T22:15:43Z",
"severity": "HIGH"
},
"details": "### Summary\n\nHTTP 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.\n\n### Details\n\nWhen a package depends on an HTTP tarball URL, pnpm\u0027s tarball resolver returns only the URL without computing an integrity hash:\n\n`resolving/tarball-resolver/src/index.ts`:\n```javascript\nreturn {\n resolution: {\n tarball: resolvedUrl,\n // No integrity field\n },\n resolvedVia: \u0027url\u0027,\n}\n```\n\nThe resulting lockfile entry has no integrity to verify:\n```yaml\nremote-dynamic-dependency@http://example.com/pkg.tgz:\n resolution: {tarball: http://example.com/pkg.tgz}\n version: 1.0.0\n```\n\nSince there is no integrity hash, pnpm cannot detect when the server returns different content. \n\nThis affects:\n- HTTP/HTTPS tarball URLs (`\"pkg\": \"https://example.com/pkg.tgz\"`)\n- Git shorthand dependencies (`\"pkg\": \"github:user/repo\"`)\n- Git URLs (`\"pkg\": \"git+https://github.com/user/repo\"`)\n\nnpm registry packages are not affected as they include integrity hashes from the registry metadata.\n\n### PoC\n\nSee attached [pnpm-bypass-integrity-poc.zip](https://github.com/user-attachments/files/23819648/pnpm-bypass-integrity-poc.zip)\n\nThe POC includes:\n- A server that returns different tarball content on each request\n- A `malicious-package` that depends on the HTTP tarball\n- A `victim` project that depends on `malicious-package`\n\nTo run:\n```bash\ncd pnpm-bypass-integrity-poc\n./run-poc.sh\n```\n\nThe output shows that each install (with `pnpm store prune` between them) downloads different code despite having a committed lockfile.\n\n### Impact\n\nAn attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. This enables:\n\n- Targeted attacks based on request metadata (IP, headers, timing)\n- Evasion of security audits (serve benign code during review, malicious code later)\n- Supply chain attacks where the malicious payload changes over time\n\nThe attack requires the victim to install a package that has an HTTP/git tarball in its dependency tree. The victim\u0027s lockfile provides no protection.",
"id": "GHSA-7vhp-vf5g-r2fw",
"modified": "2026-01-08T20:05:32Z",
"published": "2026-01-07T19:06:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-7vhp-vf5g-r2fw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69263"
},
{
"type": "WEB",
"url": "https://github.com/pnpm/pnpm/commit/0958027f88a99ccefe7e9676cdebba393dfbdc85"
},
{
"type": "PACKAGE",
"url": "https://github.com/pnpm/pnpm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "pnpm Has Lockfile Integrity Bypass that Allows Remote Dynamic Dependencies"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.