CVE-2026-94185: nvm Alias Path Traversal, Update Now

The Node Version Manager project patched a path traversal in its alias resolution code this week. Anyone running nvm before 0.40.8 should update. That part is simple. What’s less simple, and worth sitting with for a moment, is what this particular finding says about how developer tooling gets treated in the security ecosystem.

CVE-2026-94185 lives in nvm_alias(), the function that resolves a version alias by reading a file under $NVM_DIR/alias. Before 0.40.8, the function concatenated an unvalidated alias name directly onto that directory path. Feed it a crafted string and nvm reads from outside $NVM_DIR. The maintainers rate this CVSS 5.5 (medium), consistent with a local or narrow-network attack vector rather than a remotely triggerable service flaw.

What the score doesn’t tell you

A 5.5 on a command-line version manager sounds like scheduled-maintenance territory. But nvm is installed on tens of millions of developer workstations, and the same binary runs inside CI/CD pipelines, Docker image builds, and automated test runners. In any of those contexts, the alias string may not come directly from a developer’s keyboard.

A pipeline that resolves an nvm alias from an environment variable seeded by a pull request title, a config file pulled from a third-party repo, or a matrix variable in a workflow file is a different threat model than a developer typing nvm use lts/hydrogen at their own terminal. The CVSS score captures one of those scenarios pretty well. It doesn’t capture the other one at all.

The gatekeeper you forgot you had

Here’s the thing about nvm’s function in a typical build: it’s not just a convenience tool. It’s the gatekeeper for which Node.js binary your code runs against. Which runtime version processes your build scripts. Which interpreter executes whatever’s in your package.json prepare hook. That’s a position of real authority in the dependency chain, and it’s occupied by a shell script that most CI configurations install with a single curl invocation and then never audit again.

The problem with treating developer tooling as a lower tier is that the tooling is running in the same environment as everything else. An nvm install that resolves alias names from untrusted input doesn’t fail quietly into a safe default. It fails into someone else’s file reads, in a pipeline with access to build credentials, deployment keys, and environment variables that wouldn’t be in scope for the same CVE on a developer’s personal laptop.

This is the same mistake at different scales, in different decades. The system trusts the tool. The tool trusts the input. Nobody checks whether the input is trustworthy. It’s not a new insight; it shows up in roughly a third of the meaningful supply-chain findings of the past five years. What’s curious here is that nvm has been in this position for a long time, and this is the kind of thing that gets found when someone decides to actually look.

Fix and action

Update nvm to 0.40.8. The fix validates alias names before path concatenation. The full advisory is at GHSA-8grh-q73j-ffrc; patched releases are at the nvm releases page.

For teams running nvm in CI: audit how alias names reach the tool, especially in pipelines that accept external pull requests or read config from third-party sources. No workaround is available short of the update. The advisory recommends updating as the sole mitigation.

The patch is there. The question now is how many pipelines will see this rated 5.5, file it under “get to it eventually,” and ship another six months of builds against an unpatched install.

See also: Icinga 2 Patches CVSS 9.8 Auth Bypass and Stack Overflow and ScreenConnect Worm Attacks: CVE-2026-84869 Now Patched.