Vulnerability-Lookup

CVE-2026-50573 (GCVE-0-2026-50573)

Vulnerability from cvelistv5 – Published: 2026-06-25 16:50 – Updated: 2026-06-26 03:56

Title

pnpm: Unsafe default behavior breaks integrity check

Summary

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's 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.

Severity

6.8 (Medium)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator (v2.0.3)

CWE

CWE-345 - Insufficient Verification of Data Authenticity

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/pnpm/pnpm/security/advisories/…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
pnpm	pnpm	Affected: < 10.33.4 Affected: >= 11.0.0, < 11.4.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-50573",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-25T00:00:00+00:00",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-26T03:56:17.356Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "pnpm",
          "vendor": "pnpm",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 10.33.4"
            },
            {
              "status": "affected",
              "version": "\u003e= 11.0.0, \u003c 11.4.0"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345: Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-25T16:50:21.093Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp"
        }
      ],
      "source": {
        "advisory": "GHSA-54hh-g5mx-jqcp",
        "discovery": "UNKNOWN"
      },
      "title": "pnpm: Unsafe default behavior breaks integrity check"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-50573",
    "datePublished": "2026-06-25T16:50:21.093Z",
    "dateReserved": "2026-06-04T21:34:34.427Z",
    "dateUpdated": "2026-06-26T03:56:17.356Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-50573",
      "date": "2026-06-27",
      "epss": "0.00108",
      "percentile": "0.01457"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-50573\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-06-25T17:54:41.646397Z\"}}}], \"references\": [{\"url\": \"https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-06-25T17:54:48.775Z\"}}], \"cna\": {\"title\": \"pnpm: Unsafe default behavior breaks integrity check\", \"source\": {\"advisory\": \"GHSA-54hh-g5mx-jqcp\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 6.8, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"REQUIRED\", \"attackComplexity\": \"HIGH\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"pnpm\", \"product\": \"pnpm\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 10.33.4\"}, {\"status\": \"affected\", \"version\": \"\u003e= 11.0.0, \u003c 11.4.0\"}]}], \"references\": [{\"url\": \"https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp\", \"name\": \"https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp\", \"tags\": [\"x_refsource_CONFIRM\"]}], \"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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-345\", \"description\": \"CWE-345: Insufficient Verification of Data Authenticity\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-06-25T16:50:21.093Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-50573\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-06-26T03:56:17.356Z\", \"dateReserved\": \"2026-06-04T21:34:34.427Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-06-25T16:50:21.093Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-54HH-G5MX-JQCP

Vulnerability from github – Published: 2026-06-26 22:52 – Updated: 2026-06-26 22:52

Summary

pnpm: Unsafe default behavior breaks integrity check

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.

Summary

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's 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.

Reproduction Scenario

Run a local npm-compatible registry.
Publish or serve example-package@1.0.0 with tarball content v1.
Install it with pnpm:

pnpm add example-package@1.0.0 --registry=http://127.0.0.1:48741

Confirm pnpm-lock.yaml contains the v1 integrity:

packages:
  example-package@1.0.0:
    resolution:
      integrity: sha512-...v1...

Change the registry metadata and tarball for the same example-package@1.0.0 to content v2.
On a clean store/cache, run:

pnpm install --registry=http://127.0.0.1:48741

Observed Behavior

pnpm detects the checksum mismatch:

WARN Got unexpected checksum for "http://127.0.0.1:48741/example-package/-/example-package-1.0.0.tgz".
Wanted "sha512-...v1..."
Got "sha512-...v2...".

ERR_PNPM_TARBALL_INTEGRITY The lockfile is broken! Resolution step will be performed to fix it.

However, the install still succeeds:

INSTALL_RC=0
INSTALLED=v2-replaced

The lockfile is then rewritten to trust the new remote integrity:

packages:
  example-package@1.0.0:
    resolution:
      integrity: sha512-...v2...

Expected Behavior

If a downloaded tarball does not match the integrity recorded in pnpm-lock.yaml, the install should fail by default.

The lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior.

Security Impact

This behavior weakens the protection normally expected from a committed lockfile.

If 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's replacement package even though the project already has a lockfile with the original integrity.

Examples of affected new or clean environments include:

an engineer setting up the project on a new machine
a new team member onboarding to the project

In 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.

In 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.

This is especially relevant for:

private registries that allow overwriting or republishing the same version
registry mirrors or proxies that can serve changed metadata and tarballs
compromised public or private registries
compromised registry proxy infrastructure

The behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair.

This 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.

However, 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.

For that reason, it may be safer for pnpm's 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.

Comparison

In the same scenario, npm install with an existing package-lock.json fails with EINTEGRITY and does not install the changed tarball.

pnpm install --frozen-lockfile also fails as expected:

ERR_PNPM_TARBALL_INTEGRITY

The issue is specific to the default non-frozen behavior of plain pnpm install in non-CI environment.

Severity

6.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "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"
}

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.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2026-50573 (GCVE-0-2026-50573)

GHSA-54HH-G5MX-JQCP

Summary

Reproduction Scenario

Observed Behavior

Expected Behavior

Security Impact

Comparison

Tags

Sightings

Nomenclature