CVE-2022-3602

What it actually does

This is a stack-based buffer overflow in OpenSSL 3.0.x certificate validation, reached during X.509 name constraints processing after certificate chain signature checks. A malicious certificate containing a specially crafted email address can cause OpenSSL to overwrite four attacker-controlled bytes on the stack. In practical terms, the most likely impact is process crash and denial of service; remote code execution is theoretically possible but is reduced by common compiler and platform protections such as stack canaries, ASLR, non-executable stacks, and favorable stack layout. The issue affects applications using OpenSSL 3.0.0 through 3.0.6, including software that embeds or links affected OpenSSL versions such as impacted Node.js builds. It can be triggered on TLS clients that connect to a malicious server presenting a malicious certificate, and on TLS servers only when the server requests or requires client certificate authentication and validates a malicious client certificate.

Why it matters to the business

Successful exploitation can interrupt services that depend on affected OpenSSL certificate verification, causing application crashes, failed outbound integrations, degraded API availability, or denial of service against TLS endpoints that use mutual TLS. The vulnerability received high public attention and has a high EPSS score, so exposed or widely deployed OpenSSL 3.0.x components should be treated as a priority even though it is not listed in CISA KEV and no ransomware association is indicated. Organizations using Node.js or other software bundles built against vulnerable OpenSSL versions may have indirect exposure even if OpenSSL is not installed as a standalone package.

How an attack unfolds

An attacker first identifies an application that performs certificate validation using OpenSSL 3.0.0 through 3.0.6. For a client-side target, the attacker operates or compromises a TLS server and presents a certificate chain that reaches the vulnerable name constraints code path, with a crafted email address field in the certificate. The client connects to the malicious server and performs certificate verification. For a server-side target, the attacker connects to a TLS service that requests client certificate authentication and supplies a malicious client certificate. The vulnerable OpenSSL code processes the X.509 name constraints and triggers a stack overflow. Depending on the platform and build protections, the process may terminate immediately, causing denial of service, or in less likely circumstances the attacker may gain control over execution flow. Exploitation requires a malicious certificate accepted far enough into verification to reach name constraints checking, either because a CA signed it or because the application continues verification after failing to build a trusted chain.

How to fix it

Upgrade all affected OpenSSL 3.0.x deployments to OpenSSL 3.0.7 or later. For Node.js source or embedded builds that include the vulnerable OpenSSL code, update to a Node.js version or source revision that incorporates the fix; the provided fixed Node.js Git revision is 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f. Rebuild and redeploy statically linked applications, containers, appliances, language runtimes, and vendor packages that bundle OpenSSL rather than relying only on operating system package updates. If immediate patching is not possible, reduce exposure by disabling mutual TLS client certificate authentication where not required, restricting which peers can present client certificates, avoiding outbound TLS connections to untrusted destinations from vulnerable clients, and ensuring certificate verification failures are not ignored or bypassed. Mitigations should be considered temporary; patching is the primary corrective action.

How to confirm the fix worked

Confirm the runtime OpenSSL version used by each application, not only the system OpenSSL package. Use commands such as `openssl version -a`, application-specific version reporting, package metadata, container image scans, and binary dependency inspection to verify OpenSSL 3.0.7 or later is in use. For Node.js, verify the Node.js release or build includes the fixed OpenSSL code, and where source tracking is used, confirm inclusion of commit 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f or an equivalent upstream fix. Restart services after updating shared libraries and rebuild statically linked artifacts. Validate that TLS clients and services using client certificate authentication still complete normal certificate validation after the update. Exposure remains if any deployed process, container, appliance, or bundled runtime still reports OpenSSL 3.0.0 through 3.0.6.

Typical attack path

1. Identify software using OpenSSL 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, or 3.0.6, including embedded runtimes such as affected Node.js builds.
2. Determine whether the target acts as a TLS client connecting to attacker-controlled servers, or as a TLS server that requests client certificate authentication.
3. Create or obtain a certificate chain that reaches OpenSSL name constraint validation and includes a maliciously crafted email address field.
4. For client-side exploitation, lure or cause the application to initiate a TLS connection to an attacker-controlled endpoint presenting the malicious certificate.
5. For server-side exploitation, connect to the target service and present the malicious certificate during client certificate authentication.
6. Trigger vulnerable X.509 name constraint processing in OpenSSL.
7. Cause the application process to crash, or attempt more advanced exploitation where platform protections and stack layout allow code execution.

How to detect it

Look for evidence of attempted exploitation in TLS-facing application logs, reverse proxy logs, mutual TLS authentication logs, endpoint crash telemetry, core dumps, and system journals. For client-side exposure, review outbound TLS connection logs shortly before unexplained crashes, especially connections to unusual, newly seen, or attacker-controlled destinations. For server-side exposure, focus on services that request client certificates and inspect handshake failures involving unusual client certificates or certificate name constraint errors. On Linux, check syslog, journald, kernel logs, coredumpctl, application supervisor logs, and container runtime logs for segmentation faults in processes linked to OpenSSL 3.0.x. In crash dumps or stack traces, look for OpenSSL X.509, name constraint, email address, and punycode processing functions. For Node.js services, inspect application crash logs and process manager output for abrupt exits during TLS handshakes or certificate verification. Because there is no single reliable network IOC for this vulnerability, treat clusters of TLS certificate validation errors followed by process crashes as suspicious and preserve malicious certificates, packet captures, and core dumps for analysis.

• 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
• OpenSSL 3.0.7
• ossl_punycode_decode
• ossl_a2ulabel
• X509_check_email
• NAME_CONSTRAINTS_check
• NAME_CONSTRAINTS_check_CN
• X509_verify_cert
• permitted subtree violation
• excluded subtree violation
• name constraints
• certificate verify failed
• segfault
• Segmentation fault
• SIGSEGV
• core dumped
• coredumpctl
• client certificate
• tlsv1 alert unknown ca
• bad certificate
• 8c1dd95f3cc5d91acb9ce8994b3ac45ab927178f

What your security team should do

• Prioritize inventory of OpenSSL 3.0.x usage across servers, endpoints, containers, CI/CD images, appliances, and embedded runtimes such as Node.js.
• Patch or rebuild all software using OpenSSL 3.0.0 through 3.0.6 to OpenSSL 3.0.7 or later, prioritizing internet-facing services, mutual TLS endpoints, and systems that make outbound TLS connections to untrusted destinations.
• Do not assume operating system patching fixes statically linked or bundled OpenSSL copies; scan application binaries and container layers for embedded vulnerable versions.
• Review TLS services that request client certificates and restrict client certificate authentication to trusted networks or known partners until patching is complete.
• Review applications that ignore certificate validation errors and correct that behavior, because continuing verification after trust-chain failure can increase reachability of the vulnerable code path.
• Monitor for abnormal process crashes, segmentation faults, TLS handshake failures, and certificate validation errors around services using OpenSSL 3.0.x.
• Use the high EPSS score as a prioritization signal despite the lack of KEV listing, because public awareness and broad dependency reach make delayed remediation risky.