Node.js Blog: Vulnerability Reports

June 2020 Security Releases

Sam Roberts — Tue, 02 Jun 2020 12:00:00 GMT

(Update 2-June-2020) Security releases available

Updates are now available for all supported Node.js release lines for the following issues.

TLS session reuse can lead to host certificate verification bypass (High) (CVE-2020-8172)

The 'session' event could be emitted before the 'secureConnect' event. It should not be, because the connection may fail to be authorized. If it was saved an authorized connection could be established later with the session ticket. Note that the https agent caches sessions, so is vulnerable to this.

The 'session' event will now only be emitted after the 'secureConnect' event, and only for authorized connections.

Affects Node.js 12.x, and 14.x. Does not affect Node.js 10.x.

HTTP/2 Large Settings Frame DoS (Low) (CVE-2020-11080)

Receiving unreasonably large HTTP/2 SETTINGS frames can consume 100% CPU to process all the settings, blocking all other activities until complete.

The HTTP/2 session frame is limited to 32 settings by default. This can be configured if necessary using the maxSettings option.

Thank you to Jordan Zebor and Adam Cabrey of F5 Networks for reporting this.

Affects Node.js 10.x, 12.x, and 14.x.

`napi_get_value_string_*()` allows various kinds of memory corruption (High) (CVE-2020-8174)

Calling napi_get_value_string_latin1(), napi_get_value_string_utf8(), or napi_get_value_string_utf16() with a non-NULL buf, and a bufsize of 0 will cause the entire string value to be written to buf, probably overrunning the length of the buffer.

A exploit has not been reported and it may be difficult but the following is suggested:

All users of LTS Node.js versions should update to the versions announced in this security post. This will address the issue for any non pre-built add-on.
Maintainers who support EOL Node.js versions and/or build against a version of Node.js that did not support N-API internally should update to use the new versions of node-addon-api 1.x and 2.x that will be released soon after this announcement.

Affects Node.js 10.x, 12.x, and 14.x.

Affects https://www.npmjs.com/package/node-addon-api 1.x, 2.x when a native add-on is/was built using a version of Node.js that did not support N-API internally. The N-API version matrix shows which versions of Node.js in which this support was added.

`ICU-20958 Prevent SEGV_MAPERR in append` (High) (CVE-2020-10531)

An issue was discovered in International Components for Unicode (ICU) for C/C++ through 66.1. An integer overflow, leading to a heap-based buffer overflow, exists in the UnicodeString::doAppend() function in common/unistr.cpp.

Fix was applied to 10.x in an abundance of caution, even though there is no known way to trigger the overflow in 10.x.

Does not affect 12.x or 14.x, they do not include an affected version of ICU.

Downloads & release details

Summary

The Node.js project will release security updates to all supported release lines on or shortly after Tuesday, June 2nd, 2020.

The highest severity fix will be "High".

Impact

All supported versions (10.x, 12.x, and 14.x) of Node.js are vulnerable. Note that 13.x will be end-of-life on June 1st, before the security release date, and according to policy it will not receive any more updates.

Release timing

Releases will be available on or shortly after Tuesday, June 2nd, 2020.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/. Please follow the process outlined in https://github.com/nodejs/node/blob/master/SECURITY.md if you wish to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organization.

OpenSSL security releases do not require Node.js security releases

Sam Roberts — Tue, 21 Apr 2020 12:00:00 GMT

Update

The OpenSSL project has released a description of the issue fixed in the OpenSSL 1.1.1g update. It only affects a function which is not called by Node.js (or its dependencies), and as such, does not affect Node.js.

No Node.js security releases are required.

For more information, see the OpenSSL announcement.

The previous Node.js announcement can be found below.

Summary

The Node.js project may be releasing new versions across all of its supported release lines early next week to incorporate upstream patches from OpenSSL. Please read on for full details.

OpenSSL

The OpenSSL project announced this week that they will be releasing version 1.1.1g on the 21st of April. The highest severity issue that will be fixed in the release is "HIGH" severity under their security policy, meaning they are:

... issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable.

All supported versions of Node.js use OpenSSL v1.1.1, therefore all active release lines are impacted by this update: v10.x, v12.x, v13.x, and v14.x ( 14.0.0 is to be released on the 21st of April, by coincidence).

At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users.

After assessing the impact on Node.js, it will be decided whether the issues fixed require immediate security releases of Node.js, or whether they can be included in the normally scheduled updates.

Please monitor the nodejs-sec Google Group for updates, including a decision within 24 hours after the OpenSSL release regarding release timing, and full details of the defects upon eventual release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/, including information on how to report a vulnerability in Node.js.

Subscribe to the low-volume announcement-only nodejs-sec mailing list at https://groups.google.com/forum/#!forum/nodejs-sec to stay up to date on security vulnerabilities and security-related releases of Node.js and the projects maintained in the nodejs GitHub organisation.

February 2020 Security Releases

Sam Roberts — Thu, 06 Feb 2020 12:00:00 GMT

(Update 6-February-2020) Security releases available

Updates are now available for all active Node.js release lines for the following issues.

HTTP request smuggling using malformed Transfer-Encoding header (Critical) (CVE-2019-15605)

Affected Node.js versions can be exploited to perform HTTP desync attacks and deliver malicious payloads to unsuspecting users. The payloads can be crafted by an attacker to hijack user sessions, poison cookies, perform clickjacking, and a multitude of other attacks depending on the architecture of the underlying system.

Reported by Ethan Rubinson, a software engineer at eBay.

HTTP header values do not have trailing OWS trimmed (High) (CVE-2019-15606)

Optional whitespace should be trimmed from HTTP header values. Its presence may allow attackers to bypass security checks based on HTTP header values.

Reported by Alyssa Wilk from Google.

Remotely trigger an assertion on a TLS server with a malformed certificate string (High) (CVE-2019-15604)

Connecting to a NodeJS TLS server with a client certificate that has a type 19 string in its subjectAltName will crash the TLS server if it tries to read the peer certificate.

Reported by Rogier Schouten and Melvin Groenhoff.

Strict HTTP header parsing (None)

Increase the strictness of HTTP header parsing. There are no known vulnerabilities addressed, but lax HTTP parsing has historically been a source of problems. Some commonly used sites are known to generate invalid HTTP headers, a --insecure-http-parser CLI option or insecureHTTPParser http option can be used if necessary for interoperability, but is not recommended.

Downloads & release details

Summary

The Node.js project will release new versions of all supported release lines on or shortly after Tuesday, February 4th, 2020.

One Critical severity and two High severity issues will be fixed. The release also includes stricter HTTP parsing.

Impact

All supported versions (10.x, 12.x, and 13.x) of Node.js are vulnerable.

Release timing

Releases will be available at, or shortly after, Tuesday, February 4th, 2020.

Contact and future updates

December 2019 Security Releases

Michael Dawson, Sam Roberts — Wed, 18 Dec 2019 00:23:00 GMT

(Update 18-December-2019) Releases available

These releases update npm to v6.13.4 to address three vulnerabilities described below.

All current release lines were affected.

At this time, CVEs have been requested by npm, Inc. and are pending review. See https://twitter.com/ahmadnassri/status/1205132161961123841 for more information.

Global `node_modules` Binary Overwrite

Versions of the npm CLI prior to 6.13.4 are vulnerable to a Global node_modules Binary Overwrite. It fails to prevent existing globally-installed binaries to be overwritten by other package installations.

For example, if a package was installed globally and created a serve binary, any subsequent installs of packages that also create a serve binary would overwrite the first binary. This will not overwrite system binaries but only binaries put into the global node_modules directory.

This behavior is still allowed in local installations and also through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

https://www.npmjs.com/advisories/1437

Symlink reference outside of `node_modules`

Versions of the npm CLI prior to 6.13.3 are vulnerable to a symlink reference outside of node_modules. It is possible for packages to create symlinks to files outside of the node_modules folder through the bin field upon installation. A properly constructed entry in the package.json bin field would allow a package publisher to create a symlink pointing to arbitrary files on a user’s system when the package is installed. Only files accessible by the user running the npm install are affected.

This behavior is still possible through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

https://www.npmjs.com/advisories/1436

Arbitrary File Write

Versions of the npm CLI prior to 6.13.3 are vulnerable to an Arbitrary File Write. It fails to prevent access to folders outside of the intended node_modules folder through the bin field. A properly constructed entry in the package.json bin field would allow a package publisher to create files on a user's system when the package is installed. It is only possible to affect files that the user running npm install has access to and it is not possible to overwrite files that already exist on disk.

This behavior is still possible through install scripts. This vulnerability bypasses a user using the --ignore-scripts install option.

