CVE-2026-95691
Received
Received - Intake
Use After Free in OpenSSL QUIC Client
Vulnerability report for CVE-2026-95691, including description, CVSS score, EPSS score, affected products, exploitability, helpful resources, and attack-flow context.
Publication date: 2026-11-10
Last updated on: 2026-11-10
Assigner: OpenSSL Software Foundation
Description
Description
Issue summary: A retransmitted QUIC CRYPTO frame can release packet storage
while the TLS record layer retains a direct pointer into that storage causing
use after free.
Impact summary: A malicious QUIC server can cause a heap-use-after-free read
in the OpenSSL QUIC client. The server can also identify one allocator-adjacent
byte through the client's protected Handshake response.
CWE: CWE-416: Use After Free
Description: During CRYPTO stream processing, a pointer into the first frame's
memory on the stream is lent to the TLS handshake processing. The memory
must remain stable until it is processed and released. However the processing
of retransmitted CRYPTO frames could release the memory if the retransmitted
frame fully overlapped the existing frame. This then causes use-after-free read
when the TLS handshake processing continues.
The use-after-free read can lead to a Denial-of-Service of the client
application or a minor leak of information about the heap memory contents
that might be overwritten with other data, subsequently allocated by
the application, to the peer.
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |