CVE-2026-16318: s2n-tls QUIC Memory Leak DoS Vulnerability

CVE-2026-16318 Overview

CVE-2026-16318 is a memory leak vulnerability in the s2n-tls library, an open-source TLS implementation maintained by AWS. The flaw resides in the QUIC transport parameters extension handler, which incorrectly calls s2n_alloc instead of s2n_realloc when storing peer transport parameters. During a TLS 1.3 handshake that triggers a HelloRetryRequest, the handler executes twice on the same connection. The second invocation orphans the initial allocation, leaking approximately 64 KB of unreachable memory per handshake.

Only server-side QUIC-enabled deployments of s2n-tls are affected. Non-QUIC TLS connections do not exhibit the leak. Attackers can amplify the impact by deliberately forcing HelloRetryRequests over sustained connections.

Critical Impact
An unauthenticated remote attacker can exhaust server memory on long-running QUIC-enabled s2n-tls processes by repeatedly forcing HelloRetryRequests, degrading availability until the process is restarted.

Affected Products

s2n-tls versions prior to v1.7.6 (server-side QUIC deployments)
AWS services and downstream products bundling vulnerable s2n-tls releases
Applications linking s2n-tls with QUIC support enabled

Discovery Timeline

2026-07-21 - CVE-2026-16318 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-16318

Vulnerability Analysis

The vulnerability is a memory leak classified under [CWE-401]: Missing Release of Memory after Effective Lifetime. The QUIC transport parameters extension handler in s2n-tls is responsible for storing the peer's transport parameters on the connection state. When persisting these parameters, the handler calls s2n_alloc, which zeroes any existing pointer before allocating new memory. This behavior is safe on first invocation but discards prior allocations on subsequent calls.

In TLS 1.3, a server issues a HelloRetryRequest when the client's initial key share group does not match server preferences. This causes the client to send a second ClientHello, and the transport parameters extension handler is invoked a second time on the same connection. The correct behavior would be to call s2n_realloc, which preserves or safely resizes the existing allocation. Instead, the first allocation of up to approximately 64 KB becomes unreachable and remains resident until the process exits.

Root Cause

The root cause is the incorrect choice of allocator API in the extension handler code path. s2n_alloc does not free the prior buffer referenced by the target pointer, while s2n_realloc handles the reallocation contract correctly. Because HelloRetryRequest is a legitimate protocol flow, the double-invocation is a normal condition rather than an edge case.

Attack Vector

An unauthenticated network-based attacker can repeatedly initiate QUIC handshakes that offer a key share group the server does not prefer. Each forced HelloRetryRequest leaks up to approximately 64 KB. Over sustained traffic against a long-running server, cumulative leakage drives memory consumption upward until the process must be restarted, producing a denial-of-service condition against QUIC listeners.

No verified proof-of-concept code has been published. Refer to the GitHub Security Advisory GHSA-cr7x-863j-xrc7 for authoritative technical details.

Detection Methods for CVE-2026-16318

Indicators of Compromise

Steadily increasing resident set size (RSS) on s2n-tls server processes handling QUIC traffic without correlated increases in active connection counts.
Elevated rates of TLS 1.3 HelloRetryRequest responses on QUIC listeners from a small set of source addresses.
Repeated ClientHello messages offering non-preferred key share groups, particularly at high frequency.

Detection Strategies

Instrument s2n-tls server processes with heap profilers or jemalloc/tcmalloc telemetry to identify unreachable allocations tied to the QUIC extension handler.
Correlate memory growth metrics with QUIC handshake logs to isolate leakage driven by HelloRetryRequest volume.
Deploy network telemetry that flags anomalous ratios of HelloRetryRequests to completed handshakes per source IP.

Monitoring Recommendations

Monitor per-process memory utilization on QUIC endpoints and alert on sustained growth beyond expected baselines.
Track QUIC handshake completion ratios and HelloRetryRequest counts as first-class SRE metrics.
Log the s2n-tls version deployed across the fleet to identify unpatched instances during triage.

How to Mitigate CVE-2026-16318

Immediate Actions Required

Upgrade s2n-tls to version v1.7.6 or later on all server-side QUIC-enabled deployments.
Inventory all applications and container images that link s2n-tls and confirm the linked version.
Restart long-running server processes after patching to reclaim previously leaked memory.

Patch Information

The fix is available in s2n-tls release v1.7.6. The patch replaces the incorrect s2n_alloc call with s2n_realloc in the QUIC transport parameters extension handler, ensuring that repeated invocations during HelloRetryRequest flows do not orphan prior allocations. AWS customers should also review the AWS Security Bulletin 2026-062 for managed-service guidance.

Workarounds

Disable QUIC on s2n-tls servers if upgrading is not immediately feasible, since non-QUIC TLS connections are unaffected.
Schedule periodic restarts of QUIC-enabled server processes to reclaim leaked memory until patching completes.
Rate-limit inbound QUIC handshakes per source address to reduce the amplification available to an unauthenticated attacker.

bash

# Verify the installed s2n-tls version and upgrade
git -C s2n-tls describe --tags
git -C s2n-tls fetch --tags
git -C s2n-tls checkout v1.7.6
cmake --build build --target install