What is the CVSS score of EUVD-2026-39484?

EUVD-2026-39484 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of pnpm are affected by EUVD-2026-39484?

A critical vulnerability in pnpm package manager threatens the integrity of software development pipelines by enabling attackers to inject malicious code that executes when developers clone poisoned…. A patch is available.

Is there a public PoC exploit available for EUVD-2026-39484?

Yes, a public proof-of-concept exploit is available for EUVD-2026-39484. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate EUVD-2026-39484?

Within 24 hours: Inventory all pnpm deployments in development and CI/CD environments; disable or restrict repository cloning from untrusted external sources; notify development teams of the vulnerability. Within 7 days: Implement compensating controls (repository mirrors with verification, mandatory code review gates for new sources, pnpm execution monitoring); block vulnerable versions through policy or technical controls where feasible. Within 30 days: Monitor vendor advisories for patched versions (10.34.2, 11.5.3, or newer); upon availability, validate and upgrade all systems; conduct forensic review of development machines that accessed untrusted repositories during the exposure period.

pnpm EUVD-2026-39484

| CVE-2026-55698 HIGH

Insufficient Verification of Data Authenticity (CWE-345)

2026-06-25 GitHub_M

GHSA-w466-c33r-3gjp

Authentication Bypass Pnpm Red Hat

8.8

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.8 HIGH

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

vuln.today AI

8.8 HIGH

Malicious repo is network-delivered and unauthenticated (AV:N/PR:N) but the victim must run pnpm (UI:R); resulting arbitrary code execution yields full C:H/I:H/A:H with unchanged scope.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

8.8 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jun 25, 2026 - 19:17 EUVD

Analysis Generated

Jun 25, 2026 - 18:17 vuln.today

DescriptionCVE.org

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.

AnalysisAI

Arbitrary code execution in the pnpm package manager (versions prior to 10.34.2 and 11.5.3) lets a malicious repository hijack pnpm's automatic version-switching mechanism. By committing crafted package-manager bootstrap metadata in the first YAML document of pnpm-lock.yaml - including matching pnpm and @pnpm/exe versions plus package records and snapshots - an attacker bypasses fresh package-manager resolution and causes pnpm to install and execute attacker-selected bytes when a developer runs pnpm in the cloned repo. No public exploit identified at time of analysis; the high CVSS of 8.8 reflects full confidentiality, integrity, and availability impact, gated only by the user running pnpm against the poisoned repository.

Technical ContextAI

pnpm supports automatic package-manager version switching, where it bootstraps and runs the pnpm/@pnpm/exe version pinned for a project. This bootstrap metadata (packageManagerDependencies) can be persisted in the first YAML document of the lockfile (pnpm-lock.yaml). The flaw is a CWE-345 (Insufficient Verification of Data Authenticity) issue: direct pnpm execution trusted an already-resolved packageManagerDependencies entry whenever the committed env lockfile contained matching pnpm and @pnpm/exe versions, treating committed lockfile package records and snapshots as authoritative instead of performing fresh, trusted package-manager resolution. The affected component is the pnpm CLI itself (CPE cpe:2.3:a:pnpm:pnpm), and the trust boundary crossed is the lockfile committed into a repository - untrusted external data that should never be allowed to dictate which binary pnpm fetches and executes.

RemediationAI

Vendor-released patch: upgrade pnpm to 10.34.2 (10.x line) or 11.5.3 (11.x line) as the primary and complete fix, per GitHub Security Advisory GHSA-w466-c33r-3gjp (https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp). Until you can upgrade across developer workstations and CI runners, the most effective compensating control is to avoid running pnpm directly inside untrusted or freshly cloned third-party repositories, and to disable or pin automatic package-manager version switching so pnpm does not bootstrap a version dictated by the committed lockfile (trade-off: you lose convenient per-repo automatic version selection and must manage pnpm versions explicitly). Additionally, review and scrutinize the first YAML document / packageManagerDependencies and env lockfile entries of pnpm-lock.yaml in incoming pull requests and untrusted repos before executing pnpm, and run package installs for untrusted code inside sandboxed or containerized environments to contain any execution (trade-off: added workflow friction). Pin a known-good pnpm version in CI rather than letting repos select it.