https://www.npmjs.com/advisories/1434

Downloads

Please note that this will be the final release of the v8.x line as support ends after December 31st, 2019.

Summary

The Node.js project will release new versions of all supported release lines on or shortly after Tuesday December 17, 2019 UTC. For versions 8, 10, and 12 the only update to the runtime in these releases will be an updated version of npm addressing the vulnerability announced in https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli. Version 13, while still being a security release, will include all commits that were scheduled to be included in the originally scheduled release.

In the meantime, users should update to npm 6.13.4 by following the instructions provided in the npm advisory. As a general rule, avoid running npm in production environments.

Impact

All versions of Node.js are vulnerable including the LTS and current releases: Node.js 8 (LTS "Carbon"), Node.js 10 (LTS "Dubnium") , Node.js 12 (LTS "Erbium"), and Node.js 13.

Release timing

Releases will be available at, or shortly after, Tuesday, December 17, 2019 UTC.

Contact and future updates

OpenSSL security releases do not require Node.js security releases

Sam Roberts — Thu, 12 Sep 2019 17:00:15 GMT

Summary

The OpenSSL Security releases of September 10th, 2019 do not affect Node.js.

Analysis

Our assessment of the security advisory is:

ECDSA remote timing attack (CVE-2019-1547) Not affected. Node supports only named curves for ECDSA signing.
Fork Protection (CVE-2019-1549) Not affected. Node.js always call exec() after fork() so will not duplicate the PRNG state in the forked process.
Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563) Not affected. Node does not support PCKS7 and CMS.

Given this assessment, the OpenSSL updates will be treated as non-security patch updates, and will come out in the regularly scheduled updates to supported release lines.

Acknowledgements

Thanks to Shigeki Ohtsu for his rapid analysis of the OpenSSL security advisory.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/, including information on how to report a vulnerability in Node.js.

OpenSSL security releases may require Node.js security releases

Sam Roberts — Thu, 05 Sep 2019 15:34:35 GMT

Summary

The Node.js project may be releasing new versions across all of its supported release lines early next week to incorporate upstream patches from OpenSSL. Please read on for full details.

OpenSSL

The OpenSSL project announced this week that they will be releasing versions 1.0.2t and 1.1.1d on the 10th of September, UTC. The releases will fix two security defects that are labelled as "LOW" severity under their security policy, meaning they are:

... issues such as those that only affect the openssl command line utility, or unlikely configurations.

Node.js v8.x use OpenSSL v1.0.2 and Node.js v10.x and v12.x both use OpenSSL v1.1.1, therefore all active release lines are impacted by this update.

At this stage, due to embargo, the exact nature of these defects is uncertain as well as the impact they will have on Node.js users.

After assessing the impact on Node.js, it will be decided whether the issues fixed require immediate security releases of Node.js, or whether they can be included in the normally scheduled updates.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/, including information on how to report a vulnerability in Node.js.

August 2019 Security Releases

Sam Roberts — Fri, 16 Aug 2019 14:58:40 GMT

Node.js, as well as many other implementations of HTTP/2, have been found vulnerable to Denial of Service attacks. See https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md for more information.

Updates are now available for all active Node.js release lines, including Linux ARMv6 builds for Node.js 8.x (which had been delayed).

We recommend that all Node.js users upgrade to a version listed below as soon as possible.

Downloads & release details

Downloads are available for the following versions. Details of code changes can also be found on each release page.

Node.js 8.16.1: https://nodejs.org/dist/latest-v8.x/
Node.js 10.16.3: https://nodejs.org/dist/latest-v10.x/
Node.js 12.8.1: https://nodejs.org/dist/latest-v12.x/

Vulnerabilities Fixed

Impact: All versions of Node.js 8 (LTS "Carbon"), Node.js 10 (LTS "Dubnium"), and Node.js 12 (Current) are vulnerable to the following:

CVE-2019-9511 “Data Dribble”: The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
CVE-2019-9512 “Ping Flood”: The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
CVE-2019-9513 “Resource Loop”: The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.
CVE-2019-9514 “Reset Flood”: The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
CVE-2019-9515 “Settings Flood”: The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.
CVE-2019-9516 “0-Length Headers Leak”: The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory, potentially leading to a denial of service.
CVE-2019-9517 “Internal Data Buffering”: The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.
CVE-2019-9518 “Empty Frames Flood”: The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service. (Discovered by Piotr Sikora of Google)

Contact and future updates

The current Node.js security policy and information about how to report a vulnerability can be found at https://nodejs.org/en/security/.

February 2019 Security Releases

Rod Vagg — Thu, 28 Feb 2019 12:53:26 GMT

(Update 28-February-2018) Security releases available

Summary

Updates are now available for all active Node.js release lines. In addition to fixes for security flaws in Node.js, they also include upgrades of Node.js 6 and 8 to OpenSSL 1.0.2r which contains a fix for a moderate severity security vulnerability. The original announcement is included below.

For these releases, we have decided to withhold the fix for the Misinterpretation of Input (CWE-115) flaw mentioned in the original announcement. This flaw is very low severity and we are not satisfied that we had a complete and stable fix ready for release. We will be seeking to address this flaw via alternate mechanisms in the near future. In addition, we have introduced an additional CVE for a change in Node.js 6 that we have decided to classify as a Denial of Service (CWE-400) flaw.

We recommend that all Node.js users upgrade to a version listed below as soon as possible.

Downloads & release details

Downloads are available for the following versions. Details of code changes can also be found on each release page.

Node.js: Slowloris HTTP Denial of Service with keep-alive (CVE-2019-5737)

Categorization: Uncontrolled Resource Consumption / Denial of Service (CWE-400)

All actively supported release lines are vulnerable and the severity is LOW. An attacker can cause a Denial of Service (DoS) by establishing an HTTP or HTTPS connection in keep-alive mode and by sending headers very slowly thereby keeping the connection and associated resources alive for a long period of time. Attack potential is mitigated by the use of a load balancer or other proxy layer.

This vulnerability is an extension of CVE-2018-12122, addressed in November, 2018. The 40 second timeout and its adjustment by server.headersTimeout apply to this fix as in CVE-2018-12122.

CVE-2018-12122 originally reported by Jan Maybach (liebdich.com), keep-alive variant reported by Marco Pracucci (Voxnest), fixed by Matteo Collina.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

Node.js: Denial of Service with keep-alive HTTP connections (CVE-2019-5739)

Categorization: Uncontrolled Resource Consumption / Denial of Service (CWE-400)

Keep-alive HTTP and HTTPS connections can remain open and inactive for up to 2 minutes in Node.js 6.16.0 and earlier. Node.js 8.0.0 introduced a dedicated server.keepAliveTimeout which defaults to 5 seconds. The behavior in Node.js 6.16.0 and earlier is a potential Denial of Service (DoS) attack vector. Node.js 6.17.0 introduces server.keepAliveTimeout and the 5-second default.

