CVE-2026-55180

What it actually does

This vulnerability allows a repository-controlled configuration file, such as .npmrc or pnpm-workspace.yaml, to expand environment-variable placeholders like ${ENV_VAR} into package registry URLs or registry authentication fields during dependency resolution. Because this occurs before lifecycle scripts run, defenses that focus only on blocking install scripts may not prevent exposure. If a developer, build worker, or automation process runs affected pnpm or pacquet against a malicious repository, environment secrets such as package tokens, CI credentials, cloud keys, or internal registry credentials can be inserted into outbound registry requests and sent to an attacker-controlled endpoint. The impact is confidentiality loss; the vulnerability does not directly provide code execution, integrity modification, or denial of service.

Why it matters to the business

An attacker can steal secrets from developer machines or CI/CD jobs simply by convincing someone or some automation to install dependencies from a malicious repository. Stolen credentials may enable unauthorized package publishing, access to private packages, source code, CI systems, cloud resources, or internal services depending on what secrets are present in the environment. The risk is highest for organizations that run dependency installation on untrusted repositories, external pull requests, open-source intake workflows, security scanning sandboxes, or CI jobs with broadly scoped environment variables. Although the EPSS score is currently low and the issue is not listed in CISA KEV, the affected tool is common in JavaScript/TypeScript supply chains and exploitation requires only user or automation interaction with a crafted repository.

How an attack unfolds

An attacker creates or modifies a repository to include a malicious .npmrc or pnpm-workspace.yaml file. The configuration references environment-variable placeholders in fields used by pnpm or pacquet to determine registry destinations or registry credentials. The attacker then convinces a victim to clone the repository, open it in a development workflow, run dependency installation, or trigger a CI job against it. When an affected version of pnpm or pacquet resolves dependencies, it expands the placeholders using environment variables from the victim process. The expanded values are incorporated into outbound registry requests, such as a registry URL, host name, path, query string, or authorization-related value. Those requests are sent to infrastructure controlled by the attacker, who captures the secret values in web server logs, DNS logs, reverse proxy logs, or package registry request logs. The attacker can then reuse the stolen credentials against package registries, CI/CD systems, cloud services, or other systems where the exposed secrets are valid.

How to fix it

Upgrade pnpm to a fixed version: 10.34.2 or later for the 10.x line, or 11.5.3 or later for the 11.x line. Ensure any use of pacquet is updated to a version that includes the same fix. Pin the package-manager version in developer tooling and CI images so vulnerable versions are not reintroduced. Rebuild base images and developer containers that include pnpm. Avoid running dependency installation for untrusted repositories with sensitive environment variables present. For CI jobs that process external contributions or unknown repositories, remove registry tokens, cloud credentials, signing keys, and broad-scoped secrets from the environment unless they are strictly required. Restrict outbound network access during dependency resolution to approved registries where practical. Review repository-controlled .npmrc and pnpm-workspace.yaml files before running package installation, especially when they contain environment-variable substitutions in registry or authentication settings. If exposure is suspected, rotate potentially leaked package registry tokens, CI tokens, cloud credentials, and other secrets that were present in affected environments.

How to confirm the fix worked

Confirm the installed pnpm version is 10.34.2 or later, or 11.5.3 or later, using `pnpm --version` in developer workstations, CI runners, build containers, and base images. Confirm pacquet versions are updated where used. Search repositories and dependency-install workflows for .npmrc and pnpm-workspace.yaml files containing ${...} substitutions in registry, scope registry, token, auth, username, password, or certificate-related settings. Review CI definitions to verify that jobs handling untrusted repositories or external pull requests do not expose sensitive secrets during `pnpm install`, `pnpm add`, `pnpm update`, or related dependency-resolution commands. Validate egress controls by confirming dependency-resolution traffic is limited to approved package registries. As a safe test, run dependency installation in a disposable environment with a non-sensitive canary environment variable and verify that affected configuration patterns do not cause the canary value to appear in outbound registry requests after upgrading.

Typical attack path

1. Create a repository containing a malicious .npmrc or pnpm-workspace.yaml file.
2. Insert ${ENV_VAR}-style placeholders into registry destination or credential-related configuration values.
3. Host or share the repository through a channel likely to be cloned, reviewed, scanned, or built.
4. Wait for a developer, automated scanner, or CI job using a vulnerable pnpm or pacquet version to run dependency resolution.
5. Capture outbound registry, HTTP, or DNS requests containing expanded environment-variable values.
6. Extract leaked secrets from attacker-controlled logs.
7. Reuse stolen credentials to access package registries, CI/CD systems, source repositories, cloud services, or private artifacts.

How to detect it

To determine whether exploitation already occurred, review dependency-install activity from developer endpoints, CI runners, build containers, and automated scanners that used affected pnpm or pacquet versions. Focus on the period since the vulnerability was introduced or, at minimum, recent builds involving unfamiliar repositories, forks, external pull requests, or projects with repository-controlled .npmrc or pnpm-workspace.yaml files. Inspect CI logs, package-manager debug logs, shell command logs, HTTP proxy logs, DNS resolver logs, EDR process/network telemetry, and package registry access logs. Look for `pnpm install`, `pnpm add`, `pnpm update`, or pacquet execution followed by outbound requests to non-standard registry hosts. Investigate requests where registry hostnames, URL paths, query strings, headers, or authentication fields contain values resembling secrets, tokens, cloud access keys, private registry tokens, or CI variables. Search repositories for ${...} substitutions in .npmrc and pnpm-workspace.yaml, especially near `registry`, `_authToken`, `_auth`, `username`, `password`, `certfile`, `keyfile`, `cafile`, or scoped registry configuration. If suspicious traffic is found, identify which environment variables were present in that job or process, rotate affected credentials, and review downstream access logs for reuse of the exposed secrets.

• .npmrc
• pnpm-workspace.yaml
• ${
• pnpm install
• pnpm add
• pnpm update
• pacquet
• _authToken=${
• _auth=${
• username=${
• password=${
• registry=https://${
• registry=http://${
• //${
• Authorization: Bearer
• npm_config_registry
• NPM_TOKEN
• PNPM_HOME

What your security team should do

• Inventory pnpm and pacquet usage across developer images, CI runners, build containers, and automation workflows.
• Upgrade pnpm to 10.34.2 or later, or 11.5.3 or later, and update pacquet where applicable.
• Prioritize CI/CD systems and workflows that install dependencies from untrusted repositories, forks, sample projects, or external submissions.
• Remove unnecessary secrets from dependency-install environments, especially for pull request validation and automated repository scanning.
• Add policy checks that flag repository-controlled .npmrc and pnpm-workspace.yaml files containing ${...} substitutions in registry or credential settings.
• Restrict outbound network access from build jobs to approved package registries and block arbitrary registry hosts where feasible.
• Review proxy, DNS, and CI logs for historical outbound requests to unusual registry domains during pnpm dependency resolution.
• Rotate any credentials that may have been present in affected environments if suspicious outbound registry traffic is identified.