CVE-2022-4203

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 the built-in tls and https modules rely on that bundled copy to verify certificate chains. Node.js 17.x was the first release line to bundle OpenSSL 3.0.

A vulnerability (CVE-2022-4203) has been identified in the OpenSSL 3.0 library bundled with Node.js. During X.509 certificate verification, OpenSSL's name constraint check can read past the end of a buffer when a certificate uses an otherName subject alternative name and its issuing CA declares an otherName name constraint. The over-read can crash the process, causing a denial of service, and could in theory disclose private memory such as keys or plaintext, although OpenSSL knew of no working exploit for disclosure.

This flaw maps to CWE-125 (Out-of-bounds Read), where software reads data past the end of the buffer it intended to read. In OpenSSL 3.0, the name constraint code assumed that whenever a certificate name was an otherName, the matching constraint was an email constraint, and read the constraint as a text string. When the constraint was actually a different otherName type, that misread ran beyond the data it was meant to examine.

The check runs only after the certificate chain's signatures have been verified. An attacker therefore needs a malicious certificate signed by a CA the victim trusts, which is why NVD scores the attack as requiring high privileges, or an application that keeps verifying a chain after failing to build a path to a trusted issuer. A Node.js TLS client can be hit by connecting to a malicious server, and a Node.js TLS server can be hit if it requests client certificates and a malicious client connects. 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 Medium-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 4.9; OpenSSL rates the issue Moderate.

Name constraints let a CA restrict which names the certificates it issues may contain. When checking a certificate name against a constraint, OpenSSL compares them by type, and treats an otherName carrying an internationalized email address (SmtpUTF8Mailbox) as an email name. In the vulnerable versions, nc_match_single() assumed that any otherName it was given had to be compared against an email constraint, so a certificate with an otherName SAN of any other type, checked against a CA's otherName constraint, sent the constraint into the email comparison as if it were a text string. The fix passes the name's effective type into the comparison so only real email constraints are treated that way. See the OpenSSL fix commit for the exact change.

In practice the attacker must present a chain whose signatures verify, which in most deployments means getting a trusted CA to issue the malicious certificate. The most likely outcome is a crash of the Node.js process performing the TLS handshake.

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.

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

• Corey Bonnell from Digicert (finder)
• Viktor Dukhovni (remediation developer)