The original fix was submitted by Timur Shemsedinov (nodejs/node#2534) and backported by Matteo Collina.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are NOT vulnerable
All versions of Node.js 10 (LTS "Dubnium") are NOT vulnerable
All versions of Node.js 11 (Current) are NOT vulnerable

OpenSSL: 0-byte record padding oracle (CVE-2019-1559)

Severity: MODERATE

OpenSSL 1.0.2r contains a fix for CVE-2019-1559 and is included in the releases for Node.js versions 6 and 8 only. Node.js 10 and 11 are not impacted by this vulnerability as they use newer versions of OpenSSL which do not contain the flaw.

Under certain circumstances, a TLS server can be forced to respond differently to a client if a zero-byte record is received with an invalid padding compared to a zero-byte record with an invalid MAC. This can be used as the basis of a padding oracle attack to decrypt data.

Only TLS connections using certain ciphersuites executing under certain conditions are exploitable. We are currently unable to determine whether the use of OpenSSL in Node.js exposes this vulnerability. We are taking a cautionary approach and recommend the same for users. For more information, see the advisory and a detailed write-up by the reporters of the vulnerability.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are NOT vulnerable
All versions of Node.js 11 (Current) are NOT vulnerable

Acknowledgements

Matteo Collina for vulnerability fixes.

Shigeki Ohtsu and Sam Roberts for the OpenSSL upgrade.

Jan Maybach and Marco Pracucci for reporting vulnerabilities via the appropriate channels (see below).

Other members of the Node.js security team for reviews and discussion.

Original post is included below

Summary

The Node.js project will release new versions of all supported release lines on, or shortly after, Wednesday, February 27th, 2019 UTC. These releases will incorporate at least two security fixes specific to Node.js, the highest severity of which is 'low'.

The OpenSSL project has announced releases for the 26th which may impact some release lines of Node.js and require inclusion in our security releases. The highest severity indicated by OpenSSL is 'moderate' and impacts OpenSSL 1.0.2 which is used by Node.js 6.x and 8.x. A bug-fix release for OpenSSL 1.1.1 will also be made available and we will assess the impact, if any, on Node.js 11.x which uses this version. Node.js 10.x will not be impacted by the OpenSSL releases.

Impact

Releases for all actively supported release lines will be made available to fix the following vulnerabilities.

All versions of Node.js 6 (LTS "Boron") are vulnerable to:

1 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerability
1 Misinterpretation of Input (CWE-115) vulnerability
Possible update to OpenSSL 1.0.2r depending on assessed impact

All versions of Node.js 8 (LTS "Carbon") are vulnerable to:

1 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerability
1 Misinterpretation of Input (CWE-115) vulnerability
Possible update to OpenSSL 1.0.2r depending on assessed impact

All versions of Node.js 10 (LTS "Dubnium") are vulnerable to:

1 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerability
1 Misinterpretation of Input (CWE-115) vulnerability

All versions of Node.js 11 (Current) are vulnerable to:

1 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerability
1 Misinterpretation of Input (CWE-115) vulnerability
Possible update to OpenSSL 1.1.1b depending on assessed impact

Release timing

Releases will be available at, or shortly after, Wednesday, February 27th, 2019 UTC, along with disclosure of the details for the flaws addressed in each release in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

November 2018 Security Releases

Rod Vagg — Wed, 28 Nov 2018 00:55:46 GMT

(Update 27-November-2018) Security releases available

Summary

Updates are now available for all active Node.js release lines. These include fixes for the vulnerabilities identified in the initial announcement (below). They also include upgrades of Node.js 6 and 8 to OpenSSL 1.0.2q, and upgrades of Node.js 10 and 11 to OpenSSL 1.1.0j.

We recommend that all Node.js users upgrade to a version listed below as soon as possible.

Downloads & release details

Downloads are available for the following versions. Details of code changes can also be found on each release page.

Note (3-December-2018): Node.js 6.15.1 (LTS "Boron") was released to fix a misapplied backport for one of the fixes listed below. See the release page for more information.

Debugger port 5858 listens on any interface by default (CVE-2018-12120)

Categorization: Unprotected Primary Channel (CWE-419)

All versions of Node.js 6 are vulnerable and the severity is HIGH. When the debugger is enabled with node --debug or node debug, it listens to port 5858 on all interfaces by default. This may allow remote computers to attach to the debug port and evaluate arbitrary JavaScript. The default interface is now localhost. It has always been possible to start the debugger on a specific interface, such as node --debug=localhost. The debugger was removed in Node.js 8 and replaced with the inspector, so no versions from 8 and later are vulnerable.

Reported and fixed by Ben Noordhuis.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are NOT vulnerable
All versions of Node.js 10 (LTS "Dubnium") are NOT vulnerable
All versions of Node.js 11 (Current) are NOT vulnerable

Denial of Service with large HTTP headers (CVE-2018-12121)

Categorization: Uncontrolled Resource Consumption / Denial of Service (CWE-400)

All versions of 6 and later are vulnerable and the severity is HIGH. By using a combination of many requests with maximum sized headers (almost 80 KB per connection), and carefully timed completion of the headers, it is possible to cause the HTTP server to abort from heap allocation failure. Attack potential is mitigated by the use of a load balancer or other proxy layer.

The total size of HTTP headers received by Node.js now must not exceed 8192 bytes.

Reported by Trevor Norris, fixed by Matteo Collina.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

"Slowloris" HTTP Denial of Service (CVE-2018-12122)

Categorization: Uncontrolled Resource Consumption / Denial of Service (CWE-400)

All versions of Node.js 6 and later are vulnerable and the severity is LOW. An attacker can cause a Denial of Service (DoS) by sending headers very slowly keeping HTTP or HTTPS connections and associated resources alive for a long period of time. Attack potential is mitigated by the use of a load balancer or other proxy layer.

A timeout of 40 seconds now applies to servers receiving HTTP headers. This value can be adjusted with server.headersTimeout. Where headers are not completely received within this period, the socket is destroyed on the next received chunk. In conjunction with server.setTimeout(), this aids in protecting against excessive resource retention and possible Denial of Service.

Reported by Jan Maybach (liebdich.com), fixed by Matteo Collina.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

Hostname spoofing in URL parser for javascript protocol (CVE-2018-12123)

Categorization: Misinterpretation of Input (CWE-115)

All versions of Node.js 6 and later are vulnerable and the severity is LOW. If a Node.js application is using url.parse() to determine the URL hostname, that hostname can be spoofed by using a mixed case "javascript:" (e.g. "javAscript:") protocol (other protocols are not affected). If security decisions are made about the URL based on the hostname, they may be incorrect.

Reported by Martin Bajanik (Kentico), fixed by Matteo Collina.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

HTTP request splitting (CVE-2018-12116)

Categorization: Misinterpretation of Input (CWE-115)

Node.js 6 and 8 are vulnerable and the severity is MEDIUM. If Node.js can be convinced to use unsanitized user-provided Unicode data for the path option of an HTTP request, then data can be provided which will trigger a second, unexpected, and user-defined HTTP request to made to the same server.

Reported as security concern for Node.js 6 and 8 by Arkadiy Tetelman (Lob), fixed by backporting a change by Benno Fünfstück applied to Node.js 10 and later.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are NOT vulnerable
All versions of Node.js 11 (Current) are NOT vulnerable

OpenSSL Timing vulnerability in ECDSA signature generation (CVE-2018-0735)

Severity: LOW

The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a timing side-channel attack. An attacker could use variations in the signing algorithm to recover the private key.

Impact:

All versions of Node.js 6 (LTS "Boron") are NOT vulnerable
All versions of Node.js 8 (LTS "Carbon") are NOT vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

OpenSSL Timing vulnerability in DSA signature generation (CVE-2018-0734)

Severity: LOW

The OpenSSL DSA signature algorithm has been shown to be vulnerable to a timing side-channel attack. An attacker could use variations in the signing algorithm to recover the private key.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") are vulnerable
All versions of Node.js 11 (Current) are vulnerable

OpenSSL Microarchitecture timing vulnerability in ECC scalar multiplication (CVE-2018-5407)

Severity: LOW

OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been shown to be vulnerable to a microarchitecture timing side-channel attack. An attacker with sufficient access to mount local timing attacks during ECDSA signature generation could recover the private key.

Impact:

All versions of Node.js 6 (LTS "Boron") are vulnerable
All versions of Node.js 8 (LTS "Carbon") are vulnerable
All versions of Node.js 10 (LTS "Dubnium") up to 10.8.0 are vulnerable
All versions of Node.js 10 (LTS "Dubnium") from 10.9.0 are NOT vulnerable
All versions of Node.js 11 (Current) are NOT vulnerable

Acknowledgements

Matteo Collina for a significant amount of work fixing vulnerabilities.

Sam Roberts for the OpenSSL upgrades, other code contributions and assisting in the preparion of these releases.

Ben Noordhuis, Fedor Indutny and Benno Fünfstück for code contributions.

Trevor Norris, Jan Maybach, Martin Bajanik, Arkadiy Tetelman for reporting vulnerabilities via the appropriate channels (see below).

Original post is included below

Summary

Node.js will release new versions of all supported release lines on, or shortly after, November 27th, 2018 UTC. These releases will incorporate a number of security fixes specific to Node.js, as well as the updates to OpenSSL that were released today, November 20th, 2018.

OpenSSL 1.0.2q and 1.1.0j include fixes for previously disclosed low-severity timing vulnerabilities. See the OpenSSL release announcement.

Impact

Releases for all actively supported release lines will be made available to fix the following vulnerabilities.

All versions of Node.js 6 (LTS "Boron") are vulnerable to:

2 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerabilities
2 Misinterpretation of Input (CWE-115) vulnerabilities
1 Unprotected Primary Channel (CWE-419) vulnerability

All versions of Node.js 8 (LTS "Carbon") are vulnerable to:

2 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerabilities
2 Misinterpretation of Input (CWE-115) vulnerabilities

All versions of Node.js 10 (LTS "Dubnium") are vulnerable to:

2 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerabilities
1 Misinterpretation of Input (CWE-115) vulnerability

All versions of Node.js 11 (Current) are vulnerable to:

2 Uncontrolled Resource Consumption / Denial of Service (CWE-400) vulnerabilities
1 Misinterpretation of Input (CWE-115) vulnerability

Release timing

Releases will be available at, or shortly after, the 27th of November, 2018 UTC, along with disclosure of the details for the flaws addressed in each release in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

August 2018 Security Releases

Rod Vagg — Sat, 11 Aug 2018 11:07:51 GMT

(Update 16-August-2018) Security releases available

Summary

Updates are now available for all active Node.js release lines. These include upgrades for OpenSSL and fixes for the vulnerabilities identified in the initial announcement (below).

We recommend that all users upgrade as soon as practical.

Downloads & release details

Downloads are available for the following versions. Details of code changes can also be found on each release page.

OpenSSL: Client DoS due to large DH parameter (CVE-2018-0732)

All actively supported release lines of Node.js are impacted by this flaw. Patches are included in both OpenSSL 1.1.0i (Node.js 10) and 1.0.2p (Node.js 6 LTS "Boron" and Node.js 8 LTS "Carbon").

This fixes a potential denial of service (DoS) attack against client connections by a malicious server. During a TLS communication handshake, where both client and server agree to use a cipher-suite using DH or DHE (Diffie–Hellman, in both ephemeral and non-ephemeral modes), a malicious server can send a very large prime value to the client. Because this has been unbounded in OpenSSL, the client can be forced to spend an unreasonably long period of time to generate a key, potentially causing a denial of service.

Impact:

All previous versions of Node.js 6.x (LTS "Boron") are vulnerable
All previous versions of Node.js 8.x (LTS "Carbon") are vulnerable
All previous versions of Node.js 10.x (Current) are vulnerable

Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)

