CVE-2023-0401

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, so a flaw in the bundled OpenSSL is present in every Node.js binary built from that tree. Node.js 17.x was the first release line to bundle OpenSSL 3.0.

A vulnerability (CVE-2023-0401) has been identified in the OpenSSL 3.0 library bundled with Node.js. When OpenSSL verifies signatures on PKCS#7 signed or signedAndEnveloped data that uses a hash algorithm OpenSSL recognizes but cannot currently provide, the digest setup fails, OpenSSL ignores the failure, and a later digest operation dereferences a NULL pointer, most likely crashing the process.

This flaw maps to CWE-476 (NULL Pointer Dereference), where software uses a pointer it expects to be valid when it is actually NULL. In OpenSSL 3.0, digests are fetched from providers at run time, so a known algorithm can still be unavailable, for example MD4 when the legacy provider is not loaded, or a non-approved digest under a FIPS configuration. The PKCS#7 code did not check whether setting up the digest had succeeded, and went on to use the uninitialized digest.

PKCS#7 data is processed by OpenSSL's S/MIME functions and by its time stamp (TS) functions. An attacker needs an application that verifies signatures on untrusted PKCS#7 data with those functions and can then supply signed data that names an unavailable digest. OpenSSL's TLS implementation does not call these functions, and Node.js's built-in modules do not either, so exposure in a Node.js deployment depends on native addons or embedders that verify PKCS#7 through the bundled OpenSSL. This issue affects the Node.js 17.x, 18.x and 19.x release lines up to the versions listed above.

Details

Module Info

• Product: Node.js
• Affected packages: node (bundles OpenSSL 3.0 under deps/openssl)
• Affected versions: >=17.0.0 <=17.9.1 >=18.0.0 <18.14.1 >=19.0.0 <19.6.1
• 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.14.1 and 19.6.1 (February 16, 2023), security releases that upgraded the bundled OpenSSL to 3.0.8; this CVE is also listed in the Node.js NES v16.20.3 release notes (16.x line, shipped July 30, 2024). Node.js 17.x never received a fix

Vulnerability Info

This High-severity vulnerability is found in OpenSSL 3.0.0 through 3.0.7, the versions bundled by Node.js 17.x, 18.x and 19.x before the releases listed above. NVD assigns a CVSS v3.1 score of 7.5; OpenSSL rates the issue Moderate under its own severity policy.

To verify a PKCS#7 signature, OpenSSL builds a chain of message-digest BIOs, one for each hash algorithm the signed data names, and initializes each one with BIO_set_md(), which calls EVP_DigestInit(). In OpenSSL 3.0, that initialization can fail when the digest is not available from any loaded provider. In the vulnerable versions, pk7_doit.c ignored the return value of BIO_set_md(), so the digest BIO stayed uninitialized and the next read or write through it dereferenced a NULL pointer. The fix checks the return value of each BIO_set_md() call and stops with an error when it fails. See the OpenSSL fix commit for the exact change.

One crafted PKCS#7 message passed to an affected verification function is enough to crash the process. The flaw is a NULL pointer dereference and is not known to allow code execution or data disclosure.

Note: OpenSSL 1.1.1 and 1.0.2 are not affected, so Node.js release lines that bundle them, including 16.x and earlier, are not exposed by this issue. Node.js applications that rely only on the built-in crypto, tls and https modules do not verify PKCS#7 data.

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

• Hubert Kario from Red Hat (reporter)
• Dmitry Belyavsky from Red Hat (reporter)
• Tomáš Mráz from the OpenSSL project (remediation developer)