CVE-2026-121747 in nvm
Summary
by MITRE • 11/05/2026
Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.2.0 through 0.40.8, nvm does not check whether `.nvmrc` is a symbolic link. A repository or archive that ships `.nvmrc` as a symlink to another file (for example `../../.npmrc`, or `/proc/self/environ` on Linux) makes a plain `nvm use`, `nvm install`, `nvm which`, `nvm exec`, `nvm run`, or `nvm-exec` read that file and print its contents in the invalid-`.nvmrc` message (even with `--silent`) or, for a one-line file, in the `Found ... with version <...>` message; with the README's zsh `load-nvmrc` or bash `cdnvm` hook installed, entering the directory is enough. nvm sends the content nowhere; the attacker learns it only where they can see the victim's output, such as a CI log for a contributed branch. Version 0.41.0 still follows a symlinked `.nvmrc`, so deliberate links to another version file keep working, but never prints its content, and accepts it only if it contains a version or the name of an existing alias; the README's bash `cdnvm` hook, which read `.nvmrc` itself, now gets the version from nvm, so users of that hook must also update their copy of it.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability in Node Version Manager (nvm) versions 0.2.0 through 0.41.0 stems from a failure to validate whether the .nvmrc configuration file is a symbolic link rather than a regular text file. This oversight allows an attacker who controls or influences the contents of a directory accessed by a victim developer to manipulate the behavior of nvm commands such as use, install, which, exec, and run. By placing a symlinked .nvmrc that points to sensitive files like /proc/self/environ on Linux systems or other configuration files containing secrets, an attacker can cause these commands to inadvertently read and expose the contents of those target files through error messages or status outputs generated by nvm itself.
The operational impact is primarily information disclosure within environments where command output is visible to third parties, such as continuous integration logs, shared development repositories, or collaborative pull request workflows. When a victim executes an nvm command in a directory containing the malicious symlinked .nvmrc file, the tool attempts to parse the linked target's content as if it were a valid Node.js version specification. Since this content does not match expected version formats, nvm generates diagnostic messages that include the raw contents of the targeted file. In scenarios where hooks like zsh load-nvmrc or bash cdnvm are installed and triggered upon directory entry, even simple navigation into the affected directory can trigger the disclosure without explicit command execution by the victim.
This flaw aligns with CWE-200: Information Exposure through Error Messages, as sensitive data is revealed via standard output streams intended for debugging or status reporting rather than being securely handled or ignored. The attack vector leverages social engineering and repository manipulation tactics consistent with ATT&CK technique T1537: Transfer Data to Cloud Account, although in this specific context the exfiltration occurs through local log visibility rather than direct network transfer. Attackers typically exploit this by submitting code changes that include a malicious .nvmrc symlink within pull requests or shared branches, relying on maintainers or CI systems running nvm commands during review processes to leak internal environment variables, API keys, or other credentials stored in the linked files.
Mitigation strategies require immediate updates to version 0.41.0 or later of Node Version Manager, which resolves this issue by strictly validating that .nvmrc is a regular file and not a symbolic link before attempting to read its contents. For users employing custom shell hooks such as cdnvm from the official README, it is critical to update these scripts concurrently with nvm itself because older hook versions may continue reading .nvmrc directly rather than relying on version information provided by the updated core tooling. Additionally developers should audit their repositories for any existing symbolic links named .nvmrc and replace them with standard text files containing valid Node.js version specifications to prevent accidental exposure in collaborative environments where output logs are accessible to contributors or automated systems.