CVE-2026-55180 is a medium-severity security vulnerability in pnpm (npm), affecting versions < 10.34.2. It is fixed in 10.34.2, 11.5.3.
<!-- maintainer-action:start --> Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. Advisory: CAND-PNPM-122 / GHSA-3qhv-2rgh-x77r Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-3qhv-2rgh-x77r Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 Shared patch branch: security/ghsa-batch-2026-06-09 Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22 Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec Maintainer priority: start-here Component: pnpm config/env replacement and registry auth Patch area: project .npmrc env placeholders are not expanded into registry/auth destinations Affected packages: npm:pnpm, npm:@pnpm/config.reader, rust:pacquet CWE IDs: CWE-201, CWE-200, CWE-522 Conservative CVSS: 6.5 / CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N Next action: review the shared patch branch for this component, set the final affected version range, merge and release the fix, then publish or close the advisory. Expected Patched Behavior Project .npmrc environment placeholders do not expand into registry or auth destinations; the secret is absent from the request URL and auth header. Files And Tests To Review config/reader/src/loadNpmrcFiles.ts config/reader/src/getOptionsFromRootManifest.ts config/reader/test/index.ts config/reader/test/getOptionsFromRootManifest.test.ts pacquet/crates/config/src/npmrcauth.rs pacquet/crates/config/src/npmrcauth/tests.rs pacquet/crates/config/src/workspaceyaml.rs pacquet/crates/config/src/workspaceyaml/tests.rs .changeset/sharp-registry-env-placeholders.md Focused Validation Run these from a checkout of the shared patch branch. They are the useful maintainer commands with machine-local artifact paths removed. The full patched replay for the shared branch passed with all 20 candidates marked fixed. This candidate's replay evidence is results/CAND-PNPM-122-patched-result.json. <!-- maintainer-action:end --> CAND-PNPM-122: Repository config can expand victim environment secrets into registry requests before scripts run Advisory Details Summary pnpm and pacquet expanded ${ENVVAR} 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. Details The vulnerable TypeScript pnpm path was: config/reader/src/loadNpmrcFiles.ts loaded project .npmrc and substituted environment placeholders in keys and values. config/reader/src/getOptionsFromRootManifest.ts substituted environment placeholders inside workspace registry, registries, and namedRegistries settings. config/reader/src/index.ts merged those expanded registry/auth values into pnpmConfig.registries, pnpmConfig.authConfig, and pnpmConfig.configByUri. resolving/npm-resolver/src/fetch.ts built metadata request URLs from the selected registry. network/fetch/src/fetchFromRegistry.ts dispatched the request and attached matching auth headers before install lifecycle scripts could run. The pacquet parity path was: pacquet/crates/config/src/npmrcauth.rs expanded project .npmrc placeholders while parsing registry URLs and auth values. pacquet/crates/config/src/workspaceyaml.rs expanded workspace registry placeholders. pacquet/crates/resolving-npm-resolver/src/fetchfullmetadata.rs used the configured registry URL and AuthHeaders for metadata fetches. PoC Repository .npmrc URL-path exfiltration: Repository .npmrc auth-header exfiltration: Repository pnpm-workspace.yaml URL-path exfiltration: Exploit method: The victim checks out the repository and runs a pnpm or pacquet dependency-management command with CIJOBTOKEN or another sensitive environment variable present. Before the patch, repository config expanded the placeholder to the victim secret. The resolver used the expanded registry or matching auth entry to construct a metadata request. The victim sent a request such as https://attacker.example/<secret>/<package> or Authorization: Bearer <secret> to the attacker-controlled endpoint. Validation PoC: The PoC models the pre-patch URL and Authorization-header leaks, then verifies that patched pnpm and pacquet do not keep the secret in repository-controlled registry destinations or credential values. Impact A malicious repository can disclose environment secrets present in a developer or CI process to a repository-selected registry before script controls apply. This can expose npm tokens, CI job tokens, OIDC helper inputs, or other conventional environment secrets if the attacker knows or guesses their names. Affected Products Ecosystem: npm Package name: pnpm, @pnpm/config.reader; pacquet Rust port Affected versions: current main before this patch, when project .npmrc or pnpm-workspace.yaml contains environment placeholders in registry request destinations or project .npmrc contains environment placeholders in registry credential values. Patched versions: pending release containing this patch. Severity Severity before patch: High Vector string before patch: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N Score before patch: 7.4 Severity after patch: None Vector string after patch: not vulnerable after patch Score after patch: 0.0 Rationale: exploitation is remote and low complexity once a victim runs pnpm or pacquet in the malicious repository. No attacker privileges are required, but user interaction is required. The demonstrated sink is secret disclosure through outbound registry requests, not arbitrary code execution, so confidentiality is high while integrity and availability are not directly impacted by this finding. After the patch, repository-controlled registry destinations and credential values containing env placeholders are ignored, while trusted user/global/auth.ini/CLI config still expands. Weaknesses CWE-201: Insertion of Sensitive Information Into Sent Data CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-522: Insufficiently Protected Credentials Patch The patch makes environment expansion trust-aware for registry requests: Project .npmrc no longer expands ${...} in registry, @scope:registry, proxy URL values, URL-scoped keys such as //host/${SECRET}/:authToken, or registry credential values such as //host/:authToken=${SECRET} and authToken=${SECRET}. User .npmrc, auth.ini, CLI, global, and environment config still support env expansion for trusted registry configuration. pnpm-workspace.yaml no longer expands ${...} in registry, registries, or namedRegistries URL values. Trusted user-level auth values such as //registry.npmjs.org/:authToken=${NODEAUTHTOKEN} still expand or lossy-drop as before, preserving setup-node and OIDC trusted-publishing behavior when the .npmrc is supplied as user config. Pacquet mirrors the same boundary with fromprojectini() for project .npmrc and workspace registry filtering. Changed files: config/reader/src/loadNpmrcFiles.ts config/reader/src/getOptionsFromRootManifest.ts config/reader/test/index.ts config/reader/test/getOptionsFromRootManifest.test.ts pacquet/crates/config/src/npmrcauth.rs pacquet/crates/config/src/npmrcauth/tests.rs pacquet/crates/config/src/workspaceyaml.rs pacquet/crates/config/src/workspace_yaml/tests.rs Changeset: .changeset/sharp-registry-env-placeholders.md Pacquet parity: Ported in the same patch. Pacquet dependency-management commands now parse project .npmrc with request-destination and credential-value env expansion disabled, and drop workspace registry values containing ${...} placeholders. Verification Post-patch validation: The PoC ran: Results: PoC pre-patch model showed cand122-ci-job-token in both a request URL and a bearer auth header. TypeScript build for config.reader: passed. Focused root-manifest tests: 8 passed, including workspace registry and named-registry placeholder denial. Focused config-reader integration tests: 10 passed, covering project .npmrc default registry denial, scoped registry denial, URL-scoped-key denial, project auth-value denial, trusted user .npmrc registry expansion, trusted user auth-value expansion/lossy fallback, and workspace registry denial. cargo fmt --check: passed. Focused pacquet tests: 6 passed, covering project .npmrc registry denial, scoped registry denial, URL-scoped-key denial, auth-value denial, trusted .npmrc registry expansion, and workspace YAML denial. git diff --check: passed. CVSS Reassessment The initial scan score used a repository-code-execution vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (8.8 High) The PoC and source trace showed this finding is direct secret disclosure through registry request URLs or Authorization headers, not a code execution path. The corrected vulnerable vector is: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N Corrected vulnerable score: 7.4 High. Final score after patch: 0.0.
CVE-2026-55180 has a CVSS score of 6.5 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (10.34.2, 11.5.3). Upgrading removes the vulnerable code path.
npm
pnpm (< 10.34.2)pnpm (>= 11.0.0, < 11.5.3)pnpm → 10.34.2 (npm)pnpm → 11.5.3 (npm)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-55180 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-55180 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-55180 in your environment →Upgrade the following packages to resolve this vulnerability:
pnpm to 10.34.2 or laterpnpm to 11.5.3 or laterKodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-55180 is a medium-severity security vulnerability in pnpm (npm), affecting versions < 10.34.2. It is fixed in 10.34.2, 11.5.3.
CVE-2026-55180 has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
pnpm (npm) versions < 10.34.2 is affected.
Yes. CVE-2026-55180 is fixed in 10.34.2, 11.5.3. Upgrade to this version or later.
Whether CVE-2026-55180 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
pnpm to 10.34.2 or laterpnpm to 11.5.3 or later