Back to vendor advisories
AWS Security BulletinsCVE-2026-16317

CVE-2026-16317 and CVE-2026-16318: Issues with s2n-tls: an open-source implementation of the TLS/SSL protocols

Bulletin ID: 2026-062-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 07/21/2026 13:15 PM PDT Description: s2n-tls is an open source C99 implementation of the TLS/SSL protocol. We have identified two distinct issues: - CVE-2026-16317: Silent Drop of TLS 1.3 Encrypted Records in s2n-tls Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently drop individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. - CVE-2026-16318: QUIC Transport Parameters Memory Leak During HelloRetryRequest in s2n-tls Incorrect use of s2n_alloc instead of s2n_realloc in the QUIC transport parameters extension handler in s2n-tls causes one memory allocation to be leaked each time a QUIC-enabled TLS 1.3 connection goes through a HelloRetryRequest. This can occur during normal handshakes when a client offers a key share group the server does not prefer, and can lead to increased memory consumption on long-running server processes. Only QUIC-enabled deployments are affected. Impacted versions:

Not listedCVSS not listedNot listed severity
Scope

What the vendor says is affected

The collected bulletin did not provide a separate affected-products list. Check the original bulletin before making an exposure decision.

Update history

What changed in later vendor updates

SecurityAlert records field-level changes from the point we begin following a bulletin. Earlier vendor changes may not have a field-by-field record.

    • The vendor changed the advisory's last-updated date.
Timeline

When this advisory changed

  1. Added to SecurityAlert

    We collected the advisory from the official source.

  2. Published by AWS

    The publication date reported by the vendor.

  3. Confirmed at the source

    Our collector saw this advisory during a later source check.

Vulnerabilities

CVEs named in this advisory