Node.js does not expose RSA key generation functionality. Therefore, Node.js is not impacted by this vulnerability.

OpenSSL: ECDSA key extraction via local side-channel (CVE not assigned)

All actively supported release lines of Node.js are impacted by this flaw. Patches are included in both OpenSSL 1.1.0i (Node.js 10) and 1.0.2p (Node.js 6 LTS "Boron" and Node.js 8 LTS "Carbon").

Attackers with access to observe cache-timing may be able to extract DSA or ECDSA private keys by causing the victim to create several signatures and watching responses. This flaw does not have a CVE due to OpenSSL policy to not assign itself CVEs for local-only vulnerabilities that are more academic than practical. This vulnerability was discovered by Keegan Ryan at NCC Group and impacts many cryptographic libraries including OpenSSL.

Impact:

All previous versions of Node.js 6.x (LTS "Boron") are vulnerable
All previous versions of Node.js 8.x (LTS "Carbon") are vulnerable
All previous versions of Node.js 10.x (Current) are vulnerable

Unintentional exposure of uninitialized memory (CVE-2018-7166)

Only Node.js 10 is impacted by this flaw. Our previous announcement wrongly stated that all release lines were vulnerable.

Node.js TSC member Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR) discovered an argument processing flaw that causes Buffer.alloc() to return uninitialized memory. This method is intended to be safe and only return initialized, or cleared, memory. The third argument specifying encoding can be passed as a number, this is misinterpreted by Buffer's internal "fill" method as the start to a fill operation. This flaw may be abused where Buffer.alloc() arguments are derived from user input to return uncleared memory blocks that may contain sensitive information.

Impact:

All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
All versions of Node.js 8.x (LTS "Carbon") are NOT vulnerable
All previous versions of Node.js 10.x (Current) are vulnerable

Out of bounds (OOB) write (CVE-2018-12115)

All actively supported release lines of Node.js are impacted by this flaw.

Node.js TSC member Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR) discovered an OOB write in Buffer that can be used to write to memory outside of a Buffer's memory space. This can corrupt unrelated Buffer objects or cause the Node.js process to crash.

When used with UCS-2 encoding (recognized by Node.js under the names 'ucs2', 'ucs-2', 'utf16le' and 'utf-16le'), Buffer#write() can be abused to write outside of the bounds of a single Buffer. Writes that start from the second-to-last position of a buffer cause a miscalculation of the maximum length of the input bytes to be written.

Impact:

All previous versions of Node.js 6.x (LTS "Boron") are vulnerable
All previous versions of Node.js 8.x (LTS "Carbon") are vulnerable
All previous versions of Node.js 10.x (Current) are vulnerable

Original post is included below

Summary

The Node.js project will be releasing new versions for each of its supported release lines on, or shortly after, the 15th of August, 2018 (UTC). These releases will incorporate a number of security fixes and an upgraded version of OpenSSL.

We consider all of the flaws being addressed in these releases to be low severity. However, users should assess the severity of the impact on their own applications using the information disclosed here and the additional disclosure that will come with the releases.

OpenSSL 1.1.0i and 1.0.2p

The OpenSSL team have announced that OpenSSL 1.1.0i and 1.0.2p will be made available on the 14th of August, 2018. There will be three "LOW severity" security fixes in this release that have already been disclosed, and the fixes made available on the OpenSSL git repository. Two of these items are relevant to Node.js users:

OpenSSL: Client DoS due to large DH parameter (CVE-2018-0732)
OpenSSL: ECDSA key extraction via local side-channel (CVE not assigned)

Impact:

All versions of Node.js 6.x (LTS "Boron") are impacted via OpenSSL 1.0.2
All versions of Node.js 8.x (LTS "Carbon") are impacted via OpenSSL 1.0.2
All versions of Node.js 10.x (Current) are impacted via OpenSSL 1.1.0

Node.js security inclusions

Unintentional exposure of uninitialized memory (CVE-2018-7166)
Out of bounds (OOB) write (CVE-2018-12115)

All actively supported release lines of Node.js are impacted by these flaws.

Additional inclusions

We will also be including the following items in these releases for LTS release lines:

inspector: don't bind to 0.0.0.0 by default (v6.x) #21376: impacts Node.js 6.x (LTS "Boron") only
test: update keys/Makefile to clean and build all #19975: impacts the test suite for all actively supported release lines of Node.js

The Node.js 10 "Current" release will not be limited to only security-related updates, as per policy for non-LTS release lines.

Release timing

Releases will be available at, or shortly after, the 15th of August, 2018 (UTC), along with disclosure of details of the flaws addressed in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

June 2018 Security Releases

Michael Dawson — Tue, 12 Jun 2018 23:00:59 GMT

(Update 12-June-2018) Security releases available

Summary

Updates are now available for all active Node.js release lines. These include the fix for the vulnerabilities identified in the initial announcement (below).

We recommend that all users upgrade as soon as possible.

Downloads & release details

Denial of Service Vulnerability in HTTP/2 (CVE-2018-7161)

All versions of 8.x and later are vulnerable and the severity is HIGH. An attacker can cause a denial of service (DoS) by causing a node server providing an http2 server to crash. This can be accomplished by interacting with the http2 server in a manner that triggers a cleanup bug where objects are used in native code after they are no longer available. This has been addressed by updating the http2 implementation. Thanks to Jordan Zebor at F5 Networks for reporting this issue.

Impact:

All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
All versions of Node.js 8.x (LTS "Carbon") are vulnerable
All versions of Node.js 9.x are vulnerable
All versions of Node.js 10.x (Current) are vulnerable

Denial of Service, nghttp2 dependency (CVE-2018-1000168)

All versions of 9.x and later are vulnerable and the severity is HIGH. Under certain conditions, a malicious client can trigger an uninitialized read (and a subsequent segfault) by sending a malformed ALTSVC frame. This has been addressed through an by updating nghttp2. For further detail: https://nghttp2.org/blog/2018/04/12/nghttp2-v1-31-1/.

Impact:

All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
Versions of Node.js 8.4.x and higher (LTS "Carbon") are vulnerable
All versions of Node.js 9.x are vulnerable
All versions of Node.js 10.x (Current) are vulnerable

Denial of Service Vulnerability in TLS (CVE-2018-7162)

All versions of 9.x and later are vulnerable and the severity is HIGH. An attacker can cause a denial of service (DoS) by causing a node process which provides an http server supporting TLS server to crash. This can be accomplished by sending duplicate/unexpected messages during the handshake. This vulnerability has been addressed by updating the TLS implementation. Thanks to Jordan Zebor at F5 Networks all of his help investigating this issue with the Node.js team.

Impact:

All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
All versions of Node.js 8.x (LTS "Carbon") are NOT vulnerable
All versions of Node.js 9.x are vulnerable
All versions of Node.js 10.x (Current) are vulnerable

Memory exhaustion DoS on v9.x (CVE-2018-7164)

Versions 9.7.0 and later are vulnerable and the severity is MEDIUM. A bug introduced in 9.7.0 increases the memory consumed when reading from the network into JavaScript using the net.Socket object directly as a stream. An attacker could use this cause a denial of service by sending tiny chunks of data in short succession. This vulnerability was restored by reverting to the prior behaviour.

Impact:

