CVE-2022-3786

What it actually does

This is a stack-based buffer overrun in X.509 certificate verification during name-constraint checking. A malicious certificate containing a crafted email address can cause vulnerable OpenSSL-derived certificate verification logic, including affected Node.js builds that include the vulnerable code, to write an arbitrary number of period characters to the stack. The flaw is reached only after certificate chain signature verification, so exploitation generally requires a malicious certificate signed by a CA trusted by the victim, or an application configuration that continues verification even when a trusted issuer path cannot be built. The practical impact is primarily process crash and denial of service rather than reliable code execution.

Why it matters to the business

Systems using affected Node.js builds for TLS client or server certificate validation may be remotely crashed by malicious certificates, causing service disruption, failed outbound integrations, interrupted APIs, or instability in services that rely on TLS or mutual TLS. The high EPSS score indicates broad attacker interest or likelihood of exploitation activity even though it is not currently listed in CISA KEV and is not known as ransomware-used. Because Node.js is commonly embedded in applications, CI/CD tooling, internal services, agents, and web stacks, exposure may exist indirectly through packaged runtimes as well as explicitly installed Node.js versions.

How an attack unfolds

An attacker first obtains or creates a certificate containing a specially crafted email address in a field evaluated during X.509 name-constraint checking. To reach the vulnerable path reliably, the certificate must either chain to a CA trusted by the target or be processed by software that continues verification after a trust-path construction failure. Against a TLS client, the attacker hosts a malicious TLS service and induces the vulnerable client application to connect to it. During the TLS handshake, the client receives the malicious certificate, performs certificate verification, reaches name-constraint processing, and triggers the buffer overrun, typically terminating the process. Against a TLS server, exploitation is possible when the server requests or requires client certificate authentication; the attacker connects with a malicious client certificate, causing the server-side verification path to process the crafted certificate and crash the service.

How to fix it

Upgrade affected Node.js builds to a version or source revision that contains the fix for the bundled certificate verification code. For source-based Node.js consumers, ensure the repository includes commit 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f or a later equivalent fix. Where Node.js is distributed through operating system packages, containers, language runtime images, appliance firmware, or vendor bundles, apply the vendor-provided security update rather than relying only on application dependency updates. Rebuild and redeploy containers and static runtime bundles so the fixed runtime is actually present at execution time. As compensating controls, avoid permissive certificate-verification modes, do not continue verification after path-building failure unless absolutely necessary, restrict outbound TLS destinations where feasible, and limit mutual TLS client-certificate acceptance to trusted issuers with strict validation.

How to confirm the fix worked

Confirm the active Node.js runtime, embedded runtime, or source build includes the fixed commit 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f or a vendor release that incorporates it. Validate both build-time and runtime versions, including container images, serverless layers, CI runners, packaged desktop applications, and vendor-supplied agents that may carry their own Node.js or OpenSSL build. Use software composition analysis or runtime inventory to identify affected Node.js instances, then verify replacement artifacts were rebuilt after the fixed runtime was introduced. Where safe test harnesses are available, perform controlled TLS certificate-validation testing in a non-production environment to confirm malformed certificate inputs no longer crash the process.

Typical attack path

1. Identify a target application or service using an affected Node.js build or vulnerable bundled OpenSSL certificate verification logic.
2. Determine whether the target acts as a TLS client to attacker-controllable endpoints or as a TLS server requiring or requesting client certificates.
3. Prepare a malicious X.509 certificate with a crafted email address that triggers name-constraint processing overflow behavior.
4. Ensure the certificate is accepted far enough into verification, either by using a trusted CA-signed chain or relying on permissive certificate-validation behavior.
5. Present the malicious certificate during a TLS handshake.
6. Trigger certificate verification and cause the vulnerable process to crash, resulting in denial of service.
7. Repeat connections as needed to sustain service disruption until the vulnerable runtime or dependency is patched or mitigated.

How to detect it

Look for evidence of unexplained process termination during TLS handshakes or certificate verification, especially in services using Node.js for HTTPS, TLS, mTLS, API clients, webhook clients, proxies, or agents. Useful log sources include application logs, Node.js stderr/stdout, process supervisor logs, container runtime logs, Kubernetes pod events, systemd journals, core dump metadata, reverse proxy logs, TLS termination logs, endpoint detection telemetry, and network flow records. For TLS clients, investigate crashes immediately after connections to unusual, newly observed, or attacker-controlled destinations. For TLS servers using client certificate authentication, investigate repeated failed handshakes, abrupt disconnects, or process restarts associated with a small set of source IPs. Forensic artifacts may include core dumps or crash reports with stack traces referencing OpenSSL X.509 name constraint, email name, punycode, or certificate verification functions. Because exploitation generally results in denial of service rather than a durable payload, absence of files or persistence artifacts does not rule out attempted exploitation.

• CVE-2022-3786
• ossl_punycode_decode
• ossl_a2ulabel
• NAME_CONSTRAINTS_check
• X509_verify_cert
• certificate verify failed
• name constraint
• name constraints
• permitted subtree
• excluded subtree
• client certificate verification failed
• TLS alert, certificate unknown
• tlsv1 alert unknown ca
• Segmentation fault
• core dumped
• node: Segmentation fault
• node[
• Fatal error in OpenSSL
• OpenSSL 3.0.0
• OpenSSL 3.0.1
• OpenSSL 3.0.2
• OpenSSL 3.0.3
• OpenSSL 3.0.4
• OpenSSL 3.0.5
• OpenSSL 3.0.6

What your security team should do

• Prioritize patching internet-facing services, high-availability systems, mutual TLS endpoints, and applications that make outbound TLS connections to untrusted or user-controlled destinations.
• Inventory all Node.js runtimes, container base images, serverless layers, build agents, packaged applications, and vendor components that may embed the vulnerable certificate verification code.
• Upgrade affected source builds to include commit 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f or later, and apply vendor security releases for packaged distributions.
• Rebuild and redeploy containers and application bundles after upgrading; do not assume the fix is present until the running artifact has been verified.
• Review TLS client and server certificate-validation behavior and remove configurations that continue processing after trust-chain validation failure unless there is a documented business requirement.
• For mTLS services, restrict accepted client certificate issuers and monitor failed or abnormal client-certificate handshakes.
• Add monitoring for unexplained Node.js process crashes, TLS handshake failures, and certificate-validation errors, especially where followed by automatic service restarts.
• Because EPSS is high, treat remaining exposed instances as likely to be probed even though there is no current KEV listing or confirmed ransomware association.