The Credential Forwarding Mechanism
pnpm—increasingly adopted as a default package manager in JavaScript organizations and a common choice in Next.js project bootstrapping—carries a behavior cataloged in June 2026 in GitHub's Advisory Database as GHSA-cjhr-43r9-cfmw. When a repository includes a local .npmrc file specifying a custom package registry, pnpm forwards the user's unscoped npm authentication token to that registry. The registry destination is determined by the repository configuration, not the developer. This advisory documents pnpm as the reported case, not the only one with structural exposure. npm also reads project-level .npmrc registry directives and forwards authentication headers to the specified endpoint when an unscoped _authToken is present in the user's global configuration. Yarn v1 (classic) inherits the same .npmrc resolution path. The mechanistic distinction documented in GHSA-cjhr-43r9-cfmw is that pnpm forwards an unscoped _authToken to any registry URL a project .npmrc specifies, whereas npm's default credential handling requires the token to be explicitly scoped to the destination registry URL—a scoping requirement that creates an additional configuration barrier. Organizations relying on npm's default behavior as a mitigating control should verify that registry-scoped tokens are enforced in their environments rather than assume it. The broader structural condition—that a repository's configuration file can redirect a developer's credentials to an arbitrary endpoint—is an npm ecosystem credential hygiene issue; pnpm is the currently-documented instance. Three conditions converge to enable credential capture: a developer must clone a repository containing a malicious .npmrc, carry an unscoped _authToken in their user-level npm configuration, and execute pnpm install. Enterprise npm environments, organizational CI systems, and developers with publish permissions routinely store unscoped tokens as their default registry credential.
Agentic Workflows Extend an Established Exposure Surface
CI/CD pipelines—Jenkins, GitHub Actions, CircleCI, GitLab CI—have executed pnpm install and npm install autonomously without human review of repository .npmrc configuration files for over a decade. Operators configure runner environments and pipeline definitions; individual repository files, including .npmrc, pass through the execution context without per-file inspection at install time. This structural exposure predates AI coding agents and remains present in every organization running automated dependency installation. AI coding agents extend this autonomous execution surface in a specific direction: they lower the barrier to interacting with repositories outside an organization's governance boundary. A CI pipeline runs against a defined set of organizational repositories that were deliberately configured by engineering teams. An AI coding agent, following a task description, may clone and install dependencies from repositories that no organizational policy has reviewed. The .npmrc embedded in a compromised or unvetted repository passes through the agent's execution context, forwarding the developer's credential to an attacker-controlled endpoint without a human review checkpoint at the repository-content layer. The attack surface grows not because the forwarding mechanism is new, but because the population of repositories agents interact with is substantially less governed than the pipelines organizations deliberately built. Developers reviewing an agent's task output see the dependency installation result—not the credential transit event that may have occurred between clone and install. As of 2024, 76% of developers reported using or planning to use AI coding tools—a figure that represents a floor, not a ceiling, given adoption velocity since that survey. Each additional developer adopting agent-assisted workflows without registry-scoped credentials expands the credential exposure surface across their organization's CI and workstation environments.
What Credential Capture Enables
npm authentication tokens carry access proportional to their scope. An unscoped token—the type most commonly configured as a default registry credential—may carry publish permissions for packages in the account holder's namespace. An attacker who captures this credential via a malicious registry endpoint can release new package versions under the victim's identity, provided the token carries publish scope. Full downstream impact requires the chain to complete: the captured token must carry publish scope, the attacker must act before token rotation, and downstream consumers must pull without cryptographic hash pinning. Each step carries friction. Credential capture alone, however, creates durable leverage that persists until active token rotation—the window between capture and detection defines the exposure period. The npm registry hosts over 2.1 million packages; the downstream reach of any credential depends on the account's publish surface and the install patterns of its consumers.
Remediation Status
GHSA-cjhr-43r9-cfmw was published to GitHub's Advisory Database in June 2026. pnpm's maintainers classify this credential forwarding behavior as an aspect of the package manager's intended registry resolution design, not a defect to be patched in a future release. There is no updated pnpm version that changes this behavior; the advisory's remediation path is a credential configuration change rather than a software upgrade. Organizations should consult the GHSA record directly for current CVSS severity classification, as scoring may update post-disclosure. The required action: replace unscoped _authToken entries in user-level npm configuration (~/.npmrc) with registry-scoped credentials. Scoped tokens bind authentication to a specific registry URL, preventing forwarding to repository-specified endpoints regardless of what a project .npmrc contains. This change requires no pnpm version upgrade and applies immediately upon credential rotation. Organizations running pnpm in CI/CD environments should audit service account configurations for unscoped tokens; teams whose AI coding agents execute pnpm install autonomously face elevated exposure until registry-scoped credentials are in place across all execution environments.
The Governance Audit
For development organizations, two credential surfaces warrant examination: developer workstations and CI service accounts. The relevant question for each is whether the npm credential present in the environment is unscoped—bound to all registries by default—or registry-specific. pnpm's documentation supports registry-scoped authentication configuration; migrating from unscoped to registry-specific tokens requires no changes to pnpm itself and represents a credential hygiene adjustment in how developers and CI environments configure npm authentication. WebPulse cannot detect which package manager was used to build the sites in its detected-frameworks corpus—build tools such as pnpm leave no deployable signature in HTML or HTTP headers, making them invisible to deployment scanning. The pnpm adoption and download figures cited in this article derive from npm Registry download counts, not WebPulse scan data. The advisory is GHSA-cjhr-43r9-cfmw; affected organizations should audit .npmrc files in cloned repositories for unauthorized registry directives and implement registry-scoped credential practices across both developer workstations and CI service accounts.
