CVE-2021-3449

What it actually does

This vulnerability is a remote denial-of-service condition in OpenSSL TLS servers using OpenSSL 1.1.1 through 1.1.1j. A TLSv1.2 client-initiated renegotiation ClientHello can trigger a NULL pointer dereference when the renegotiation message omits the signature_algorithms extension that was present in the original ClientHello while including the signature_algorithms_cert extension. The result is a process crash in the TLS-terminating service. Confidentiality and integrity are not directly impacted, and OpenSSL TLS clients are not affected. The vulnerable condition requires TLSv1.2 and renegotiation to be enabled, which was commonly the default for affected OpenSSL versions.

Why it matters to the business

An unauthenticated remote attacker can crash internet-facing or internal services that terminate TLS with affected OpenSSL versions, causing outages, failed customer connections, degraded API availability, and operational disruption. Because OpenSSL is widely embedded in web servers, proxies, application runtimes, appliances, and downstream software such as Node.js builds, exposure may exist both in directly installed libraries and statically bundled dependencies. The issue is not listed in CISA KEV and is not associated with ransomware use in the provided data, but the EPSS score is elevated, so organizations should treat externally reachable TLS services as higher priority for remediation.

How an attack unfolds

An attacker first identifies a TLS service that supports TLSv1.2 and allows client-initiated renegotiation while using an affected OpenSSL 1.1.1 release. The attacker establishes an initial TLS connection with a normal ClientHello that includes signature_algorithms. During renegotiation, the attacker sends a crafted TLSv1.2 ClientHello that changes the extension set by omitting signature_algorithms while including signature_algorithms_cert. The vulnerable OpenSSL server code dereferences a NULL pointer while processing the renegotiation extensions, causing the TLS-terminating process to crash. Repeating the sequence against one or more service instances can produce sustained denial of service until the service is patched, renegotiation is disabled, or traffic is filtered.

How to fix it

Upgrade affected OpenSSL 1.1.1 installations to OpenSSL 1.1.1k or later. OpenSSL 1.1.1 through 1.1.1j are affected; OpenSSL 1.0.2 is not affected by this issue. For source-based builds, apply the OpenSSL fix corresponding to commit e2885ef548103d332889de78b51be4303ea79938. For Node.js source consumers or products embedding Node.js/OpenSSL, apply a fixed build containing commit 58db386a1be17499a444df6a78743c9dfb3cfbe3 or use a vendor release that incorporates the OpenSSL 1.1.1k fix. Restart or redeploy all services that dynamically link to OpenSSL after upgrading, and rebuild statically linked applications or containers that embed vulnerable OpenSSL code. If immediate patching is not possible, reduce exposure by disabling TLS renegotiation where supported, terminating TLS on a patched proxy or load balancer, limiting access to sensitive TLS endpoints, and monitoring/restarting affected services while permanent fixes are deployed.

How to confirm the fix worked

Confirm the runtime OpenSSL version used by each TLS-terminating process, not only the system package version. Use commands such as `openssl version -a`, package manager inventory, container image inspection, software bill of materials data, and binary linkage checks such as `ldd` or equivalent platform tooling. Verify that no service is using OpenSSL 1.1.1 through 1.1.1j, including statically linked applications and bundled runtimes. Confirm patched OpenSSL reports 1.1.1k or later, or that vendor packages explicitly backport the fix. Validate that services were restarted after library updates. Where patching is delayed, test whether client-initiated TLS renegotiation is disabled or blocked at the TLS termination layer. Review vulnerability scanner results and dependency manifests for OpenSSL and Node.js builds that include affected OpenSSL versions.

Typical attack path

1. Scan or probe target services to find TLS endpoints that negotiate TLSv1.2.
2. Determine whether client-initiated TLS renegotiation is accepted by the service.
3. Open a TLS session using a ClientHello that includes the signature_algorithms extension.
4. Initiate TLSv1.2 renegotiation on the established connection.
5. Send a malformed renegotiation ClientHello that omits signature_algorithms but includes signature_algorithms_cert.
6. Trigger a NULL pointer dereference in the affected OpenSSL server process.
7. Repeat the request pattern to crash restarted workers or multiple backend instances and sustain service disruption.

How to detect it

To determine whether this issue was already exploited, focus on evidence of TLS-facing process crashes that coincide with unusual TLSv1.2 renegotiation activity. Review system logs, service logs, crash reporters, supervisor logs, container orchestration events, and core dump directories for segmentation faults in processes linked against libssl or libcrypto. Useful sources include Linux syslog or journald, kernel logs, web server error logs, reverse proxy logs, application runtime logs, endpoint detection telemetry, load balancer TLS logs, packet captures, and network IDS metadata. Look for repeated short-lived TLS connections from the same source followed by service restarts, worker crashes, or core dumps. In packet captures or TLS inspection metadata, look for TLSv1.2 renegotiation ClientHello messages where the renegotiation ClientHello includes extension type 50 / 0x0032, signature_algorithms_cert, and does not include extension type 13 / 0x000d, signature_algorithms. Because exploitation causes denial of service rather than code execution, there may be no persistent host artifact beyond crash evidence, restart events, and network traces.

• segfault.*libssl.so.1.1
• segmentation fault.*libssl.so.1.1
• kernel:.*segfault.*libssl.so.1.1
• systemd-coredump.*libssl.so.1.1
• core dumped.*libssl.so.1.1
• core dumped.*nginx
• core dumped.*apache2
• core dumped.*httpd
• core dumped.*haproxy
• core dumped.*node
• Segmentation fault.*nginx
• Segmentation fault.*apache2
• Segmentation fault.*httpd
• Segmentation fault.*haproxy
• Segmentation fault.*node
• tls_parse_ctos_sig_algs
• signature_algorithms_cert
• extension 50
• 0x0032
• TLSv1.2 renegotiation
• ClientHello.*signature_algorithms_cert
• ClientHello.*renegotiation
• /var/lib/systemd/coredump/
• /var/crash/
• /var/log/syslog
• /var/log/messages
• /var/log/kern.log

What your security team should do

• Prioritize externally reachable TLS services using OpenSSL 1.1.1 through 1.1.1j for immediate upgrade to OpenSSL 1.1.1k or later.
• Inventory all TLS termination points, including web servers, reverse proxies, API gateways, mail services, VPN portals, appliances, containers, and applications that statically bundle OpenSSL.
• Rebuild and redeploy applications and container images that embed vulnerable OpenSSL, rather than relying only on operating system package updates.
• Disable client-initiated TLS renegotiation where operationally feasible, especially on internet-facing services.
• Add monitoring for repeated TLS handshake renegotiation errors, process crashes, segmentation faults, core dumps, and rapid service restarts in TLS-facing applications.
• Review historical logs for crash patterns around TLS handshakes to assess whether exploitation may have occurred before patching.
• Use compensating controls such as patched load balancers, rate limiting, and source filtering for services that cannot be upgraded immediately.
• Track vendor advisories for products that bundle OpenSSL or Node.js and confirm that fixes are included in deployed versions.