All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
All versions of Node.js 8.x (LTS "Carbon") are NOT vulnerable
Versions of Node.js 9.7.0 and higher are vulnerable
All versions of Node.js 10.x (Current) are vulnerable

Calls to Buffer.fill() and/or Buffer.alloc() may hang (CVE-2018-7167)

Calling Buffer.fill() or Buffer.alloc() with some parameters can lead to a hang which could result in a Denial of Service. The following examples show the cases which hang:

Buffer.alloc(100).fill(Buffer.alloc(0))
Buffer.alloc(100).fill(Buffer.from(''))
Buffer.alloc(100).fill(new Uint8Array([]))
Buffer.alloc(100, Buffer.alloc(0))
Buffer.alloc(100, new Uint8Array([]))
new Buffer(10).fill(new Buffer(''))

In order to address this vulnerability, the implementations of Buffer.alloc() and Buffer.fill() were updated so that they zero fill instead of hanging in these cases.

All versions of Node.js 6.x (LTS "Boron") are vulnerable
All versions of Node.js 8.x (LTS "Carbon") are vulnerable
All versions of Node.js 9.x are vulnerable
All versions of Node.js 10.x (Current) are NOT vulnerable

Original post is included below

Summary

Node.js will release new versions of all supported release lines on or around June 12th, 2018 (UTC). These releases will incorporate a number of security fixes.

Impact

All versions of Node.js 6.x (LTS "Boron") are vulnerable to 1 denial-of-service (DoS) vulnerability with a severity of LOW.
All versions of Node.js 8.x (LTS "Carbon") are vulnerable to 2 denial-of-service (DoS) vulnerabilities, the highest severity being HIGH (Note This should have said 3).
Versions of Node.js 9.x are vulnerable to 5 denial-of-service (DoS) vulnerabilities, the highest severity being HIGH.
All versions of Node.js 10.x (Current) are vulnerable to 4 denial-of-service (DoS) vulnerabilities, the highest severity being HIGH.

Release timing

Releases will be available on or around June 12th, 2018 (UTC), along with disclosure of the details for the flaws addressed in each release in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

March 2018 Security Releases

Rod Vagg — Wed, 21 Mar 2018 23:49:59 GMT

(Update 28-March-2018) Security releases available

Summary

Updates are now available for all active Node.js release lines. These include the fix for the vulnerabilities identified in the initial announcement (below).

In addition to the vulnerabilities in the initial announcement, we have also included a fix for a vulnerability in the Node.js inspector functionality. This is described in detail below.

We recommend that all users upgrade as soon as possible.

Downloads & release details

OpenSSL 1.0.2o

OpenSSL version 1.0.2o was released this week. It fixed a flaw that primarily relates to PKCS#7 that may be used to cause a denial of service (DoS) attack (CVE-2018-0739). As PKCS#7 is not currently supported by Node.js and this flaw does not impact SSL/TLS functionality, our crypto team do not believe this has any impact on Node.js users.

OpenSSL 1.0.2o also contains a small number of code changes that are part of the OpenSSL project's continued code cleanup efforts. It is included in the releases for all Node.js release lines regardless of security impact.

Node.js Inspector DNS rebinding vulnerability (CVE-2018-7160)

Node.js 6.x and later include a debugger protocol (also known as "inspector") that can be activated by the --inspect and related command line flags. This debugger service was vulnerable to a DNS rebinding attack which could be exploited to perform remote code execution.

The attack was possible from malicious websites open in a web browser on the same computer, or another computer with network access to the computer running the Node.js process. A malicious website could use a DNS rebinding attack to trick the web browser to bypass same-origin-policy checks and to allow HTTP connections to localhost or to hosts on the local network. If a Node.js process with the debug port active is running on localhost or on a host on the local network, the malicious website could connect to it as a debugger, and get full code execution access.

We updated the inspector implementation with an additional check for the browser provided Host header. If the connection is via a hostname, i.e. subject to DNS resolution, we ensure that the connection is to either localhost or localhost6 precisely.

Note that this mitigation may affect some remote debugging scenarios. For example it may no longer be possible to debug a remote computer by using a hostname. Either connect using the IP address or use an ssh-tunnel to work around this additional security check. This change is therefore a "breaking change", however, as per the Node.js release plan, we are including this as a security fix on all impacted release lines as a semver-minor rather than semver-major increment.

Node.js versions 4.x were not vulnerable as the inspector debug protocol is not available in that release line.

The severity of this vulnerability is HIGH due to remote code execution risk. However, the impact should be limited to environments (e.g. development) where debuggers are typically used.

This vulnerability was reported by Timo Schmid.

`'path'` module regular expression denial of service (CVE-2018-7158)

The 'path' module in the Node.js 4.x release line contains a potential regular expression denial of service (ReDoS) vector. The code in question was replaced in Node.js 6.x and later so this vulnerability only impacts all versions of Node.js 4.x.

The regular expression, splitPathRe, used within the 'path' module for the various path parsing functions, including path.dirname(), path.extname() and path.parse() was structured in such a way as to allow an attacker to craft a string, that when passed through one of these functions, could take a significant amount of time to evaluate, potentially leading to a full denial of service.

We have determined the security risk of this vulnerability to Node.js users to be HIGH and recommend upgrading your Node.js 4.x installations as soon as possible.

This vulnerability was reported by James Davis of Virginia Tech.

Spaces in HTTP `Content-Length` header values are ignored (CVE-2018-7159)

The HTTP parser in all current versions of Node.js ignores spaces in the Content-Length header, allowing input such as Content-Length: 1 2 to be interpreted as having a value of 12. The HTTP specification does not allow for spaces in the Content-Length value and the Node.js HTTP parser has been brought into line on this particular difference.

We have determined the security risk of this flaw to Node.js users to be VERY LOW as it is difficult, and may be impossible, to craft an attack that makes use of this flaw in a way that could not already be achieved by supplying an incorrect value for Content-Length. Vulnerabilities may exist in user-code that make incorrect assumptions about the potential accuracy of this value compared to the actual length of the data supplied. Node.js users crafting lower-level HTTP utilities are advised to re-check the length of any input supplied after parsing is complete.

This change is a "breaking change" as Content-Length values containing internal spaces are now rejected in the same way that non-numeric values are rejected. However, as per the Node.js release plan, we are including this as a security fix on all release lines as a semver-minor rather than semver-major increment.

This flaw was reported by Сковорода Никита Андреевич (Nikita Skovoroda / @ChALkeR)

Update root certificates

All releases also include an update to the root certificates that are bundled in the Node.js binary. This includes 8 new additional certificates and the removal of 30 certificates. Details are available in on the public Node.js repository at https://github.com/nodejs/node/pull/19322.

Node.js uses Mozilla's NSS root certificate database. Certificates are regularly added to and removed from this database. Occasionally, certificates are revoked due to compliance or trust concerns, as is the case for the WoSign / StartCom certificates that are being removed in this update.

Please note that the NODE_EXTRA_CA_CERTS environment variable may be used to add back in certificates that have been removed if required (although this is not advised). In addition the ca option may be used when creating TLS or HTTPS servers to provide a custom list of trusted certificates.

This update was submitted by Ben Noordhuis.

Original post is included below

Summary

The Node.js project will be releasing new versions for each of its supported release lines on, or shortly after, the 27th of March, 2018 (UTC). These releases will incorporate a number of security fixes and will also likely include an upgraded version of OpenSSL.

Inclusions

OpenSSL 1.0.2o

The OpenSSL team have announced that OpenSSL 1.0.2o will be made available on the 27th of March, 2018. The highest severity issue fixed in these releases is MODERATE. According to the OpenSSL Security Policy, this classification is defined as follows:

MODERATE Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.

This post will be updated with a Node.js impact assessment for the flaws addressed in this OpenSSL release. However, regardless of severity, all actively supported Node.js release lines will likely receive an upgrade from OpenSSL 1.0.2n to 1.0.2o.

Impact:

All versions of Node.js 4.x (LTS "Argon") are impacted
All versions of Node.js 6.x (LTS "Boron") are impacted
All versions of Node.js 8.x (LTS "Carbon") are impacted
All versions of Node.js 9.x (Current) are impacted

Denial of service (DoS) vulnerability

All versions of 4.x are vulnerable to a flaw that can be used by an external attacker to cause a denial of service (DoS). The severity of this vulnerability is HIGH, users of the impacted versions should plan to upgrade when a fix is made available.

Impact:

All versions of Node.js 4.x (LTS "Argon") are vulnerable
All versions of Node.js 6.x (LTS "Boron") are NOT vulnerable
All versions of Node.js 8.x (LTS "Carbon") are NOT vulnerable
All versions of Node.js 9.x (Current) are NOT vulnerable

