CVE-2026-16318

ŚrednieCVSS 5.3

Opublikowano: 21/07/2026(UTC)Zaktualizowano: 22/07/2026(UTC)Przetłumaczono: 25/07/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.39%

Percentyl 31 - wyżej niż 31% wszystkich znanych CVE

Streszczenie

W bibliotece s2n-tls w wersji przed 1.7.6 wykryto wyciek pamięci w obsłudze rozszerzeń parametrów transportowych QUIC. Podczas połączenia TLS 1.3 z HelloRetryRequest procedura jest wywoływana dwukrotnie, a drugie wywołanie używa s2n_alloc zamiast s2n_realloc, co powoduje wyzerowanie wskaźnika i wyciek pierwszego przydziału pamięci.

Ocena ryzyka

Nieuwierzytelniony użytkownik może celowo wymuszać HelloRetryRequests, powodując wyciek do 64 KB pamięci na każdy handshake. W długotrwałych procesach serwerowych może to prowadzić do zwiększonego zużycia pamięci, aż do restartu procesu.

Rekomendacja

Zaleca się aktualizację biblioteki s2n-tls do wersji 1.7.6 lub nowszej.

Inne podatności w s2n-tls

CVE-2026-16317Średnie
W bibliotece s2n-tls brakuje walidacji zewnętrznego bajtu content_type w szyfrowanych rekordach TLS 1.3. Umożliwia to aktywnemu atakującemu typu man-in-the-middle ciche odrzucanie pojedynczych rekordów danych aplikacji bez wykrycia przez żadną ze stron. Implementacja AEAD w s2n-tls na stałe koduje wartość application_data w dodatkowych danych uwierzytelniających, zamiast używać rzeczywistego bajtu z sieci, przez co zewnętrzny content_type nie jest objęty tagiem uwierzytelniającym.

Oryginalny opis (angielski, źródło NVD)

The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS