CVE-2026-16317: s2n-tls TLS 1.3 DoS Vulnerability

CVE-2026-16317 Overview

CVE-2026-16317 is a cryptographic authentication flaw in AWS s2n-tls affecting all TLS 1.3 connections. The library fails to validate the outer content_type byte of encrypted TLS 1.3 records, violating RFC 8446 Section 5.2. The s2n-tls AEAD implementation hardcodes the application_data (0x17) value in the additional authenticated data instead of using the actual wire byte. As a result, the outer content_type is not covered by the authentication tag, enabling an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification.

Critical Impact
An on-path attacker can selectively suppress TLS 1.3 application data records, causing HTTP request/response desynchronization and undetectable data loss in write-heavy workloads.

Affected Products

AWS s2n-tls versions prior to v1.7.6
TLS 1.3 clients built on s2n-tls
TLS 1.3 servers built on s2n-tls

Discovery Timeline

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

Technical Details for CVE-2026-16317

Vulnerability Analysis

The vulnerability resides in the s2n-tls Authenticated Encryption with Associated Data (AEAD) implementation for TLS 1.3. RFC 8446 requires that the outer content_type field of every encrypted TLS 1.3 record be set to application_data (0x17), and this byte must be covered by the record's authentication tag through inclusion in the additional authenticated data (AAD). The s2n-tls library instead hardcodes the constant 0x17 when constructing the AAD, ignoring the byte actually present on the wire.

This omission breaks the integrity guarantee for the outer content_type. An attacker who can intercept and modify TLS traffic can alter the outer content_type of specific records without producing an authentication failure. When the receiver validates the tag, it succeeds against the hardcoded value, and the tampered record is silently dropped by protocol handling logic that expects the standard content type. The result is selective suppression of application data records.

The issue is tracked under [CWE-354: Improper Validation of Integrity Check Value]. TLS 1.2 and QUIC connections are not affected because they use different AEAD constructions.

Root Cause

The root cause is a deviation from RFC 8446 in how s2n-tls constructs AEAD additional authenticated data. Instead of feeding the observed outer content_type byte into the AAD, the library substitutes a hardcoded constant. The authentication tag therefore never binds to the wire value, leaving that byte malleable to an on-path adversary.

Attack Vector

An active network attacker positioned between a TLS 1.3 client and server modifies the outer content_type of targeted encrypted records. In HTTP pipelining scenarios, dropping a record containing an HTTP request causes subsequent responses to be delivered to the wrong requests, enabling request/response desynchronization. In write-heavy workloads, dropping a record containing a write request can produce undetectable data loss when the client interprets a later success response as confirmation of the suppressed write.

No authentication credentials or user interaction are required. The attacker needs only a network position enabling manipulation of TLS records in transit.

Refer to the GitHub Security Advisory GHSA-684c-v35q-fvx7 for further technical detail on the AEAD construction defect.

Detection Methods for CVE-2026-16317

Indicators of Compromise

Unexplained gaps in HTTP request/response correlation across TLS 1.3 sessions terminated by s2n-tls
Application-layer write acknowledgments that do not match the sequence of client-submitted writes
Persistent latency or protocol errors from clients whose network path traverses an untrusted intermediary

Detection Strategies

Inventory all services and dependencies linked against s2n-tls and identify versions below v1.7.6
Instrument TLS 1.3 endpoints to log record counts on both sides and reconcile deltas between peers
Correlate application-layer request/response IDs to identify desynchronization patterns consistent with record suppression

Monitoring Recommendations

Enable verbose TLS handshake and record telemetry on load balancers and services using s2n-tls
Alert on abnormal ratios of sent-to-acknowledged application writes in write-heavy services
Monitor for TLS session anomalies on network paths that traverse third-party or public transit

How to Mitigate CVE-2026-16317

Immediate Actions Required

Upgrade s2n-tls to version v1.7.6 or later across all client and server deployments
Rebuild and redeploy any statically linked applications and container images that embed s2n-tls
Review AWS service dependencies and apply vendor updates referenced in AWS Security Bulletin 2026-062

Patch Information

AWS released the fix in s2n-tls v1.7.6. The patch corrects AEAD additional authenticated data construction so that the outer content_type byte from the wire is bound to the authentication tag, restoring compliance with RFC 8446 Section 5.2.

Workarounds

No configuration-based workaround is available; the fix requires the updated library
Where immediate upgrade is not feasible, restrict exposure by terminating TLS 1.3 at a non-affected proxy or load balancer
Enforce application-layer integrity controls such as idempotency keys and explicit write acknowledgments to detect suppressed records

bash

# Verify installed s2n-tls version and upgrade
ldconfig -p | grep libs2n
# Rebuild from patched source
git clone https://github.com/aws/s2n-tls.git
cd s2n-tls
git checkout v1.7.6
cmake . -Bbuild && cmake --build build