node-gyp@12.4.0 security report

Uses os.homedir() to resolve '~' in --devdir and to compute cache paths via env-paths. This is normal behavior for a build tool but does access the user's home directory.

process.chdir(dir) is called based on user-provided -C/--directory flag. This changes the CWD for the process which can affect subsequent file operations, but is a documented CLI behavior and validated as a directory first.

prog.commands[command.name] dynamically selects and invokes a command handler based on user-supplied argument (command.name from program args). If command.name is attacker-influenced and 'commands' contains unexpected keys, this could be leveraged for unexpected invocation - though in this context it's the intended CLI dispatch mechanism, not obfuscation.

The errorMessage() function reads and logs npm_package_name and npm_package_version environment variables. While limited to npm package metadata and only on error paths, this is a minor information disclosure pattern that could be expanded in other code paths, and it demonstrates environment variable access behavior.

The build function spawns make or msbuild with argv that may include user-supplied options (gyp.opts.make, gyp.opts.jobs, gyp.opts.solution). While this is typical for a build tool, it allows arbitrary command execution if an attacker can influence these options, e.g., through package.json or environment variables. This is expected behavior for node-gyp but should be noted as a risk in a third-party package context.

The code modifies process.env.PYTHONPATH and process.env.PYTHON, which could affect subsequent subprocesses. This is part of normal node-gyp operation but is a side effect that could potentially be abused in a compromised environment.

The code reads files from the node prefix directory (node_version.h) and resolves paths based on user-provided --nodedir, expanding ~ to the home directory. This is expected for node-gyp but allows reading files outside the package scope if a malicious --nodedir is provided.

The code constructs paths using user-controlled input (gyp.opts.nodedir, argv) and resolves them. While not directly malicious, it could be used to access unintended locations if an attacker controls the build arguments.

The code uses JSON.parse on strings read from files and process.config. This is not eval or Function constructor, so it is safe, but it does parse potentially attacker-controlled config.gypi files. However, JSON.parse itself is not dangerous unless combined with eval. The parsed config is then written to a file in the build directory, which is expected behavior for node-gyp.

The code reads from a path derived from nodeDir and writes to buildDir. Both are expected parameters for node-gyp. No traversal outside intended directories is evident, but nodeDir could be user-controlled via --nodedir flag, potentially allowing reading arbitrary config.gypi files. This is by design for node-gyp to support custom Node.js headers.

The code accesses process.config and process.arch, but does not read environment variables or credential files like .npmrc, .ssh, etc. The gyp.opts object may contain user-provided command-line options, but these are not exfiltrated.

The module downloads content from a user-supplied URL using undici fetch. Proxy and CA settings are taken from gyp options or environment variables, which is normal for node-gyp-style tooling. No data is sent to unexpected external servers; requests target the provided URL.

Reads http_proxy, HTTP_PROXY, https_proxy, HTTPS_PROXY to configure proxy support. This is expected behavior for a downloader and does not harvest credentials or secrets.

readCAFile reads a CA certificate file from a path provided via gyp.opts.cafile. This is explicit user configuration, not harvesting of sensitive files like ~/.ssh or cloud credentials.

The code reads numerous environment variables (USERNAME, USER, LOCALAPPDATA, SystemDrive, ProgramW6432, ProgramFiles, ProgramFiles(x86), NODE_GYP_FORCE_PYTHON, PYTHON) to construct paths and locate Python executables. While this is expected behavior for a Python finder, it could be abused to gather system/user information if the package were malicious.

The code constructs absolute file paths to Python executables across Program Files and LocalAppData directories and attempts to execute them. If an attacker can place a malicious python.exe in one of these locations, it could lead to arbitrary code execution.

Reads numerous environment variables including VCINSTALLDIR, VSCMD_VER, WindowsSDKVersion, and SystemRoot. These are used for VS detection logic, not exfiltration, but the pattern of environment variable access is present.

Uses execFile to spawn powershell.exe with -NoProfile and various commands including Get-VSSetupInstance and Add-Type for loading a local C# file. This is standard node-gyp functionality for locating Visual Studio, but represents a shell/process execution surface.

Downloads Node.js development tarballs and Windows node.lib files from release.tarballUrl and related URLs, but verifies content against SHASUMS256.txt checksums. This is expected functionality for node-gyp's install command.

Creates and manages directories under gyp.devDir (typically ~/.node-gyp) and os.tmpdir(). Files are extracted from tarballs, with only .h and .gypi files filtered in. This is standard node-gyp behavior for installing dev headers.

Uses fs.rm with recursive:true on a temp directory created via mkdtemp, which is properly scoped and cleaned up in a finally block. Not a concern.

The code reads environment variables matching npm_config_* and npm_package_config_node_gyp_* and injects them into options. This is legitimate for node-gyp but could expose secrets if present in environment. However, it only reads and uses them locally, not exfiltrating.

The spawn method uses childProcess.spawn to execute arbitrary commands. This is expected for node-gyp's build functionality, but could be abused if command/args are attacker-controlled. The code is part of a build tool, so this is intentional behavior.

The constructor dynamically requires command modules based on a fixed list ('./' + command). The commands are from a hardcoded array, so no user input is used for module paths. This is safe.

The execFile function wraps child_process.execFile, which spawns external processes. While this is a legitimate utility used to run reg.exe for Windows registry queries, spawning processes is a red flag that warrants scrutiny.

regGetValue reads process.env.SystemRoot to construct the path to reg.exe. This is a standard use for locating the Windows directory and is not credential harvesting, but environment variable access is noted.

findAccessibleSync uses openSync to read files resolved from caller-provided candidates. This is a general-purpose file readability helper and does not target sensitive paths itself, but could be misused by callers.