OpenSSL: 5 Low fixes merged, QUIC, AES-GCM-SIV and CMS

[Norbert Pócs <norbertp () openssl org>]

OpenSSL Security Advisory [10th November 2026]
==============================================

The issues listed below have been fixed in the public openssl/openssl
repository on GitHub. Releases containing these fixes are scheduled
for 1st December 2026.

QUIC Uses Uninitialized Stack Bytes During Automated Peer Detection
(CVE-2026-88822)
====================================================================================

Severity: Low

Issue summary: QUIC, when performing automated peer detection, may allow
uninitialized stack data to leak into the received address which is then
used
as the destination for outgoing packets.

Impact summary: Applications using QUIC's automated peer detection mechanism
may receive an invalid address, leading to connection loss and disclosure of
uninitialized stack data to an attacker observing the outgoing network
traffic.

CWE: CWE-457 (Use of Uninitialized Variable)

Description: The OpenSSL QUIC stack contains a feature in which, when using
an
already connected socket, it will auto-detect the peer address during the
SSL
handshake.  This feature uses the getpeername() function, passing a buffer
of
sufficient length to hold any supported address family, but passes a buffer
length that is only sized such that larger addresses, such as IPv6, cannot
be
retrieved. The getpeername() function however, still returns the full
address
length, which is accepted as the valid input buffer length, leading to the
address buffer containing uninitialized stack data instead of the actual
peer
address. The invalid peer address is then used as destination for the
outgoing
packets which leads to a connectivity breakage and a leakage of the
uninitialized stack data to passive network observers.

FIPS impact: no
The FIPS modules in 4.1, 4.0, 3.5, and 3.0 are not affected by this CVE as
the affected protocol is not implemented in the FIPS module.

OpenSSL 4.1, 4.0, and 3.5 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 4.1 users should upgrade to OpenSSL 4.1.1
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.10.

This issue was reported on 28 August 2026 by Jaehun Lee.
The fix has been developed by Neil Horman.

AES-GCM-SIV AAD Forgery After Zero-length Incremental AAD Update
(CVE-2026-88823)
=================================================================================

Severity: Low

Issue summary: The AES-GCM-SIV implementation treats a zero-length
Additional
Authenticated Data (AAD) update as a reset of all the AAD supplied so far,
instead of leaving the AAD unchanged. An application that supplies its AAD
in
several fragments, one of which is empty, therefore produces or verifies
messages whose authentication tag does not cover the AAD supplied before
the empty fragment.

Impact summary: Data an application intended to authenticate alongside a
message is silently left unauthenticated. An attacker can forge the AAD of
such
a message.

CWE: CWE-325: Missing Cryptographic Step

Description: An application passing AAD in multiple chunks of which some
have
zero length will have the previous AAD chunks effectively unauthenticated.
Also,
on context re-initialisation, the AAD was not reset, which meant that any
AAD
accumulated from the previous context usage were also included in the AAD
of the
new message.

The fix makes a zero-length AAD update a no-op and clears any accumulated
AAD
whenever the context is re-initialised with a key or a nonce.
A re-initialisation that only changes parameters keeps the AAD.

FIPS impact: no
The FIPS modules are not affected, as AES-GCM-SIV is not a FIPS approved
algorithm and is implemented only in the default provider, outside the
OpenSSL FIPS module boundary.

OpenSSL 4.1, 4.0, and 3.5 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 4.1 users should upgrade to OpenSSL 4.1.1
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.4
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.10

This issue was reported on 23 July 2026 by Jérémy Jean (ANSSI), on
6 September 2026 by Bhargava Shastry and on 25 September 2026
by Jonathan Bateman (Rochester Institute of Technology).
The fix has been developed by Daniel Kubec.

Retransmitted QUIC CRYPTO Frames Can Cause DoS or One-byte Disclosure
(CVE-2026-95691)
======================================================================================

Severity: Low

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.

OpenSSL 4.1, 4.0 and 3.5 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 4.1 users should upgrade to OpenSSL 4.1.1
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.4
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.10

This issue was reported on 11 Sep 2026 by Filipe Casal (Trail of Bits).
The fix has been developed by Filipe Casal (Trail of Bits).

Out-of-Bounds Read and Incorrect IV Length Handling in AES-GCM-SIV
(CVE-2026-95692)
===================================================================================

Severity: Low

Issue summary: Setting an AES-GCM-SIV IV shorter than the expected nonce
length via EVP_CipherInit_ex() may trigger a heap out-of-bounds read.
Supplying a longer IV is silently truncated instead of rejected.

