@pnpm/npm-conf@3.0.2 security report

Uses require.resolve('npm', {paths: paths.slice(-1)}) with computed paths to locate the built-in npm module and derive its npmrc location. This is a computed module resolution but is constrained to npm's own package and is not driven by untrusted external input.

The module loads npm configuration from multiple locations including project .npmrc, workspace .npmrc, user config (~/.npmrc), global config, and a built-in npmrc derived from the resolved npm package path. These files frequently contain authentication tokens and registry credentials. While this mirrors standard npm CLI config loading behavior, it means the package reads potentially sensitive credential-bearing configuration files at import time.

Calls conf.addEnv() which reads environment variables into the configuration object. Environment variables can contain npm auth tokens (e.g. NPM_TOKEN) and other secrets. This is expected behavior for a config loader but represents secret ingestion.

Resolves and reads configuration files at absolute paths derived from the user's home directory (userconfig), global prefix/etc (globalconfig), and project/workspace directories, reaching well outside the package's own directory tree.

Methods like addFile, loadCAFile, loadUser, and loadPrefix read files from the local filesystem (e.g., .npmrc files, CA files, prefix directory) and access process.cwd(). This is typical for a configuration loader but could be used to read sensitive files if paths are controlled by an attacker.

The addEnv method reads all environment variables matching /^npm_config_/i and processes them. While this is standard for npm/pnpm config loading, it could capture sensitive values like tokens if they are passed via environment variables with npm_config_ prefix.

The loadUser method reads process.env.SUDO_UID to determine the user. While not directly harvesting credentials, it relies on environment variables that could be manipulated.

The code reads process.env.HOME, process.env.EDITOR, process.env.VISUAL, process.env.COMSPEC, process.env.SHELL, process.env.PREFIX, process.env.DESTDIR, process.env.APPDATA, process.env.NO_COLOR, process.env.SUDO_GID, process.env.TRAVIS, and process.env.CI. It also computes paths to user configuration files such as ~/.npmrc and ~/.npm-init.js. While these are standard npm configuration lookups, the pattern of harvesting environment and user-specific config paths is a common precursor to credential theft if the values are exfiltrated elsewhere. In this isolated file there is no exfiltration, but the behavior warrants a warning.

The module determines and stores paths to global npm configuration (globalconfig), user npm configuration (userconfig), npm cache directory, home directory, and prefix directory. It also mutates process.env.HOME if os.homedir() returns a value. These operations read and potentially influence the filesystem environment outside the package's own scope, which could be abused by a malicious actor to redirect configuration or cache locations.

The generated template (defaultsTemplate) references process.env, os.tmpdir, home directory, and npm cache paths. This is normal npm config default code and is not executed during this script's execution—it is only embedded as a string into generated output.

The script reads npm's config defaults file from node_modules and transforms it via babylon/babel. This is expected behavior for a code generation tool and does not exfiltrate or execute external input.

The script writes generated files (defaults.js and types.js) into its own __dirname. It reads from a resolved dependency path (npm/lib/config/defaults) and writes only within the package directory. This is a code generation/build-time script and not malicious in nature.