npm@11.19.0 security report

The script references npm configuration definitions via @npmcli/config but does not read, harvest, or transmit any environment variables, .npmrc files, or credentials to external servers.

Uses require() to load local relative paths ('../lib/cli.js', './npm-cli.js') and a fixed package path ('@npmcli/config/lib/definitions'). These are static, hardcoded paths with no computed or external input, so there is no dynamic import risk.

The script modifies process.argv to route npx arguments to npm exec. This is legitimate argument preprocessing, not malicious. It only manipulates the argument array in memory and does not execute external commands, read credentials, or exfiltrate data.

In replaceDefinitions, getCommand(name, commandLoader) is called with name derived from the doc file path (basename stripped of npm- prefix and .md extension). If doc file names were attacker-controlled, this could allow requiring arbitrary modules under lib/commands, potentially executing arbitrary code on import.

Top-level code runs immediately on import: enableCompileCache() is invoked and validateEngines/require chains are wired up. This is normal CLI bootstrap behavior but means the package executes logic at import time, so the full transitive code path (validate-engines.js and cli/entry.js) must be reviewed for malicious behavior since this file alone cannot be judged safe.

The module resolves and requires an entry point (cli/entry.js) using a path computed at runtime via __dirname. While the path is deterministic and package-local, this pattern dynamically loads a module rather than a static import, which can obscure what code actually executes. In this file the target is fixed, so the risk is limited, but the pattern warrants verification that cli/entry.js and validate-engines.js contain no malicious payloads.

The edit subcommand spawns the user-configured editor process (this.npm.flatOptions.editor) on the npmrc file. This is intentional functionality for npm config edit, uses explicit user-provided config, and does not execute untrusted input or perform hidden actions.

Uses pacote/npmFetch to query the configured npm registry for the latest npm package manifest and to ping the registry. This is expected behavior for an npm CLI health-check tool.

Makes an HTTPS GET request to 'https://nodejs.org/dist/index.json' to fetch Node.js release information. This is a legitimate, expected behavior for an npm doctor command and does not involve sending any local data outbound.

Recursively traverses npm cache, local/global node_modules, and local/global bin directories to verify permissions. This is scoped to npm-related directories and is the documented purpose of the doctor command.

Uses the 'which' module to locate the 'git' executable in PATH. This does not spawn a shell or execute arbitrary commands; it only resolves the binary path.

cacache.verify is invoked on the npm cache, which may garbage-collect corrupted content. This is a standard npm cache maintenance operation and is confined to the npm cache directory.

Custom resolution of localBin and pkgPath for workspaces using resolve(runPath, 'node_modules', '.bin') and workspace paths. No external data exfiltration, but it manipulates filesystem paths outside the immediate module scope based on workspace configuration.

The command explicitly sets packageLockOnly: false so that missing packages are actually installed when exec'd, which may trigger install scripts (lifecycle scripts). It also resolves allow-scripts policy from user/global config, deliberately skipping project-level config. This is behavior consistent with npm exec but represents code that can trigger arbitrary package install scripts.

The code attempts to prevent path traversal using join('/', pkgname) and checking relative(path, this.npm.dir) === ''. However, the check may be insufficient if pkgname contains multiple path segments or encoded characters. This is a security-relevant pattern but appears to be a mitigation rather than a vulnerability.

The catch handler sets process.exitCode based on error codes from executed commands. This is normal error handling but interacts with arbitrary command execution.

The code uses require('@npmcli/arborist') inside the exec method. This is a legitimate npm library used for managing package trees, not a malicious dynamic import.

The code uses pacote.manifest to fetch package metadata. This is standard behavior for npm commands that need to retrieve package information from registries.

The openUrl function opens funding URLs in the user's browser. This is expected behavior for the npm fund command, which retrieves and displays funding information for packages. The URLs come from package funding metadata, not from attacker-controlled external servers.

User-supplied arguments are used to build a glob pattern (via deref(args[0]) and string interpolation) that scans the filesystem under npm.npmRoot. While rooted/normalized through path.resolve, it uses attacker-influenced text in glob patterns.

This file is part of the npm CLI's org command implementation. It uses libnpmorg (an official npm library) to manage npm organizations. All operations (set, rm, ls) are expected org management commands that require authentication via the otplease wrapper. No malicious patterns such as data exfiltration, credential harvesting, obfuscation, crypto mining, backdoors, or process spawning were detected.