Impact summary: An application passing a caller-supplied IV of the wrong
length may crash or read beyond its buffer. Because trailing IV bytes are
ignored, an attacker who knows one message and tag may forge messages under
a
different IV.

CWE: CWE-125: Out-of-bounds Read

Description: AES-GCM-SIV copies the caller-supplied IV or nonce into its
internal state using a copy whose length is taken from the expected nonce
size
rather than from the length the caller actually provided. When the caller
passes a shorter IV, the copy reads past the end of the caller's buffer;
AddressSanitizer confirms a heap out-of-bounds read reached through
EVP_CipherInit_ex() into ossl_aes_gcm_siv_init(). When the caller passes a
longer IV, the implementation silently discards the trailing bytes instead
of
rejecting the length.

The truncation breaks the binding between the IV and the computed
authentication tag. An attacker who has observed a message and its tag under
one IV can produce a message and tag that verify under a different IV whose
first bytes match, since the surplus bytes never influence the computation.
The message itself is unchanged, so this is a failure of IV commitment
rather
than a classic existential forgery.

Only applications that call EVP_CipherInit_ex() (or the equivalent provider
cipher initialization) with an IV length other than the standard 12 bytes
for
AES-GCM-SIV are affected. The severity is limited because the out-of-bounds
read is small and attacker-controlled only in length, and the forgery
requires
an unusual IV length choice by the application.

FIPS impact: no
The FIPS modules are not affected by this issue, as AES-GCM-SIV is not an
approved algorithm.

OpenSSL 4.1, 4.0, and 3.5 are vulnerable to this issue.

OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.

OpenSSL 4.1 users should upgrade to OpenSSL 4.1.1.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.10.

This issue was reported on 19 September 2026 by Billy Brumley (Rochester
Institute of Technology).
The fix has been developed by Billy Brumley (Rochester
Institute of Technology).

Infinite Loop in CMS_encrypt() With an EC Group Order of 1 (CVE-2026-107496)
============================================================================

Severity: Low

Issue summary: Encrypting a CMS message to an EC certificate whose group
order
is 1 may cause CMS_encrypt() or CMS_encrypt_ex() to loop indefinitely.

Impact summary: An attacker able to supply the recipient certificate to an
application performing CMS encryption can cause that application to loop
indefinitely, consuming CPU and resulting in Denial of Service.

CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')

Description: CMS_encrypt() and CMS_encrypt_ex() encrypt a message to one or
more recipient certificates and, for an EC recipient, generate an ephemeral
key in the recipient's group. If the certificate declares a group order of
1,
random scalar generation can only produce zero. The key generation routine
then retries without limit while waiting for a nonzero private scalar, so
the
call never returns.

The OpenSSL TLS and QUIC implementations do not use this path. An
application
is exposed only if it calls CMS_encrypt() or CMS_encrypt_ex() with a
recipient
certificate whose EC parameters are attacker-controlled. Certificates with
normal EC group orders do not trigger the loop.

OpenSSL 4.0 and later reject unknown explicit EC groups in default builds.
These versions are affected only when configured with the
enable-ec_explicit_curves option.

The result is a hang that consumes a CPU core until the process is
interrupted, a Denial of Service. The severity is Low because the attacker
must supply the recipient certificate and the application must choose to
encrypt to it; ordinary CMS encryption to trusted recipients is unaffected.

The fix makes EC key generation fail when the group has no valid nonzero
private scalar, instead of retrying indefinitely.

FIPS impact: no
The FIPS modules in 4.1, 4.0, 3.5 and 3.0 are not affected. The FIPS
provider
does not support arbitrary explicit EC domain parameters, so an order-1
group
is rejected during key import before the vulnerable key generation path is
reached.

OpenSSL 4.1, 4.0, 3.5, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

OpenSSL 4.1 users should upgrade to OpenSSL 4.1.1.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.10.

Premium support customers only:
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.24.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zk.
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zt.

This issue was reported on 8 October 2026 by Yinxi Liu.
The fix has been developed by Jakub Zelenka.

General Advisory Notes
======================

URL for this Security Advisory:
https://openssl-library.org/news/secadv/20261110.txt

Note: the online version of the advisory may be updated with additional
details over time.

Only currently supported releases have been analysed. OpenSSL 3.1, 3.2, 3.3,
3.4, and 3.6 are out of support and have not been analysed.

For details of OpenSSL severity classifications please see:
https://openssl-library.org/policies/general/security-policy/

--
Norbert