CVE-2026-121751 in nvm
Summary
by MITRE • 11/04/2026
Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.39.6 through 0.40.8, `nvm ls-remote` (and other commands that refresh remote LTS aliases) store the version column of the mirror's `index.tab` in `$NVM_DIR/alias/lts/` without validating it, and `nvm_normalize_lts` later evaluates any suffix of an `lts/-N` value inside shell arithmetic `$((N+1))`. Under bash and zsh, arithmetic evaluation expands command substitutions in array subscripts, so a stored value such as `lts/-10*path[$(cmd)1]` runs `cmd` as the user when the alias is later resolved by purely local commands (`nvm ls`, `nvm alias`, `nvm use --lts`, `nvm which lts/`), and in every new shell when the `default` alias is `lts/*`. Exploitation requires the victim to use a hostile mirror -- via a compromised mirror or CDN, a network man-in-the-middle of an `http://` mirror, or a maliciously configured `NVM_NODEJS_ORG_MIRROR` -- and to run an affected command. The same sink is also reachable from a project `.nvmrc`, which is treated as hardening. dash is not affected. Version 0.41.0 only passes an all-digit `lts/-N` offset to arithmetic and drops `index.tab` rows whose version is not a valid version string.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
Node Version Manager, commonly referred to as nvm, serves as a critical utility for developers managing multiple Node.js versions across different projects and environments. It operates as a POSIX-compliant shell function that allows users to install, switch between, and manage various releases of the JavaScript runtime. While primarily designed for version management, its interaction with remote repositories introduces significant security considerations when handling external data sources. The vulnerability identified in nvm versions 0.39.6 through 0.40.8 stems from a failure to properly validate input derived from remote mirrors before processing it within shell arithmetic contexts. This flaw represents a classic instance of insecure deserialization or command injection via environment manipulation, where trusted local commands inadvertently execute code based on untrusted external data.
The technical root cause lies in the behavior of specific nvm commands such as `nvm ls-remote`, which refreshes remote Long-Term Support (LTS) aliases by fetching and parsing an index file from a Node.js mirror. In affected versions, the tool stores the version column from this remote `index.tab` directly into local alias files under `$NVM_DIR/alias/lts/` without rigorous validation of its format or content. Subsequently, when these aliases are resolved through functions like `nvm_normalize_lts`, any suffix within an LTS value is evaluated using shell arithmetic expansion syntax, specifically the construct `$((expression))`. In shells such as Bash and Zsh, this arithmetic evaluation context has a dangerous side effect: it expands command substitutions found within array subscripts. This means that if a malicious actor controls the content of the remote index file, they can inject arbitrary strings into the version field that include shell metacharacters for command execution.
Exploitation of this vulnerability requires specific conditions to be met by an attacker and a victim. The primary vector involves the use of a hostile mirror, which could result from a compromised Node.js official mirror or CDN, a successful network man-in-the-middle attack against unencrypted HTTP connections to such mirrors, or the configuration of the `NVM_NODEJS_ORG_MIRROR` environment variable by an attacker with local access. When a victim runs commands that trigger the refresh and resolution of these aliases, such as `nvm ls`, `nvm alias`, `nvm use --lts`, or `nvm which lts/`, the shell interprets the injected payload within the arithmetic context. For example, an attacker could craft a version string like `lts/-10*path[$(malicious_cmd)1]`. When this value is processed by nvm and subsequently resolved in a new shell session or when the default alias points to LTS, the embedded command substitution executes with the privileges of the current user. This results in arbitrary code execution on the victim's machine without any additional interaction beyond running standard version management commands.
The impact of this vulnerability extends beyond immediate remote exploitation scenarios due to how nvm handles project-specific configurations. The same injection sink is reachable through a `.nvmrc` file located within a developer’s project directory. If an attacker can influence or replace the contents of such a file, they can trigger code execution when another user opens that project in their shell environment. This transforms what might be considered a local configuration issue into a broader attack surface, particularly in shared development environments or CI/CD pipelines where `.nvmrc` files are frequently checked out and processed automatically. The vulnerability affects Bash and Zsh shells significantly due to their handling of arithmetic expansion, while Dash is noted as not being affected by this specific mechanism because it does not expand command substitutions within array subscripts during arithmetic evaluation in the same manner.
To mitigate this risk, users must upgrade nvm to version 0.41.0 or later immediately upon availability. The fix implemented in version 0.41.0 addresses the core issue by strictly validating input before it reaches the arithmetic evaluator. Specifically, the updated code ensures that only all-digit offsets for `lts/-N` values are passed to the shell arithmetic context, effectively neutralizing command injection attempts embedded within non-numeric suffixes. Additionally, the patch drops any rows from the remote `index.tab` file where the version string is not valid according to strict parsing rules, preventing malformed or malicious entries from being stored in local alias files. For organizations relying on nvm, it is also advisable to enforce HTTPS connections for all mirror requests and validate the integrity of downloaded index files using cryptographic checksums provided by Node.js releases.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), as well as CWE-20 Improper Input Validation regarding the failure to sanitize data from external sources before processing. In terms of adversary tactics, it maps to ATT&CK technique T1059 Command and Scripting Interpreter, specifically sub-techniques involving shell commands like sh or bash. The attack vector leverages legitimate administrative tools for malicious purposes, highlighting the importance of defense-in-depth strategies that include input validation at every layer of data processing. Security teams should audit their nvm configurations to ensure no custom mirrors are being used without proper verification and consider implementing strict allow-listing policies for version strings in automated environments to prevent similar injection vectors from succeeding even if other vulnerabilities exist within shell interpreters themselves.