{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "11.4.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "pnpm",
        "purl": "pkg:brew/pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "git",
    "upstream_evidence": [
      {
        "ecosystem": "GIT",
        "key": "https://github.com/pnpm/pnpm",
        "name": "https://github.com/pnpm/pnpm",
        "strategy": "git",
        "subject_version": "v12.5.1"
      },
      {
        "ecosystem": "npm",
        "key": "pkg:npm/pnpm@12.5.1",
        "name": "pnpm",
        "strategy": "registry",
        "subject_version": "12.5.1"
      }
    ]
  },
  "details": "pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0.",
  "id": "BREW-pnpm-CVE-2026-50573",
  "modified": "2026-09-20T11:59:11Z",
  "published": "2026-08-13T17:28:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/50xxx/CVE-2026-50573.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50573"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Unsafe default behavior breaks integrity check",
  "upstream": [
    "GHSA-54hh-g5mx-jqcp",
    "CVE-2026-50573"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "10.34.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "pnpm@10",
        "purl": "pkg:brew/pnpm%4010"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.33.2"
            },
            {
              "fixed": "10.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "npm",
        "key": "pkg:npm/pnpm@10.34.5",
        "name": "pnpm",
        "strategy": "registry",
        "subject_version": "10.34.5"
      }
    ]
  },
  "details": "While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.\n\n## Summary\n\n`pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`.\n\nWhen a package is already locked with an `integrity` value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain `pnpm install` then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully.\n\nThis means the lockfile integrity check does not act as a hard stop by default.\n\n## Reproduction Scenario\n\n1. Run a local npm-compatible registry.\n2. Publish or serve `example-package@1.0.0` with tarball content `v1`.\n3. Install it with pnpm:\n\n```bash\npnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741\n```\n\n4. Confirm `pnpm-lock.yaml` contains the `v1` integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v1...\n```\n\n5. Change the registry metadata and tarball for the same `example-package@1.0.0` to content `v2`.\n6. On a clean store/cache, run:\n\n```bash\npnpm install --registry=http://127.0.0.1:48741\n```\n\n## Observed Behavior\n\npnpm detects the checksum mismatch:\n\n```text\nWARN Got unexpected checksum for \"http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz\".\nWanted \"sha512-...v1...\"\nGot \"sha512-...v2...\".\n\nERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.\n```\n\nHowever, the install still succeeds:\n\n```text\nINSTALL_RC=0\nINSTALLED=v2-replaced\n```\n\nThe lockfile is then rewritten to trust the new remote integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v2...\n```\n\n## Expected Behavior\n\nIf a downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`, the install should fail by default.\n\nThe lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.\n\n## Security Impact\n\nThis behavior weakens the protection normally expected from a committed lockfile.\n\nIf a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker\u0027s replacement package even though the project already has a lockfile with the original integrity.\n\nExamples of affected new or clean environments include:\n\n- an engineer setting up the project on a new machine\n- a new team member onboarding to the project\n\nIn this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in `pnpm-lock.yaml`. However, instead of failing by default, plain `pnpm install` performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.\n\nIn other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.\n\nThis is especially relevant for:\n\n- private registries that allow overwriting or republishing the same version\n- registry mirrors or proxies that can serve changed metadata and tarballs\n- compromised public or private registries\n- compromised registry proxy infrastructure\n\nThe behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.\n\nThis issue does not occur when `--frozen-lockfile` is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.\n\nHowever, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.\n\nFor that reason, it may be safer for pnpm\u0027s default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.\n\n## Comparison\n\nIn the same scenario, `npm install` with an existing `package-lock.json` fails with `EINTEGRITY` and does not install the changed tarball.\n\n`pnpm install --frozen-lockfile` also fails as expected:\n\n```text\nERR_PNPM_TARBALL_INTEGRITY\n```\n\nThe issue is specific to the default non-frozen behavior of plain `pnpm install` in non-CI environment.",
  "id": "BREW-pnpm@10-CVE-2026-50573",
  "modified": "2026-09-17T17:38:54Z",
  "published": "2026-08-13T17:28:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50573"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Unsafe default behavior breaks integrity check",
  "upstream": [
    "GHSA-54hh-g5mx-jqcp",
    "CVE-2026-50573"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "upstream_fixed_in": "10.34.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "pnpm@9",
        "purl": "pkg:brew/pnpm%409"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "npm",
        "key": "pkg:npm/pnpm@9.15.9",
        "name": "pnpm",
        "strategy": "registry",
        "subject_version": "9.15.9"
      }
    ]
  },
  "details": "While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.\n\n## Summary\n\n`pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`.\n\nWhen a package is already locked with an `integrity` value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain `pnpm install` then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully.\n\nThis means the lockfile integrity check does not act as a hard stop by default.\n\n## Reproduction Scenario\n\n1. Run a local npm-compatible registry.\n2. Publish or serve `example-package@1.0.0` with tarball content `v1`.\n3. Install it with pnpm:\n\n```bash\npnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741\n```\n\n4. Confirm `pnpm-lock.yaml` contains the `v1` integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v1...\n```\n\n5. Change the registry metadata and tarball for the same `example-package@1.0.0` to content `v2`.\n6. On a clean store/cache, run:\n\n```bash\npnpm install --registry=http://127.0.0.1:48741\n```\n\n## Observed Behavior\n\npnpm detects the checksum mismatch:\n\n```text\nWARN Got unexpected checksum for \"http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz\".\nWanted \"sha512-...v1...\"\nGot \"sha512-...v2...\".\n\nERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.\n```\n\nHowever, the install still succeeds:\n\n```text\nINSTALL_RC=0\nINSTALLED=v2-replaced\n```\n\nThe lockfile is then rewritten to trust the new remote integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v2...\n```\n\n## Expected Behavior\n\nIf a downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`, the install should fail by default.\n\nThe lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.\n\n## Security Impact\n\nThis behavior weakens the protection normally expected from a committed lockfile.\n\nIf a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker\u0027s replacement package even though the project already has a lockfile with the original integrity.\n\nExamples of affected new or clean environments include:\n\n- an engineer setting up the project on a new machine\n- a new team member onboarding to the project\n\nIn this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in `pnpm-lock.yaml`. However, instead of failing by default, plain `pnpm install` performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.\n\nIn other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.\n\nThis is especially relevant for:\n\n- private registries that allow overwriting or republishing the same version\n- registry mirrors or proxies that can serve changed metadata and tarballs\n- compromised public or private registries\n- compromised registry proxy infrastructure\n\nThe behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.\n\nThis issue does not occur when `--frozen-lockfile` is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.\n\nHowever, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.\n\nFor that reason, it may be safer for pnpm\u0027s default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.\n\n## Comparison\n\nIn the same scenario, `npm install` with an existing `package-lock.json` fails with `EINTEGRITY` and does not install the changed tarball.\n\n`pnpm install --frozen-lockfile` also fails as expected:\n\n```text\nERR_PNPM_TARBALL_INTEGRITY\n```\n\nThe issue is specific to the default non-frozen behavior of plain `pnpm install` in non-CI environment.",
  "id": "BREW-pnpm@9-CVE-2026-50573",
  "modified": "2026-08-13T17:28:25Z",
  "published": "2026-08-13T17:28:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50573"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Unsafe default behavior breaks integrity check",
  "upstream": [
    "GHSA-54hh-g5mx-jqcp",
    "CVE-2026-50573"
  ]
}

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "pnpm",
          "vendor": "pnpm",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.33.4"
            },
            {
              "status": "affected",
              "version": "\u003e= 11.0.0, \u003c 11.4.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:pnpm:pnpm:*:*:*:*:*:node.js:*:*",
              "matchCriteriaId": "F41CB711-4C82-4DEA-BC04-6DFB489B0158",
              "versionEndExcluding": "10.34.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:a:pnpm:pnpm:*:*:*:*:*:node.js:*:*",
              "matchCriteriaId": "7D7BF63F-E778-4B19-8290-D8D69305361D",
              "versionEndExcluding": "11.4.0",
              "versionStartIncluding": "11.0.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "pnpm is a package manager. Prior to 10.34.0 and 11.4.0, `pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0."
    }
  ],
  "id": "CVE-2026-50573",
  "lastModified": "2026-06-29T21:15:58.043",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 6.8,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.6,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.1,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 5.2,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-50573",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-06-25T00:00:00+00:00",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-06-25T18:16:39.687",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Vendor Advisory"
      ],
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "tags": [
        "Exploit",
        "Vendor Advisory"
      ],
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-345"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50573"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T22:52:33Z",
    "nvd_published_at": "2026-06-25T18:16:39Z",
    "severity": "MODERATE"
  },
  "details": "While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default.\n\n## Summary\n\n`pnpm install` in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`.\n\nWhen a package is already locked with an `integrity` value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain `pnpm install` then performs a resolution repair, accepts the registry\u0027s new integrity, updates the lockfile, installs the new content, and exits successfully.\n\nThis means the lockfile integrity check does not act as a hard stop by default.\n\n## Reproduction Scenario\n\n1. Run a local npm-compatible registry.\n2. Publish or serve `example-package@1.0.0` with tarball content `v1`.\n3. Install it with pnpm:\n\n```bash\npnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741\n```\n\n4. Confirm `pnpm-lock.yaml` contains the `v1` integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v1...\n```\n\n5. Change the registry metadata and tarball for the same `example-package@1.0.0` to content `v2`.\n6. On a clean store/cache, run:\n\n```bash\npnpm install --registry=http://127.0.0.1:48741\n```\n\n## Observed Behavior\n\npnpm detects the checksum mismatch:\n\n```text\nWARN Got unexpected checksum for \"http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz\".\nWanted \"sha512-...v1...\"\nGot \"sha512-...v2...\".\n\nERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.\n```\n\nHowever, the install still succeeds:\n\n```text\nINSTALL_RC=0\nINSTALLED=v2-replaced\n```\n\nThe lockfile is then rewritten to trust the new remote integrity:\n\n```yaml\npackages:\n  example-package@1.0.0:\n    resolution:\n      integrity: sha512-...v2...\n```\n\n## Expected Behavior\n\nIf a downloaded tarball does not match the integrity recorded in `pnpm-lock.yaml`, the install should fail by default.\n\nThe lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.\n\n## Security Impact\n\nThis behavior weakens the protection normally expected from a committed lockfile.\n\nIf a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker\u0027s replacement package even though the project already has a lockfile with the original integrity.\n\nExamples of affected new or clean environments include:\n\n- an engineer setting up the project on a new machine\n- a new team member onboarding to the project\n\nIn this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in `pnpm-lock.yaml`. However, instead of failing by default, plain `pnpm install` performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content.\n\nIn other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile.\n\nThis is especially relevant for:\n\n- private registries that allow overwriting or republishing the same version\n- registry mirrors or proxies that can serve changed metadata and tarballs\n- compromised public or private registries\n- compromised registry proxy infrastructure\n\nThe behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.\n\nThis issue does not occur when `--frozen-lockfile` is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content.\n\nHowever, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version.\n\nFor that reason, it may be safer for pnpm\u0027s default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile.\n\n## Comparison\n\nIn the same scenario, `npm install` with an existing `package-lock.json` fails with `EINTEGRITY` and does not install the changed tarball.\n\n`pnpm install --frozen-lockfile` also fails as expected:\n\n```text\nERR_PNPM_TARBALL_INTEGRITY\n```\n\nThe issue is specific to the default non-frozen behavior of plain `pnpm install` in non-CI environment.",
  "id": "GHSA-54hh-g5mx-jqcp",
  "modified": "2026-06-26T22:52:33Z",
  "published": "2026-06-26T22:52:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50573"
    },
    {
      "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Unsafe default behavior breaks integrity check"
}