semantic-release npm package: is it safe?

The application is designed to load and execute plugins based on the 'plugins', 'extends', and other plugin-related options parsed from the command line. These options are coerced from user input and passed to the main module. This constitutes a dynamic module loading mechanism where user-controlled input determines what code gets executed. If an attacker can control the CLI arguments or configuration, they may achieve arbitrary code execution.

The CLI dynamically imports './index.js' at runtime after parsing user-controlled options from process.argv. While the module path is static, the options parsed from CLI arguments are passed directly into the imported module. In the context of semantic-release, these options include plugin names and shareable configurations which are resolved and executed as code. An attacker who can influence the CLI arguments (e.g., via CI/CD configuration or a malicious .releaserc file) could cause arbitrary plugin code to be loaded and executed.

The extends config option allows loading arbitrary modules via importFrom.silent(__dirname, extendPath) and importFrom(cwd, extendPath), where extendPath comes directly from the configuration. This enables loading and executing code from any resolvable module path, which could be exploited if an attacker can control the config (e.g., a malicious shared config). This is a legitimate feature of semantic-release, but it represents a code execution vector.

The code reads multiple sensitive environment variables (GH_TOKEN, GITHUB_TOKEN, GL_TOKEN, GITLAB_TOKEN, BB_TOKEN, BITBUCKET_TOKEN, GIT_CREDENTIALS) to extract git authentication credentials. While this is the intended functionality for semantic-release to authenticate with git providers, it demonstrates credential harvesting behavior that could be abused if the package were compromised or if the collected credentials were sent elsewhere.

getCommits uses gitLogParser.parse with a format string constructed from user-supplied from and to values: { _: ${from ? from + '..' : ''}${to} }. These values are passed to git-log-parser, which may construct a git log command. If the parser does not safely shell-escape these values, an attacker controlling from or to (e.g., via branch/tag names in a CI context) could inject git options or shell metacharacters.

The code calls loadPlugin(context, name, pluginsPath) where 'name' and 'pluginsPath' are derived from plugin configuration. This function likely dynamically imports or requires modules based on user-supplied or configuration-supplied names, which could be abused to load arbitrary code if the plugin name is not properly validated. While this is typical for a plugin system (semantic-release), it represents a dynamic import risk.

The plugin function (or method) retrieved from the loaded module is invoked with configuration and context data. This is expected behavior for a plugin framework but means arbitrary code from third-party plugins will execute. If a malicious plugin is installed, it would run with access to environment, file system, and network.

The code loads external plugins from the filesystem based on names provided in configuration. While this is expected behavior for a plugin system, it represents a code execution vector if the configuration is not properly validated or if an attacker can influence plugin paths.

The loadPlugin function uses dynamic import() with a computed file path derived from user-controlled plugin names and configuration. This could potentially load and execute arbitrary modules if an attacker can control the plugin name or path, though resolve-from is used to resolve paths relative to known directories.