A flaw was found in the way the DES/3DES cipher was used as part of the TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to recover some plaintext data by capturing large amounts of encrypted traffic between TLS/SSL server and client if the communication used a DES/3DES based ciphersuite.

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. The security risk of this flaw to Node.js users is considered 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.

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.

Reference: https://nodejs.org/en/blog/vulnerability/february-2019-security-releases/

A flaw was found in Node.js versions before 6.15.0, 8.14.0, 10.14.0 and 11.3.0. A Denial of Service with large HTTP headers. 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.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

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.

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

A flaw was found in OpenSSL versions from 1.1.0 through 1.1.0i inclusive, from 1.0.2 through 1.0.2p inclusive and version 1.1.1. 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.

Reference: https://www.openssl.org/news/secadv/20181030.txt

Upstream Patches: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=43e6a58d4991a451daf4891ff05a48735df871ac https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8abfe72e8c1de1b95f50aa0d9134803b4d00070f https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ef11e19d1365eea2b1851e6f540a0bf365d303e7 https://github.com/openssl/openssl/commit/b96bebacfe814deb99fb64a3ed2296d95c573600

Withdrawn Advisory This advisory has been withdrawn because this vulnerability affects inspector code in https://github.com/nodejs/node, not the legacy debugger at https://github.com/node-inspector/node-inspector. https://github.com/nodejs/node is not in a supported ecosystem.

Original Description The Node.js inspector, in 6.x and later is vulnerable to a DNS rebinding attack which could be exploited to perform remote code execution. An attack is 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.

Node.js was affected by OpenSSL vulnerability CVE-2017-3737 in regards to the use of SSLread() 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 c-ares function aresparsenaptrreply(), which is used for parsing NAPTR responses, could be triggered to read memory outside of the given input buffer if the passed in DNS response packet was crafted in a particular way.

A flaw was found in Node.js versions before 6.15.0, 8.14.0, 10.14.0 and 11.3.0. A hostname spoofing in URL parser for javascript protocol. 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.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

A flaw was found in Node.js versions before 6.15.0, 8.14.0, 10.14.0 and 11.3.0. A Slowloris HTTP Denial of Service. 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.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

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.

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

A flaw was found in Node.js before 6.15.0 and 8.14.0. An HTTP request splitting. 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.

References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/

An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.

External References:

https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7

Upstream patch:

https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb

CVE assignment:

http://seclists.org/oss-sec/2016/q4/602

An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.

A man-in-the-middle (MITM) attacker may be able to execute a padding oracle attack to decrypt traffic when a connection uses an AES-CBC cipher and the server runs on an Intel CPU supporting AES-NI. This is a common configuration for TLS servers.

The OpenSSL project has labelled this vulnerability high severity.

An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.

An upgrade to zlib 1.2.11 to fix a number of low severity CVEs that were present in zlib 1.2.8.

A vulnerability was found in OpenSSL 1.0.2. When an application encounters a fatal protocol error and then calls SSLshutdown() twice, OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. This difference in behaviour can be detected by a remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Also the application must call SSLshutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). AEAD ciphersuites are not impacted. This issue does not impact OpenSSL 1.1.1 or 1.1.0.

Upstream bug: https://www.openssl.org/news/secadv/20190226.txt

Upstream Patch: https://github.com/openssl/openssl/commit/e9bbefbf0f24c57645e7ad6a5a71ae649d18ac8e

OpenSSL could allow a remote attacker to obtain sensitive information, caused by an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. An attacker could exploit this vulnerability to obtain information about the private key.

Note: In order to exploit this vulnerability, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701.

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 SSLOPSINGLEDHUSE, 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.

If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash.

For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k

External References:

https://www.openssl.org/news/secadv/20170126.txt

Last updated 24 July 2024

A malicious client can exhaust a server's memory, resulting in a denial of service (DoS) by sending very large OCSP Status Request extensions in a single session.

This flaw is labelled high severity due to the ease of use for a DoS attack and Node.js servers using TLS are vulnerable.

Last updated 24 July 2024

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/.

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

An overflow can occur in MDC2Update() under certain circumstances resulting in an out of bounds (OOB) error. This attack is impractical on most platforms due to the size of data required to trigger the OOB error.

Node.js is impacted by this flaw but due to the impracticalities of exploiting it and the very low usage of of MDC-2, it is very low severity for Node.js users.

Fix invalid wildcard certificate validation check whereby a TLS server may be able to serve an invalid wildcard certificate for its hostname due to improper validation of . in the wildcard string.

This is a high severity defect that would allow a malicious TLS server to serve an invalid wildcard certificate for its hostname and be improperly validated by a Node.js client. This is due to a flaw in the validation of . in the wildcard name string.

crypto/x509/x509vfy.c in OpenSSL 1.0.2i allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) by triggering a CRL operation.

http: Properly validate for allowable characters in the reason argument in ServerResponse#writeHead(). Fixes a possible response splitting attack vector. This introduces a new case where throw may occur when configuring HTTP responses, users should already be adopting try/catch here.

This is a low severity security defect that that may make HTTP response splitting possible under certain circumstances. If user-input is passed to the reason argument to writeHead() on an HTTP response, a new-line character may be used to inject additional responses.

The fix for this defect introduces a new case where throw may occur when configuring HTTP responses. Users should already be adopting try/catch here.

Common Vulnerability Scoring System (CVSS) v3 Base Score:

Metric Score Base Score: 4.8 (Medium) Base Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N Attack Vector: Network (AV:N) Attack Complexity: High (AC:H) Privileges Required: None (PR:N) User Interaction: None (UI:N) Scope of Impact: Unchanged (S:U) Confidentiality Impact: Low (C:L) Integrity Impact: Low (I:L) Availability Impact: None (A:N)

Refer to the CVSS v3 Specification for details on the meanings and application of the vector components.