The code makes HTTP requests to the npm registry for legitimate purposes: fetching package metadata (pacote.packument) and user info (npmFetch.json on /-/user/org.couchdb.user:...). These are expected for the 'npm owner' command and use the user's configured registry, not hardcoded external servers.

The changeOwners method sends a PUT request to update package maintainers. This is the intended functionality of 'npm owner add/rm' and is properly authenticated via otplease. No malicious data injection or exfiltration.

Authentication tokens are handled through npm's standard flatOptions and otplease utilities. No direct credential reading from files (.npmrc, etc.) or environment variables is performed in this file.

Dynamically requires @npmcli/arborist. This is a standard dependency for npm's arborist functionality and is expected within npm's own codebase.

Uses unlink to remove the old package-lock.json after renaming to npm-shrinkwrap.json. This is expected behavior for the npm shrinkwrap command and operates within the package directory.

The static cmd() method loads command modules via require(./commands/${command}) where command comes from deref(c). This is standard npm CLI architecture for dispatching to built-in commands (which are validated by deref against a known command list), not external input. It allows arbitrary command name strings to be passed, but this is an established, intended pattern in npm itself.

Uses which(process.argv[0]) to resolve the node binary, and updates process.execPath/config.execPath to the resolved path. This is a normal npm startup routine to ensure correct node symlink resolution; it does not spawn shell commands or pass untrusted input to a shell.

Sets process.title using only positional args and applies redactLog (replaceInfo) to cooked argv before logging. The comment explains this is done to prevent secrets from leaking into the process title/command line. This is a defensive, security-conscious behavior, not a harvesting pattern.

Writes error report files to ${this.logPath}${file} (defaults to logs-dir under cache) and creates cache/logs directories via fs.mkdir with recursive:true. These are standard npm runtime paths (cache dir, logs dir) controlled by user config, not suspicious external locations.

The code uses require('hosted-git-info') inside the hostedFromMani method, which is a dynamic require based on a hardcoded string. This is not a red flag, but rather a common pattern in Node.js packages to lazy-load dependencies. The module loaded is a well-known, trusted package for parsing hosted git URLs.

The code uses openUrl to open URLs derived from package manifests. This is a legitimate feature for npm CLI commands like 'npm bugs' or 'npm docs'. The URL is constructed from package metadata and passed to a utility that opens the user's browser. While this could theoretically be abused if a malicious package manifest contains a crafted URL, the manifest is fetched via pacote from the configured registry, and the user explicitly invokes the command, so the risk is low.

Calls stream._handle.setBlocking(true) on stdout/stderr TTY handles. This is a documented workaround copied from the yargs/set-blocking package, not a vulnerability.

Constructor registers process-level event listeners ('log', 'output', 'input') and sets up a Progress spinner immediately upon instantiation. This is standard npm CLI display logic, but it does mean module-level/side-effect behavior occurs on import/instantiation. No data is sent externally or executed unsafely.

Uses dynamic import() for 'chalk' and 'supports-color' inside the async load() method. These are static, hardcoded module names from trusted dependencies, not computed or external input.

The code explicitly sets redact: false for 'notice' level logs and for JSON output buffering after per-item redaction. This is intentional per comments (2FA links, already-redacted items), but could theoretically weaken redaction if misused. Not malicious.

The code reads process.env.NPM_ID_TOKEN, process.env.ACTIONS_ID_TOKEN_REQUEST_URL, process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN, and process.env.SIGSTORE_ID_TOKEN. While these are OIDC-related tokens intended for authentication, the code collects and uses them to authenticate with the npm registry and enables token exchange. This is consistent with its stated purpose but constitutes credential handling that should be scrutinized.

The retrieved npm token is stored in opts[authTokenKey] and config.set(authTokenKey, response.token, 'user'), effectively injecting a live auth token into the npm configuration for the session. This is expected behavior for OIDC publishing but could be abused if the token exchange endpoint or registry is malicious.

new URL(/-/npm/v1/oidc/token/exchange/package/${escapedPackageName}, registry) concatenates package name into a URL path. While npa(...).escapedName is used, this pattern can lead to SSRF if registry or packageName are attacker-controlled, though typically they are user-specified.

The code decodes the OIDC idToken payload (base64) and parses JSON without verifying the signature. This is only used to decide whether to enable provenance based on visibility claims — not for security-critical authorization — but relying on unverified claims could be a logic flaw.

Writes an npmrc file into the installed npm package directory during global installs. This is intentional npm behavior to preserve builtin config, not a malicious pattern, and is scoped to the installed npm package path.