CVE-2023-5678

Overview

Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. It uses an event-driven, non-blocking I/O model and is widely used for web applications and server-side development. Node.js compiles its own copy of OpenSSL from deps/openssl in the Node.js source tree and statically links it into the runtime, and the built-in crypto module uses that bundled copy for Diffie-Hellman (DH) key generation and key agreement.

A vulnerability (CVE-2023-5678) has been identified in the OpenSSL library bundled with Node.js. Generating an X9.42 DH key with DH_generate_key(), or checking an X9.42 DH public key or parameters with DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check(), can be very slow when the parameters are excessively long. Where the key or parameters come from an untrusted source, this can lead to a denial of service. EVP_PKEY_generate() is affected as well, since it calls DH_generate_key().

This flaw maps to CWE-606 (Unchecked Input for Loop Condition), where the amount of work done depends on input that is never checked, and to CWE-754 (Improper Check for Unusual or Exceptional Conditions). X9.42 DH parameters include a prime modulus p and a subgroup order q. After CVE-2023-3446 and CVE-2023-3817, DH_check() rejected oversized values, but DH_check_pub_key() checked neither an excessively large p nor q, and DH_generate_key() checked p but not q, so oversized parameters could still drive these functions into very long computations.

OpenSSL's TLS implementation is not affected, and neither are OpenSSL's 3.0 and 3.1 FIPS providers. Node.js's built-in crypto.DiffieHellman calls both DH_generate_key() (in generateKeys()) and DH_check_pub_key() (in computeSecret()), but it only ever accepts a prime and a generator and always leaves q empty, so the q-related slowdowns cannot be reached through it; the remaining large-p case in DH_check_pub_key() matters only for applications that let an attacker choose the DH prime. Exposure otherwise depends on native addons or embedders that handle untrusted X9.42 DH parameters through the bundled OpenSSL. This issue affects every Node.js release line from 4.x through 21.x up to the versions listed above.

Details

Module Info

• Product: Node.js
• Affected packages: node (bundles OpenSSL under deps/openssl)
• Affected versions: >=4.0.0 <=4.9.1 >=5.0.0 <=5.12.0 >=6.0.0 <=6.17.1 >=7.0.0 <=7.10.1 >=8.0.0 <=8.17.0 >=9.0.0 <=9.11.2 >=10.16.0 <=10.24.1 >=11.9.0 <=11.15.0 >=12.0.0 <=12.22.12 >=13.0.0 <=13.14.0 >=14.0.0 <=14.21.3 >=15.0.0 <=15.14.0 >=16.0.0 <=16.20.2 >=17.0.0 <=17.9.1 >=18.0.0 <18.19.1 >=19.0.0 <=19.9.0 >=20.0.0 <20.11.1 >=21.0.0 <21.6.2
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://nodejs.org/en/download
• Package manager: Not applicable; Node.js is distributed as runtime builds from nodejs.org rather than as a published npm package
• Fixed in: Node.js 18.19.1, 20.11.1 and 21.6.2 (all February 14, 2024), security releases that upgraded the bundled OpenSSL to 3.0.13; Node.js NES v16.20.3 (16.x line, shipped July 30, 2024), v14.21.4 (14.x line, shipped August 24, 2024) and v12.22.13 (12.x line, shipped November 10, 2025). OpenSSL published the 1.1.1 fix only to premium support customers, so no upstream Node.js release on an OpenSSL 1.1.1 line (12.x, 14.x, 16.x) carries it. The other release lines listed above never received a fix

Vulnerability Info

This Medium-severity vulnerability is found in the OpenSSL library that Node.js bundles and statically links at deps/openssl, in Node.js releases whose bundled OpenSSL predates 3.0.13, and in every release that bundles OpenSSL 1.1.1 or 1.0.2, whose fixes OpenSSL released only to premium support customers. NVD assigns a CVSS v3.1 score of 5.3; OpenSSL rates the issue Low under its own severity policy.

Checking an X9.42 DH public key involves exponentiation modulo p using q, and generating a key involves arithmetic on numbers the size of q, so the work grows with the size of these parameters. The DH functions already had size limits for p in some places, but DH_check_pub_key() had none and nothing limited q. The fix makes DH_check_pub_key() refuse an excessively large p before doing any work and flag a q that is larger than p, and makes DH_generate_key() and the related public-key check reject a q larger than the maximum modulus size. See the OpenSSL 3.0 fix commit for the exact change.

An attacker needs to get oversized X9.42 DH parameters or a DH key built on them generated or checked by an application, for example by submitting them to a service that validates uploaded keys. The OpenSSL pkey (with -pubcheck) and genpkey command-line tools are also affected. The result is long CPU-bound delays in the process doing the work.

Note: OpenSSL's TLS implementation does not call the affected functions, so TLS connections are not a route to this issue, and Node.js's built-in crypto.createDiffieHellman() never passes a q value to them.

Mitigation

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Node.js LTS release (22.x or 24.x), both of which bundle OpenSSL 3.5, which includes this fix.
• Migrate affected applications away from the End-of-Life Node.js release lines.
• Leverage a commercial support partner like HeroDevs for post-EOL security support, through Node.js NES.

Credits

• David Benjamin from Google (finder)
• Richard Levitte from the OpenSSL project (remediation developer)