Node.js

Node.js Security Progress Report – Security Release and Node.js 21


October was busy due to the latest security release affecting Node.js 18 and Node.js 20. Usually, we lock in the Continuous Integration (CI) cycle at least 5 days before a release. This time, however, due to the recent changes to the CITGM (Canary In The Gold Mine: a simple tool for pulling down an arbitrary module from npm and testing it using a specific version of the node runtime) and changes to the automation of the security release proposal, it was just 3 days.

Thank you to the continued support from the Alpha-Omega project at the OpenSSF Project, helping us make Node.js more secure and easier to build! 

October was busy due to the latest security release affecting Node.js 18 and Node.js 20. Usually, we lock in the Continuous Integration (CI) cycle at least 5 days before a  release. This time, however, due to the recent changes to the CITGM (Canary In The Gold Mine: a simple tool for pulling down an arbitrary module from npm and testing it using a specific version of the node runtime) and changes to the automation of the security release proposal, it was just 3 days.

Speedy!

And, a day after the security release, we put out Node.js 21. Main updates for Node.js 21:

  • V8 JavaScript engine updated to 11.8
  • Stable WebStreams which helps to process data in small sizes for applications
  • A new experimental flag to flip module defaults (–experimental-default-type) – Node.js has two module systems: CommonJS modules and ECMAScript modules. Node.js treats files with a .js extension by default as CommonJS modules. This can now more easily be flipped.
  • Many updates to test runner which allows users to run functional tests and export results

If you’d like to find out more about Node.js 21:

This means a transition from Node.js 20 to LTS. Node.js 21 is now our Current release.

Security Release

In October, Node.js addressed 4 CVEs within Node.js and 2 within its dependencies:

  • 2 High severity issues
  • 1 Medium severity issue
  • 1 Low severity issue in Node.js
  • Security updates for undici and nghttp2

The 20.x release line of Node.js was vulnerable to 2 high severity issues, 1 medium severity issue, and 1 low severity issue. The 18.x release line was vulnerable to 1 medium severity issue, and 1 low severity issue.

Users can always check their version’s vulnerability status by running:

$ npx is-my-node-vulnerable

Security initiatives and assessments

Recently, OpenSSL disclosed 3 security releases which were assessed by the Node.js team as non-critical patches. They were handled in regular releases.

Additionally, two pull requests were created to update Permission Model stability. The Permission Model has been moved to version 1.1 and Active Development. We’ve documented that some files can be read before V8 initialization, which implies before permission model initialization, too.

With the intention of improving the scorecard for different repositories under Node.js, we created 5 pull requests to pin Github Actions by commit-hash. We are evaluating how effective this approach is for non-libraries since it can cause some maintenance burdens for the maintainers. 

You can pin Github Actions by tag without having to manually (or through dependabot) update semver-minor and semver-patch releases. actions/checkout@v2 will always fetch the latest release of v2.

In October, we’ve added support to Ada and simdtuf to our dependency-vulnerability-scanner. And Node.js 21 was added to the cycle.

As a final update, we’ve identified that a previous security release might have broken the usage of the esm npm package. However, considering this package is now archived and the usage of monkey patching is not guaranteed by Node.js, it is unlikely a patch will be produced.

Interested in getting involved with Node.js security? We are actively looking for new contributors! Find out more about the Node.js Security Team here: https://github.com/nodejs/security-wg