version 0.40.8 fixes a path traversal vulnerability that could lead to file disclosure from a developer's computer. The issue is documented as CVE-2026-94185 and affects versions prior to 0.40.8.
The vulnerability is in the way the Node Version Manager, known as nvm, handles versions and aliases stored in the $NVM_DIR/alias. According to the CVE entry, the function did not check whether the final path remained within the intended directory.
See also: GitLab: Critical path traversal vulnerability requires immediate update
nvm version 0.40.8: How the vulnerability works
Before nvm 0.40.8, the nvm_alias() concatenated the name of a version or alias with the directory path, without sufficient constraint checking. A name containing the .. could thus be moved out and point to a file located elsewhere on the system.
In the default installation, a specially crafted value such as ../../.npmrc can point to a file in the home directory. nvm then displays non-empty lines of the file in an error message or in the command output. This behavior creates a risk of revealing sensitive information, but does not allow data modification or code execution.
The most realistic way to exploit this is to use a repository with a malicious .nvmrc. When a developer runs nvm use, nvm install , or nvm which inside this folder, the untrusted value can be passed to the alias resolution process. The same issue can be triggered when automatic version switching on entering a new directory is configured.
The issue does not require an internet connection and does not depend on any nvm service. This means that a security check on incoming connections is not enough to address it. Protection must start from the development chain: checking the code before local commands, limiting automated mechanisms, and upgrading the version management tool.
Project managers distributing .nvmrc to collaborators or public repositories should review their approval processes. A file that appears to simply request a different Node.js version can affect the local behavior of nvm. This is especially important for developers with access to code repositories, package registries, or continuous integration services.
Rating and limits of the attack
The security bulletin on GitHub classifies the issue as moderate severity. The CVSS 3.1 score is 5.5, while the corresponding CVSS 4.0 score is 6.7. The attack vector is local, requires user interaction, and primarily impacts confidentiality.
The attacker does not need an account on the machine, but must trick the user into running an affected command or provide them with a repository containing the appropriate .nvmrc . Reading is limited to files that the user has access to. Typical targets include configuration files, service credentials, access tokens, .env files , and npm configurations.
The listing clarifies that this route does not cause file corruption, denial of service, or remote code execution. However, leaking a token or configuration file could lead to a separate attack, especially in environments where the same computer is used for development and infrastructure access.
See also: Malicious .git configurations can make AI agents execute code
What users should do
nvm version 0.40.8, as reported on the project release page, now rejects .. in alias resolution paths. Users should upgrade to version 0.40.8 or later immediately, especially if they use automatic version switching when entering project folders.
Until the nvm version upgrade is complete, it is best to avoid running nvm commands on repositories of unknown origin. Development teams can also check .nvmrc before use and consider whether credentials or other sensitive files have been recently exposed.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
On workstations used for production projects, teams can list the installed version with the usual nvm commands and confirm that no older version remains in the environment. At the same time, a check of the logs and recent changes helps identify unusual usage.
See also: PoC Exploit for Lenovo code execution vulnerability
The release of nvm 0.40.8 coincides with the publication of the vulnerability and is the official patched version reported by the project. The SecNews technical team recommends that developers treat any untrusted .nvmrc as a potentially dangerous setting and complete the update before continuing their work.
