pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state during automatic version switching. This vulnerability is fixed in 10.34.2 and 11.5.3.

The version of pnpm installed on the remote host is prior to 10.34.2, or 11.x prior to 11.5.3. It is, therefore, affected by multiple vulnerabilities:

  - pnpm and pacquet expanded ${ENV_VAR} placeholders from repository-controlled .npmrc and     pnpm-workspace.yaml into registry request destinations and registry credentials. A malicious repository     could cause dependency resolution to send victim environment secrets to an attacker-selected registry     before lifecycle scripts run. (CVE-2026-55180)

  - The generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and     other opaque locators. Approval for one source string could therefore authorize a different     attacker-controlled source whose locator normalized to the same value. (CVE-2026-55487)

  - pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. A     repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that     repository-controlled dependency as an install-engine opt-in, allowing execution of arbitrary binaries.
    (CVE-2026-55697)

  - pnpm can persist package-manager bootstrap metadata in pnpm-lock.yaml. A malicious repository could     commit package-manager lockfile package records and snapshots that bypassed fresh package-manager     resolution, then cause pnpm to install and execute bytes selected by that committed lockfile state.
    (CVE-2026-55698)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can persist package-manager bootstrap
    metadata in the first YAML document of pnpm-lock.yaml. Before the patch, direct pnpm execution trusted an
    already resolved packageManagerDependencies entry when the committed env lockfile contained matching pnpm
    and @pnpm/exe versions. A malicious repository could therefore commit package-manager lockfile package
    records and snapshots that bypassed fresh package-manager resolution, then cause pnpm to install and
    execute bytes selected by that committed lockfile state during automatic version switching. This
    vulnerability is fixed in 10.34.2 and 11.5.3. (CVE-2026-55698)

ID	Name	Product	Family	Type	Severity
325222	pnpm < 10.34.2 / 11.x < 11.5.3 Multiple Vulnerabilities	Nessus	Misc.	Local	high
444017	SCA: security update for pnpm (GHSA-w466-c33r-3gjp)	Tenable Cloud Security	SCA Checks	Local	high
444017	SCA: security update for pnpm (GHSA-w466-c33r-3gjp)	Tenable Self-Hosted Container Security	SCA Checks	Local	high

Detections

Analytics

CVE-2026-55698

high

Tenable Plugins

high

high

high