Security Concerns with Using Older Node.js Versions via NVM

[Jubelnar]

Hi,

I've got some security-related questions regarding the use of NVM. In my company, we use a software called Arctic Wolf to scan for vulnerabilities on our local machines. A couple of months ago, I had an old Node.js 18.x version installed on my machine, which was flagged as a security risk. To resolve this, we updated to the latest version.

However, I now need an old Node.js 12.x version to compile an old React project. To manage multiple Node versions, I installed NVM. When I asked our administrator about using Node.js 12, he mentioned that this would also raise a red flag in Arctic Wolf. Interestingly, since installing the version through NVM, Arctic Wolf hasn't flagged it.

My question is: Should we still be concerned about vulnerabilities in the old Node.js version installed via NVM? Does NVM handle these versions in a way that mitigates these security risks, or is it just not being detected by Arctic Wolf?

Any insights or advice on this matter would be greatly appreciated!

Thanks in advance!

[coreybutler]

Great question. The answer is a little nuanced.

NVM4W uses a symlink to change the active version of node, i.e. it determines which executable is linked to "node.exe" on the PATH. It replicates the effect you'd have if you installed node without a version manager. I'm not sure how Arctic Wolf works internally, but I suspect it looks for the active version of node. If you switch to an old version while the AV runs, it would likely flag the version because the active version is vulnerable. However, if you switch back to a new version, the AV likely won't catch it because the active version of node is not vulnerable. This doesn't mean your system is safe, because node 12 still exists on it. It's just not in the active PATH. If someone were clever, they could determine the path to the Node 12 exe and run it.

NVM4W does not support .nvmrc files, which allows projects to run a pinned version of node in other version managers. Pinned versions allow anyone to run npm start, automatically using the pinned version. In cases like yours, the pinned version may be vulnerable. That means an attacker would be able to run a vulnerable version of node via npm (or possibly npx), but the AV would not detect it because the old version is not "active". In this regard, NVM4W is slightly more secure because it will not arbitrarily run a pinned version of node. Tbh, I've taken a lot of heat for not supporting .nvmrc files, but this is one of the top reasons why I've not added support.

I've worked with a lot of cybersecurity teams and observed that developer machines are often the source of the largest attack surface in organizations, primarily because they aren't updated regularly enough. NVM4W minimally mitigates by not using .nvmrc, but it doesn't do anything to disable other exe files installed on the system. Frankly, Arctic Wolf should be identifying all of the executables and determining their version/vulnerability, even if they aren't on the active path, because a savvy attacker could still exploit an old version of node if it can run an arbitrary exe.

There's not much that a simple cli version manager can do to mitigate this any further, but their are ways using more sophisticated architecture. We are actively working on this for Runtime, the successor to NVM4W (which is rapidly approaching a beta release). Vulnerability management/mitigation will be a commercial/paid feature, but at a very reasonable cost. I encourage all organizations to keep an eye open for the release announcement, seeing as Runtime is addressing these types of concerns for enterprises. Announcements about Runtime will be made on https://linkedin.com/company/authorsoftware and to anyone on the mailing list (fill out the survey on the Readme to sign up).

Let me know if I can clarify anything.

[Jubelnar]

Thank you for your detailed response. I'll keep an eye out for the release announcements.