CVE-2024-2511

What it actually does

This is a denial-of-service flaw in OpenSSL TLS servers using TLS 1.3 with the non-default SSL_OP_NO_TICKET option enabled. Under certain conditions, the TLS session cache can enter an incorrect state and fail to flush entries as it fills, causing unbounded memory growth. A remote unauthenticated client can repeatedly create TLS 1.3 session activity that forces the affected server process to consume increasing memory until performance degrades, the process is killed by the operating system, or the service becomes unavailable. TLS clients are not affected, OpenSSL 1.0.2 is not affected, and the OpenSSL 3.0, 3.1, and 3.2 FIPS modules are not affected.

Why it matters to the business

The practical risk is service instability or outage for applications, proxies, APIs, load balancers, VPN components, or other network-facing services that use affected OpenSSL TLS server code in the vulnerable configuration. Because exploitation is remote and unauthenticated but requires a specific non-default server configuration, exposure is narrower than a typical OpenSSL-wide issue; however, the EPSS score is elevated, so internet-facing TLS services should be reviewed promptly. Successful exploitation can cause degraded customer access, failed transactions, increased infrastructure load from restarts, and operational incidents due to memory exhaustion.

How an attack unfolds

An attacker first identifies a TLS service that supports TLS 1.3 and is backed by an affected OpenSSL build. The attacker then determines or assumes that the service is configured with SSL_OP_NO_TICKET and does not have a mitigating early-data anti-replay configuration. The attacker opens repeated TLS 1.3 connections and drives session establishment patterns that cause OpenSSL's server-side session cache to retain entries incorrectly. Because the cache fails to flush as intended, memory usage in the server process grows over time. If the traffic continues, the process may exhaust available memory, trigger operating-system OOM handling, crash, restart, or become too slow to serve legitimate users. The attack does not provide code execution or data theft by itself; its value is disruption of availability.

How to fix it

Upgrade OpenSSL to a fixed version supplied by the operating system, application vendor, appliance vendor, container base image, or OpenSSL project. For source builds from the affected Git repository, ensure the fix containing commit 7e4d731b1c07201ad9374c1cd9ac5263bdf35bce is present. Where packaged releases are used, deploy the vendor-fixed OpenSSL maintenance release or backport for the affected branch, commonly including fixed OpenSSL 3.0.x, 3.1.x, and 3.2.x updates. Restart or reload all services that link OpenSSL after patching; updating the library on disk is not sufficient for already-running processes. If immediate patching is not possible, reduce exposure by disabling the vulnerable configuration where feasible: avoid SSL_OP_NO_TICKET for TLS 1.3 servers, review session-cache settings, consider enabling appropriate early-data anti-replay protections if early data is used, rate-limit suspicious TLS handshakes, and place vulnerable services behind load balancers or controls that can absorb abusive connection patterns. Confirm that statically linked applications and container images are rebuilt with the fixed OpenSSL code.

How to confirm the fix worked

Confirm the OpenSSL runtime and linked library versions used by each TLS server, 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 application dependency scans. For custom builds, verify that commit 7e4d731b1c07201ad9374c1cd9ac5263bdf35bce or an equivalent vendor backport is present. Inspect server code and configuration for SSL_OP_NO_TICKET, SSL_CTX_set_options, session-cache settings, and TLS 1.3 enablement. After patching, restart affected services and verify that their loaded OpenSSL library is the fixed build using process library mapping tools such as ldd, pmap, /proc/<pid>/maps, or platform equivalents. In a controlled test environment, perform repeated TLS 1.3 handshakes against the service and monitor resident memory; fixed or non-exposed services should not show unbounded session-cache-driven growth.

Typical attack path

1. Discover externally reachable TLS services and fingerprint support for TLS 1.3.
2. Identify services likely using affected OpenSSL versions or unpatched vendor builds.
3. Target servers configured with the non-default SSL_OP_NO_TICKET option, especially where TLS session cache behavior is enabled server-side.
4. Generate repeated TLS 1.3 handshakes or session activity designed to grow the affected session cache.
5. Sustain the connection pattern until server process memory increases significantly.
6. Cause service degradation, process termination, operating-system OOM events, or application restarts.
7. Repeat the activity to keep the service unstable if no rate limiting, patch, or configuration change is applied.

How to detect it

There is no reliable single network payload or log line that uniquely proves exploitation of this issue. Detection should focus on correlated evidence: affected OpenSSL version, TLS 1.3 server role, use of SSL_OP_NO_TICKET, abnormal growth in process memory, high rates of TLS handshakes or short-lived TLS connections, and service crashes or OOM events. Review web server, reverse proxy, application, load balancer, and system logs around memory exhaustion events. Look for spikes in TLS connection attempts from one or a small set of source IPs, unusually high handshake-to-request ratios, repeated connection opens without meaningful application-layer traffic, and resident memory growth that tracks TLS connection volume. System telemetry sources should include process metrics, kernel logs, OOM-killer logs, container runtime events, service manager restart logs, reverse proxy access logs, TLS termination logs, firewall or flow logs, and EDR process telemetry. Because the issue can also happen accidentally, classify suspected exploitation only when resource exhaustion coincides with suspicious remote connection patterns against a confirmed exposed configuration.

• SSL_OP_NO_TICKET
• SSL_CTX_set_options
• SSL_OP_NO_TICKET option
• TLSv1.3
• TLS 1.3
• Out of memory
• Cannot allocate memory
• oom-killer
• Killed process
• Memory cgroup out of memory
• container killed due to memory usage
• signal 9
• exit code 137
• worker process exited on signal 9
• server reached MaxRequestWorkers
• AH00052: child pid
• upstream prematurely closed connection
• SSL_accept

What your security team should do

• Prioritize inventory of internet-facing TLS 1.3 servers using OpenSSL 3.x, especially custom-compiled applications, appliances, containers, reverse proxies, API gateways, and load balancers.
• Patch or vendor-update affected OpenSSL deployments and restart all dependent services; ensure statically linked applications and container images are rebuilt.
• Search code and configuration repositories for SSL_OP_NO_TICKET and SSL_CTX_set_options usage to identify deployments with the vulnerable non-default configuration.
• Temporarily disable SSL_OP_NO_TICKET on TLS 1.3 servers where operationally safe until patching is complete.
• Add monitoring for abnormal TLS handshake volume, rapid connection churn, process resident-memory growth, OOM-killer events, and repeated service restarts.
• Apply rate limiting or connection throttling at edge devices for excessive TLS handshakes from the same sources or networks.
• Validate that vendor appliances and bundled applications have received a backported OpenSSL fix rather than relying only on operating-system package status.
• Treat unexplained memory growth on TLS services as potentially security-relevant, even though this issue may also occur accidentally during normal operation.