HTTP parsing flaw

All versions of Node.js contain a flaw in their HTTP parser whereby a malformed HTTP request may be misinterpreted. The security impact of this flaw is minimal and therefore the severity is VERY LOW. The impact relates to usability concerns but we are currently not aware of practical uses of this flaw to attack well-constructed HTTP servers.

Impact:

All versions of Node.js 4.x (LTS "Argon") are vulnerable
All versions of Node.js 6.x (LTS "Boron") are vulnerable
All versions of Node.js 8.x (LTS "Carbon") are vulnerable
All versions of Node.js 9.x (Current) are vulnerable

Update root certificates

All releases will also include an update to the root certificates that are bundled in the Node.js binary. This includes 5 new additional certificates and the removal of 30 certificates. Details are available in on the public Node.js repository at https://github.com/nodejs/node/pull/19322.

Please note that the NODE_EXTRA_CA_CERTS environment variable may be used to add back in certificates that have been removed if required (although this is not advised). In addition, the ca option may be used when creating TLS or HTTPS servers to provide a custom list of trusted certificates.

Regarding Node.js 4.x (LTS "Argon")

Please be aware that according to the Node.js release schedule, support for Node.js 4.x (LTS "Argon") will cease on the 30th of April. As this release line is in "Maintenance" and therefore receives minimal updates, this upcoming release of Node.js 4.x may be the final version for that release line.

If you have not already migrated from Node.js 4.x to a later release line, please do so at your earliest convenience. The Node.js team recommends adopting either Node.js 6.x (LTS "Boron") or Node.js 8.x (LTS "Carbon").

Release timing

Releases will be available at, or shortly after, the 27th of March, 2018 (UTC), along with disclosure of the details for the flaws addressed in each release in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Meltdown and Spectre - Impact On Node.js

Michael Dawson — Mon, 08 Jan 2018 17:30:00 GMT

Summary

Project zero has recently announced some new attacks that have received a lot of attention: https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html.

The risk from these attacks to systems running Node.js resides in the systems in which your Node.js applications run, as opposed to the Node.js runtime itself. The trust model for Node.js assumes you are running trusted code and does not provide any separation between code running within the runtime itself. Therefore, untrusted code that would be necessary to execute these attacks in Node.js could already affect the execution of your Node.js applications in ways that are more severe than possible through these new attacks.

This does not mean that you don't need to protect yourself from these new attacks when running Node.js applications. If an attacker manages to run malicious code on an unpatched OS (whether using JavaScript or something else) they may be able to access memory and or data that they should not have access to. In order to protect yourself from these cases, apply the security patches for your operating system. You do not need to update the Node.js runtime.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Data Confidentiality/Integrity Vulnerability, December 2017

Michael Dawson — Fri, 08 Dec 2017 16:30:00 GMT

(Update 7-December-2017) Security releases available

Summary

Updates are now available for all active Node.js release lines. These include the fix for the vulnerability identified in the initial announcement.

In addition the updates for 8.X and 9.X include a fix for a low severity buffer vulnerability as describe below.

We recommend that all users upgrade as soon as possible.

Downloads

Data Confidentiality/Integrity Vulnerability - CVE-2017-15896

Node.js was affected by OpenSSL vulnerability CVE-2017-3737 in regards to the use of SSL_read() due to TLS handshake failure. The result was that an active network attacker could send application data to Node.js using the TLS or HTTP2 modules in a way that bypassed TLS authentication and encryption.

The original HTTP module was not affected.
The vulnerability in the HTTP2 module (which only existing in the 8.X and 9.X lines) was fixed through nodejs/node@f3686f2. HTTP2 was previously exploitable through the submission of malicious data by an attacker.
The vulnerability in the TLS module was fixed by incorporating OpenSSL-1.0.2n into Node.js. We are not currently aware of any exploits but it was previously at a severe security risk of accepting unauthenticated data. See this advisory from OpenSSL for more details on the fixes in OpenSSL-1.0.2n secadv-20171207.txt.
The HTTPS module was not affected.

This vulnerability has been assigned CVE-2017-15896.

We would like to thank Matt Caswell (OpenSSL) and David Benjamin (Google) for reporting this.

Uninitialized buffer vulnerability - CVE-2017-15897

Node.js had a bug in versions 8.X and 9.X which caused buffers to not be initialized when the encoding for the fill value did not match the encoding specified. For example, 'Buffer.alloc(0x100, "This is not correctly encoded", "hex");' The buffer implementation was updated such that the buffer will be initialized to all zeros in these cases.

Versions 4.X and 6.X were not vulnerable.

The severity of this information disclosure vulnerability was low (due to the combination of coding errors that need to have been made in order to make it exploitable) and it has been assigned CVE-2017-15897.

Also included in OpenSSL update - CVE 2017-3738

Note that CVE 2017-3738 of OpenSSL-1.0.2 affected Node but it was low severity as described in secadv-20171207.txt.

Original post is included below

Summary

The Node.js project will be releasing new versions of 4.x, 6.x, 8.x and 9.x as soon as possible after the OpenSSL release, on or soon after December 8th UTC, to incorporate a security fix.

Data Confidentiality/Integrity Vulnerability

All versions of 4.x, 6.x, 8.x and 9.x are vulnerable to an issue to be fixed in the forthcoming OpenSSL-1.0.2n released on Dec 7, see https://mta.openssl.org/pipermail/openssl-announce/2017-December/000108.html for more details. The severity of this vulnerability of Node.js is HIGH (due to the way Node.js uses the OpenSSL APIs) and users of the affected versions should plan to upgrade when a fix is made available.

Impact

Versions 4.0 and later of Node.js are vulnerable
Versions 6.0 and later of Node.js are vulnerable
Versions 8.0 and later of Node.js are vulnerable
Versions 9.0 and later of Node.js are vulnerable

Release timing

Releases will be available as soon as possible after the OpenSSL release, along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

OpenSSL update, 1.0.2m

Rod Vagg — Mon, 30 Oct 2017 23:30:01 GMT

(Update 8-Nov-2017) Node.js Releases

Releases were made available for active lines yesterday, each including the OpenSSL 1.0.2m update. As we have not categorized these strictly as security releases they also contain other minor fixes and additions as per our regular release procedures.

While we don't consider OpenSSL 1.0.2m a critical update, you should make plans to upgrade your deployments as soon as practical.

(Update 2-Nov-2017) Node.js Impact Assessment & Release Plan

The following impact assessment for Node.js of the flaws fixed in OpenSSL 1.0.2m has been provided by Shigeki Ohtsu from our crypto team. Original details about the announcement from the OpenSSL team can be found below.

CVE-2017-3735: OOB read parsing IPAdressFamily in an X.509 certificate

CVE-2017-3735 fixes buffer over-read in parsing X.509 certificates using extensions defined in RFC3779.

Node.js disables RFC3779 support by defining OPENSSL_NO_RFC3779 during compile. It is therefore unlikely that Node.js is impacted in any way by this vulnerability.

CVE-2017-3736: Carry propagating bug in the x86_64 Montgomery squaring procedure

CVE-2017-3736 fixes a carry propagating bug in the x86_64 Montgomery squaring procedure.

Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against Diffie-Hellman are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent Diffie-Hellman parameters and a private key that is shared between multiple clients. This only affects processors that support the BMI1, BMI2 and ADX extensions like Intel Broadwell (5th generation) and later or AMD Ryzen.

CVE-2017-3736 impacts Node.js users but the likelihood of successful attack using the flaw is very low and we therefore deem it to be non-critical.

Additional fixes

OpenSSL 1.0.2m also includes two additional fixes that do not have a CVE assigned to them.

A side channel attack of ECDSA which appears too difficult to execute and can only obtain limited information about a private key.
A fix for TLS servers with SNI enabled. Node.js does not use SSL_set_SSL_CTX in this context so is not impacted.

Release plan

Due to the low impact and low severity of these fixes, we have decided not to push urgent releases of Node.js this week. Releases of all active release lines are scheduled for next Tuesday, the 7th of November and these releases will all include OpenSSL 1.0.2m along with other regular Node.js patches and additions.

Our active release lines are:

Node.js 4 LTS "Argon" (Maintenance LTS)
Node.js 6 LTS "Boron" (Active LTS)
Node.js 8 LTS "Carbon" (Active LTS)
Node.js 9 (Current)

We will include an update here once all releases are made available.

Original post is included below

The OpenSSL project has announced (also see their correction) that they will be releasing versions 1.1.0g and 1.0.2m this week, on Thursday the 2nd of November 2017, UTC. The releases will fix one "low severity security issue" and one "moderate level security issue". "Moderate" level security issues for OpenSSL:

... includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws.

Note that Node.js currently does not support or bundle OpenSSL 1.1.0, so we will focus entirely on 1.0.2m in this release.

Information about the "low" severity security issue is already public:

Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)

If an X.509 certificate has a malformed IPAddressFamily extension, OpenSSL could do a one-byte buffer overread. The most likely result would be an erroneous display of the certificate in text format.

As this is a low severity fix, no release is being made. The fix can be found in the source repository (1.0.2, 1.1.0, and master branches); see https://github.com/openssl/openssl/pull/4276. This bug has been present since 2006.

At this stage, due to embargo, it is uncertain what the nature of the "moderate" severity fix is, nor what impact it will have on Node.js users, if any. We will proceed as follows:

Within approximately 24 hours of the OpenSSL 1.0.2m release, our crypto team will make an impact assessment for Node.js users. This information may vary depending for the different active release lines and will be posted here.

As part of that impact assessment we will announce our release plans for each of the active release lines to take into account any impact. Please be prepared for the possibility of important updates to Node.js 4 "Argon", Node.js 6 "Boron", Node.js 8 "Carbon" and Node.js 9 (Current) as soon as Friday, the 3rd of November, 2017.

If our assessment concludes that the OpenSSL "moderate" security issue has very low impact for Node.js users, the Node.js release team may decide to bundle this OpenSSL upgrade with the regular, planned Node.js releases for both LTS and Current release lines and not proceed with special security releases.

Please monitor the nodejs-sec Google Group for updates, including an impact assessment and updated details on release timing within approximately 24 hours after the OpenSSL release: https://groups.google.com/forum/#!forum/nodejs-sec

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

DOS security vulnerability, October 2017

Michael Dawson — Tue, 24 Oct 2017 22:00:00 GMT

(Update 24-October-2017) Releases available

Summary

Updates are now available for all active Node.js release lines. These include the fix for the vulnerability identified in the initial announcement.

We recommend that all users upgrade as soon as possible.

Downloads

Node.js-specific security flaws

Node.js was susceptible to a remote DoS attack due to a change that came in as part of zlib v1.2.9. In zlib v1.2.9 8 became an invalid value for the windowBits parameter and Node's zlib module will crash or throw an exception (depending on the version) if you call:

zlib.createDeflateRaw({windowBits: 8})

The windowBits parameter controls how much of a message zlib keeps in memory while compressing it. A larger "window", as it's called, means more opportunities to spot and compress repeated bits of text, but results in higher memory usage. windowBits is the base-2 logarithm of the size of this window in bytes, and previously could take any integer value from 8 to 15.

This problem (Node.js crashing or throwing an exception) could be remotely exploited using some of the existing WebSocket clients that may request a value of 8 for windowBits in certain cases or with a custom built WebSocket client. There may also exist other vectors through which a zLib operation would be initiated by a remote request with a window size that results in a value of windowBits of 8.

This problem was resolved within Node.js by changing any request for a windowBits size of 8 to use a windowsBits size of 9 instead. This is consistent with previous zLib behavior and we believe minimizes the impact of the change on existing applications.

This vulnerability has been assigned CVE-2017-14919.

Original post is included below

Summary

The Node.js project will be releasing new versions of 4.x, 6.x, and 8.x the week of the 24th of October to incorporate a security fix.

Denial of Service Vulnerability

Versions 4.8.2 and later, 6.10.2 and later, as well as all versions of 8.x are vulnerable to an issue that can be used by an external attacker to cause a denial of service. The severity of this vulnerability is HIGH and users of the affected version should plan to upgrade when a fix is made available.

Impact

Versions 4.8.2 and later of Node.js are vulnerable.
Versions 6.10.2 and later of Node.js are vulnerable.
Versions 8.x of Node.js are vulnerable.

Release timing

Releases will be available at, or shortly after, the 24th of October along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Path validation vulnerability, September 2017

Michael Dawson — Fri, 29 Sep 2017 20:09:00 GMT

Path Validation Vulnerability (Updated 29-September-2017 - CVE assigned)

The Node.js project released a new version of 8.x this week which incorporates a security fix.

Impact

Version 8.5.0 of Node.js is vulnerable. 4.x and 6.x versions are NOT vulnerable.

Downloads

Node.js 8 (Current)

Node.js-specific security flaws

Node.js version 8.5.0 included a change which caused a security vulnerability in the checks on paths made by some community modules. As a result, an attacker may be able to access file system paths other than those intended.

This problem was resolved within Node.js by partially reverting https://github.com/nodejs/node/commit/b98e8d995efb426bbdee56ce503017bdcbbc6332.

A CVE has been assigned as CVE-2017-14849

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

Security updates for all active release lines, July 2017

Michael Dawson — Tue, 11 Jul 2017 17:00:00 GMT

(Update 10-August-2017) Snapshots Re-enabled on 8.3.0

The vulnerability has been patched upstream and snapshots have been re-enabled in 8.3.0

Expect a backport and update with the next release of 6.x

Download

Node.js v8 (Current)

(Update 11-July-2017) Security releases available

Summary

Updates are now available for all active Node.js release lines as well as the 7.x line. These include the fix for the high severity vulnerability identified in the initial announcement, one additional lower priority Node.js vulnerability in the 4.x release line, as well as some lower priority fixes for Node.js dependencies across the current release lines.

We recommend that users of all these release lines upgrade as soon as possible.

Downloads

Note: The 0.10.x and 0.12.x release lines are also vulnerable to the Constant Hashtable Seeds vulnerability. We recommend that users of these release lines upgrade to one of the supported LTS release lines.

Node.js-specific security flaws

Constant Hashtable Seeds (CVE-2017-11499)

Node.js was susceptible to hash flooding remote DoS attacks as the HashTable seed was constant across a given released version of Node.js. This was a result of building with V8 snapshots enabled by default which caused the initially randomized seed to be overwritten on startup. Thanks to Jann Horn of Google Project Zero for reporting this vulnerability.

You can read about the general category of hash flooding vulnerabilities here: https://events.ccc.de/congress/2011/Fahrplan/attachments/2007_28C3_Effective_DoS_on_web_application_platforms.pdf.

Snapshots have been disabled by default in these updates. Code that relies heavily on vm.runInNewContext will most likely see a performance regression until a better solution is implemented.

This is a high severity vulnerability and applies to all active release lines (4.x, 6.x, 8.x) as well as the 7.x line.

http.get with numeric authorization options creates uninitialized buffers

Application code that allows the auth field of the options object used with http.get() to be set to a number can result in an uninitialized buffer being created/used as the authentication string. For example:

const opts = require('url').parse('http://127.0.0.1:8180');
opts.auth = 1e3; // A number here triggers the bug
require('http').get(opts, res => res.pipe(process.stdout));

Parsing of the auth field has been updated in the 4.x release so that a TypeError will be thrown if the auth field is a number when http.get() is called.

This is a low severity defect and only applies to the 4.x release line.

Vulnerabilities in dependencies

The releases for the affected Node.js release lines have been updated to include the patches need to address the following issues in Node.js dependencies. These are all considered to be low severity for Node.js due to the limited impact or likelihood of exploit in the Node.js environment.

CVE-2017-1000381 - c-ares NAPTR parser out of bounds access

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Parsing of NAPTR responses could be triggered to read memory outside of the given input buffer through carefully crafted DNS response packets. The patch recommended in CVE-2017-1000381 has been added to the version of c-ares in Node.js in these releases.

This is a low severity defect and affects all active release lines (4.x, 6.x and 8.x) as well as the 7.x line.

Original post is included below

Summary

The Node.js project will be releasing new versions across all of its active release lines (4.x, 6.x, 8.x) as well as 7.x the week of July 10th 2017 to incorporate a security fix.

Denial of Service Vulnerability

All current versions of v4.x through to v8.x inclusive are vulnerable to an issue that can be used by an external attacker to cause a denial of service. The severity of this vulnerability is high and users of the affected versions should plan to upgrade when a fix is made available.

Impact

Versions 4.x of Node.js are vulnerable
Versions 6.x of Node.js are vulnerable
Versions 7.x of Node.js are vulnerable
Versions 8.x of Node.js are vulnerable

Release timing

Releases will be available at, or shortly after, Tuesday the 11th of July along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.

Contact and future updates

The current Node.js security policy can be found at https://nodejs.org/en/security/.

Please contact security@nodejs.org if you wish to report a vulnerability in Node.js.

OpenSSL update, 1.0.2k

Rod Vagg — Fri, 27 Jan 2017 11:49:06 GMT

(Update 1-February-2017) Releases available

Updates are now available for all active Node.js release lines.

The following releases are bundled with OpenSSL 1.0.2k:

While this is not a critical update, all users of these release lines should upgrade at their earliest convenience.

Original post is included below

The OpenSSL project has announced the immediate availability of OpenSSL version 1.0.2k.

Although the OpenSSL team have determined a maximum severity rating of "moderate", the Node.js crypto team (Ben Noordhuis, Shigeki Ohtsu and Fedor Indutny) have determined the impact to Node users is "low". Details on this determination can be found below.

We will therefore be scheduling releases of all active release lines (7 "Current", 6 "LTS Boron", 4 "LTS Argon") on Tuesday the 31st of January. As releases are made, they will appear on the nodejs.org news feed and this post will also be updated with details.

Node.js Impact Assessment

CVE-2017-3731: Truncated packet could crash via OOB read

This is a moderate severity flaw in OpenSSL. By default, Node.js disables RC4 so most users are not affected. As RC4 can be enabled programmatically, it is possible for a Node.js developer to craft code that may be vulnerable to this flaw. Any user activating RC4 in their codebase should prioritise this update.

All active versions of Node.js are affected, but the severity is very low for most users.

CVE-2017-3730: Bad DHE and ECDHE parameters cause a client crash

Because this flaw only impacts OpenSSL 1.1.0 and no active Node.js release line currently bundles this version, Node.js is not affected.

CVE-2017-3732: BN_mod_exp may produce incorrect results on x86_64

As noted by the OpenSSL team, the likelihood of being able to craft a practical attack that uses this flaw is very low. In addition, Node.js enables SSL_OP_SINGLE_DH_USE, further decreasing the chance of a successful exploit of this vulnerability in a Node.js service.

All active versions of Node.js are affected, but the severity is very low for Node.js users.

CVE-2016-7055: Montgomery multiplication may produce incorrect results

Some calculations, when run on an Intel Broadwell or later CPU, can produce in erroneous results. This flaw has been previously discussed by the Node.js team on GitHub. It is not believed that practical attacks can be crafted to exploit this vulnerability except in very specific circumstances. Therefore this is a low severity flaw.

All active versions of Node.js are affected, but the severity is very low for Node.js users.

October security releases and v6 LTS "Boron" security inclusions

Rod Vagg — Sat, 15 Oct 2016 10:36:44 GMT

(Update 18-October-2016) Releases available

Updates are now available for all active Node.js release lines.

The following releases all contain fixes for CVE-2016-5180 "ares_create_query single byte out of buffer write":

While this is not a critical update, all users of these release lines should upgrade at their earliest convenience.

In addition, our new Node.js v6 LTS "Boron" release line is available beginning with Node.js v6.9.0 (LTS "Boron"). Along with the transition to Long Term Support, this release also contains the following security fixes, specific to v6.x:

Disable auto-loading of openssl.cnf: Don't automatically attempt to load an OpenSSL configuration file, from the OPENSSL_CONF environment variable or from the default location for the current platform. Always triggering a configuration file load attempt may allow an attacker to load compromised OpenSSL configuration into a Node.js process if they are able to place a file in a default location.
Patched V8 arbitrary memory read (CVE-2016-5172): The V8 parser mishandled scopes, potentially allowing an attacker to obtain sensitive information from arbitrary memory locations via crafted JavaScript code. This vulnerability would require an attacker to be able to execute arbitrary JavaScript code in a Node.js process.
Create a unique v8_inspector WebSocket address: Generate a UUID for each execution of the inspector. This provides additional security to prevent unauthorized clients from connecting to the Node.js process via the v8_inspector port when running with --inspect. Since the debugging protocol allows extensive access to the internals of a running process, and the execution of arbitrary code, it is important to limit connections to authorized tools only. Note that the v8_inspector protocol in Node.js is still considered an experimental feature. Vulnerability originally reported by Jann Horn.

All of these vulnerabilities are considered low-severity for Node.js users, however, users of Node.js v6.x should upgrade at their earliest convenience.

Original post is included below

Node.js v6 LTS security inclusions

Next week, on Tuesday the 18th (late evening UTC), the Node.js Foundation will be launching its second new LTS release line, a continuation of the v6.x series of releases. This line will be codenamed "Boron" and the first version will be v6.9.0.

In addition to a change to introduce the process.release.lts property, set to 'Boron', we will also be including 3 low-severity security patches that only apply to the v6.x release series.

The security vulnerabilities being addressed are all low-severity and arise from Node.js dependencies:

V8
OpenSSL when Node.js is built in FIPS-compliant mode (not official builds)
v8_inspector, a new experimental debugging protocol

These patches will also be included in the new v7.x Current (non-LTS) release series which is due to be launched later this month.

Node.js v6 is affected
Node.js v4 (LTS "Argon") is not affected
Node.js v0.12 (Maintenance) is not affected
Node.js v0.10 (Maintenance) is not affected

CVE-2016-5180 "ares_create_query single byte out of buffer write"

A security vulnerability has been discovered in the c-ares library that is bundled with all versions of Node.js. Due to the difficulty of triggering and making use of this vulnerability we currently consider this a low-severity security flaw for Node.js users.

The patch has already been included in Node.js v6 and we will ensure that patched versions of the remaining affected versions are made available by Tuesday the 18th.

Node.js v6 is not affected
Node.js v4 (LTS "Argon") is affected
Node.js v0.12 (Maintenance) is affected
Node.js v0.10 (Maintenance) is affected

We apologise for the short notice of these releases.

Node.js Blog: Vulnerability Reports

June 2020 Security Releases

(Update 2-June-2020) Security releases available

TLS session reuse can lead to host certificate verification bypass (High) (CVE-2020-8172)

HTTP/2 Large Settings Frame DoS (Low) (CVE-2020-11080)

napi_get_value_string_*() allows various kinds of memory corruption (High) (CVE-2020-8174)

ICU-20958 Prevent SEGV_MAPERR in append (High) (CVE-2020-10531)

Downloads & release details

Summary

Impact

Release timing

Contact and future updates

OpenSSL security releases do not require Node.js security releases

Update

Summary

OpenSSL

Contact and future updates

February 2020 Security Releases

(Update 6-February-2020) Security releases available

HTTP request smuggling using malformed Transfer-Encoding header (Critical) (CVE-2019-15605)

HTTP header values do not have trailing OWS trimmed (High) (CVE-2019-15606)

Remotely trigger an assertion on a TLS server with a malformed certificate string (High) (CVE-2019-15604)

Strict HTTP header parsing (None)

Downloads & release details

Summary

Impact

Release timing

Contact and future updates

December 2019 Security Releases

(Update 18-December-2019) Releases available

Global node_modules Binary Overwrite

Symlink reference outside of node_modules

Arbitrary File Write

Downloads

Summary

Impact

Release timing

Contact and future updates

OpenSSL security releases do not require Node.js security releases

Summary

Analysis

Acknowledgements

Contact and future updates

OpenSSL security releases may require Node.js security releases

Summary

OpenSSL

Contact and future updates

August 2019 Security Releases

Downloads & release details

Vulnerabilities Fixed

Contact and future updates

February 2019 Security Releases

Summary

Downloads & release details

Node.js: Slowloris HTTP Denial of Service with keep-alive (CVE-2019-5737)

Node.js: Denial of Service with keep-alive HTTP connections (CVE-2019-5739)

OpenSSL: 0-byte record padding oracle (CVE-2019-1559)

Acknowledgements

Summary

Impact

Release timing

Contact and future updates

November 2018 Security Releases

Summary

Downloads & release details

Debugger port 5858 listens on any interface by default (CVE-2018-12120)

Denial of Service with large HTTP headers (CVE-2018-12121)

"Slowloris" HTTP Denial of Service (CVE-2018-12122)

Hostname spoofing in URL parser for javascript protocol (CVE-2018-12123)

HTTP request splitting (CVE-2018-12116)

OpenSSL Timing vulnerability in ECDSA signature generation (CVE-2018-0735)

OpenSSL Timing vulnerability in DSA signature generation (CVE-2018-0734)

OpenSSL Microarchitecture timing vulnerability in ECC scalar multiplication (CVE-2018-5407)

Acknowledgements

Summary

Impact

Release timing

Contact and future updates

August 2018 Security Releases

Summary

`napi_get_value_string_*()` allows various kinds of memory corruption (High) (CVE-2020-8174)

`ICU-20958 Prevent SEGV_MAPERR in append` (High) (CVE-2020-10531)

Global `node_modules` Binary Overwrite

Symlink reference outside of `node_modules`

`'path'` module regular expression denial of service (CVE-2018-7158)

Spaces in HTTP `Content-Length` header values are ignored (CVE-2018-7159)