Openssl: >> Openssl >> 3.0.0 Security Vulnerabilities
Issue summary: ChaCha20-Poly1305 and AES-OCB decryption with an empty
ciphertext can report success without verifying the supplied authentication
tag when the operation is finalized by calling the EVP_Cipher() function.
Impact summary: Applications calling EVP_Cipher() on an empty ciphertext and
expecting the call to check the AEAD tag may accept forged messages.
CWE: CWE-354 (Improper Validation of Integrity Check Value)
Description: The EVP_Cipher() API call for AEAD ciphers behaves like a one
shot encryption and decryption call. It also verifies the AEAD tag after the
decryption operation. However for AES-OCB and ChaCha20-Poly1305 ciphers
it skipped the AEAD tag verification when an empty ciphertext was passed to
the function. The callers of this function might believe that a successful
return indicates a valid AEAD tag for these ciphers, even when that has not
truly been validated in this case.
FIPS impact: no
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this CVE
as the affected algorithms are not FIPS approved and thus not implemented
in the FIPS module.
CVSS Score
9.1
EPSS Score
0.002
Published
2026-08-25
Issue summary: OpenSSL CMS decryption sizes the key-unwrap output buffer based
on querying the unwrapped key size, but the AES-WRAP-PAD unwrap primitive
can write and cleanse more bytes than that query reports, causing an 8-byte
out-of-bounds heap write.
Impact summary: An attacker who supplies a crafted CMS message can trigger a
deterministic 8-byte out-of-bounds heap write when the victim decrypts it
with CMS_decrypt(), corrupting the heap and typically resulting in a Denial
of Service.
CWE: CWE-787: Out-of-bounds Write
Description: The key-wrap OID is potentially attacker-controlled on the wire.
CMS unwrapping allows both id-aesNNN-wrap-pad and id-aesNNN-wrap ciphers.
An attacker can take a legitimate message and change a single OID byte to
select the padded variant while leaving the message otherwise valid. Since
the unwrap key is derived from the recipient's private operation (ECDH key
agreement or ML-KEM decapsulation), the RFC 5649 integrity check cannot
pass, and the decryption fails with integrity failure.
The write is a fixed-size (8-byte), fixed-value (zero) heap overflow
immediately past the allocation, requires no special configuration, and is
reachable from the public CMS_decrypt() function. The consequence is
a heap corruption leading to a Denial of Service. The fix in the CMS code
sizes the unwrap output buffer for the worst case so a failed unwrap cannot
write past the allocation.
FIPS impact: no
As the CMS code lives outside the FIPS module boundary, no FIPS
modules are affected by this CVE.
CVSS Score
7.5
EPSS Score
0.006
Published
2026-08-25
Issue summary: The OpenSSL Certificate Management Protocol (CMP) caches
additional certificates (extraCerts) sent in a CMP message, but never expunges
them (for instance if they are invalid). If a server reuses an OSSL_CMP_CTX
frequently, this cache of extraCerts may grow unboundedly, and a malicious
client may flood a CMP server with requests driving this growth.
Impact summary: Users utilizing a CMP server that reuses a single OSSL_CMP_CTX
for the lifetime of a server process may observe unbounded memory growth in the
event a malicious client repeatedly sends requests containing unique extra
certificates, which may lead to OOM conditions.
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: If a remote user sends CMP messages to a server with a list of
extraCerts and the message is rejected, the extraCerts from the message remains
in the server contexts untrusted certificate stack. This exposes servers with
long lived ctx objects to Denial of Service attacks in which an attacker sends
messages intending to be rejected with a large list of additional certificates
repeatedly, forcing the server to store them indefinitely.
The issue was fixed by removing the added extra certs if the message is
rejected, using the same method as when the context is configured to not do
caching at all.
FIPS impact: no
As the CMP code lives outside the FIPS module boundary, no FIPS
modules are affected by this CVE.
CVSS Score
5.9
EPSS Score
0.005
Published
2026-08-25
Issue summary: OpenSSL CMP password based protection verification only
checks whether the protectionAlg parameter was not NULL and not its
ASN.1 type, before treating it as a PBMParameter. A crafted message can
contain a parameter of a different type, which is then dereferenced as an
invalid pointer.
Impact summary: A remote, unauthenticated attacker can crash an application
acting as a CMP server that accepts PBM-protected messages, or a CMP client
talking to a malicious or intercepted CMP server, resulting in a Denial of
Service.
CWE: CWE-476: NULL Pointer Dereference
Description: When verifying the password-based MAC protection of a CMP
message, OpenSSL library reads the protectionAlg algorithm parameter with
X509_ALGOR_get0(), which returns both the parameter type and its value
pointer. The value is then cast to an ASN1_STRING and treated as the
expected PBMParameter after only checking that pointer is not NULL. The
parameter type returned by X509_ALGOR_get0() was never consulted.
This happens during protection verification, before any MAC is computed, so
no knowledge of the PBM shared secret is required; the only precondition is
that PBM verification is reachable. On the server side this is reached from
OSSL_CMP_SRV_process_request() for any application that stands up a CMP
server accepting PBM-protected messages, and on the client side from CMP
response validation against a malicious or on-path (MITM) server. The
reliable consequence is a denial of service; there is no memory disclosure,
no controlled memory write, and no path to code execution. CMP is a
specialized feature that an application must explicitly enable.
FIPS impact: no
As the CMP code lives outside the FIPS module boundary, no FIPS modules
are affected by this CVE.
CVSS Score
7.5
EPSS Score
0.013
Published
2026-08-25
Issue summary: Receiving a DTLS record for a future epoch while a handshake
is in progress causes OpenSSL to buffer far more memory than the record
itself requires.
Impact summary: A peer can use a small amount of network traffic to make an
OpenSSL DTLS endpoint retain a disproportionately large amount of memory,
which may lead to a Denial of Service.
CWE: CWE-405: Asymmetric Resource Consumption (Amplification)
Description: While a DTLS handshake is in progress, a peer may legitimately
have already moved on to the next epoch (for example, having sent its
ChangeCipherSpec and Finished messages) before the local endpoint has
processed the same transition, typically because of reordering on the
underlying UDP transport. OpenSSL buffers such early records so that they
can be processed once the local endpoint catches up.
Buffering a record currently retains the entire read buffer it arrived in,
which is sized to hold the largest possible DTLS record (around 16
kilobytes), rather than just the bytes that make up the record itself. Up
to 100 such records may be buffered per connection. As a result, a peer
that sends a stream of small forged records claiming to belong to the next
epoch can cause an OpenSSL DTLS endpoint to retain around 1.7 megabytes of
memory, despite sending only a small fraction of that amount of data over
the network.
An attacker therefore gains a memory amplification factor of around 1200,
and can multiply the effect across as many associations as it is able to
open, making this a remote memory exhaustion Denial of Service risk for
DTLS servers. Since the memory retained per connection remains bounded,
and any limit an application already places on the number of concurrent
associations also bounds the total exposure, this issue has been assessed
as Low severity.
FIPS impact: no
No FIPS modules are affected by this issue as the affected code is outside
the OpenSSL FIPS module boundary.
OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to this
issue.
OpenSSL 4.0 users should upgrade to OpenSSL 4.0.2.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.4.
OpenSSL 3.5 users should upgrade to OpenSSL 3.5.8.
OpenSSL 3.4 users should upgrade to OpenSSL 3.4.7.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.22.
Premium support customers only:
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zi
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zr
This issue was reported on 18 May 2026 by Amazon Web Services.
The fix has been developed by Matt Caswell.
-- cut (non-publishing metadata for internal use) --
Reported by: Amazon Web Services
Fixed by: Matt Caswell
CVSS Score
7.5
EPSS Score
0.005
Published
2026-08-25
Issue summary: A signed integer overflow when sizing the destination
buffer for Unicode output in ASN1_mbstring_ncopy() can lead to a heap
buffer overflow.
Impact summary: A heap buffer overflow may lead to a crash or possibly
attacker controlled code execution or other undefined behaviour.
In ASN1_mbstring_copy() and ASN1_mbstring_ncopy() the destination
size for Unicode output is computed in a signed int: by left shift
of the input character count for BMPSTRING (UTF-16) and
UNIVERSALSTRING (UTF-32), and by summing per-character byte counts
for UTF8STRING. The calculation overflows when the input reaches
around 2^30 characters. In the worst case (UNIVERSALSTRING at 2^30
characters) the size wraps to zero, OPENSSL_malloc(1) is called, and
the subsequent character copy writes several gigabytes past the
one-byte allocation.
X.509 certificate processing routes through ASN1_STRING_set_by_NID(),
whose DIRSTRING_TYPE mask excludes UNIVERSALSTRING and whose per-NID
size limits cap the input length; no network protocol or
certificate-handling path in OpenSSL exercises the overflow.
Triggering the bug requires an application that calls
ASN1_mbstring_copy() or ASN1_mbstring_ncopy() directly, or registers
a custom string type via ASN1_STRING_TABLE_add(), with
attacker-controlled input on the order of half a gigabyte or more.
For these reasons this issue was assigned Low severity.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as the affected code is outside the OpenSSL FIPS module
boundary.
CVSS Score
8.1
EPSS Score
0.008
Published
2026-06-09
Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap)
processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK
cipher can trigger a heap out-of-bounds read in kek_unwrap_key().
Impact summary: A heap buffer over-read may trigger a crash which leads to
Denial of Service for an application if the input buffer ends at a memory
page boundary and the following page is unmapped. There is no information
disclosure as the over-read bytes are not revealed to the attacker.
The key unwrapping function performs a check-byte test as specified in the
RFC that reads 7 bytes from a heap allocation that is based on the wrapped
key length from the message. There is a minimum length check based on the
block length of the wrapping cipher. However the cipher is selected from
an OID carried in the attacker's PWRI keyEncryptionAlgorithm with no
requirement that the cipher be a block cipher. When an attacker selects
a stream-mode cipher the guard will be ineffective and the allocated buffer
containing the unwrapped key can be too small to fit the check-bytes
specified in the RFC and a buffer over-read can happen.
Applications calling CMS_decrypt() or CMS_decrypt_set1_password()
(equivalently openssl cms -decrypt -pwri_password ...) on untrusted CMS
data are vulnerable to this issue. No password knowledge is required: the
over-read happens during the unwrap attempt before any authentication
succeeds.
The over-read is limited to a few bytes and is not written to output, so
there is no information disclosure. Triggering a crash requires the
allocation to border unmapped memory, which is unlikely with the normal
allocator.
The FIPS modules are not affected by this issue.
CVSS Score
7.5
EPSS Score
0.007
Published
2026-06-09
Issue summary: The implementations of AES-SIV (RFC 5297) and AES-GCM-SIV
(RFC 8452) mishandle the authentication of AAD (Additional Authenticated
Data) with an empty ciphertext allowing a forgery of such messages.
Impact summary: An attacker can forge empty messages with arbitrary AAD
to the victim's application using these ciphers.
AES-SIV (RFC 5297) and AES-GCM-SIV (RFC 8452) are nonce-misuse-resistant AEAD
modes: they accept a key, nonce, optional AAD (bytes that are authenticated
but not encrypted), and plaintext, and produces ciphertext plus a 16-byte
tag. On decrypt, `EVP_DecryptFinal_ex()` is documented to return success only
if the tag is verified succesfully.
In OpenSSL's provider implementation of these ciphers, the expected tag is
computed only when decryption function is invoked with non-empty data.
If the caller supplies AAD and then calls `EVP_DecryptFinal_ex()` without
invocation of the ciphertext update, which can happen when the received
ciphertext length is zero, the tag is never recalculated and still holds its
all-zeros value.
When AES-GCM-SIV is used, an attacker who sends arbitrary AAD, empty
ciphertext, and all-zeros tag passes authentication under any key they do not
know, single-shot. When AES-SIV is used, for mounting the attack it's
necessary for the application to reuse the decryption context without
resetting the key.
AES-SIV is implemented since OpenSSL 3.0. AES-GCM-SIV is implemented since
OpenSSL 3.2.
No protocols implemented in OpenSSL itself (TLS/CMS/PKCS7/HPKE/QUIC) support
either AES-GCM-SIV or AES-SIV. To mount an attack, the applications must
implement their own protocol and use the EVP interface. Also they must skip the
ciphertext update when a message with an empty ciphertext arrives.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as these algorithms are not FIPS approved and the affected code is
outside the OpenSSL FIPS module boundary.
CVSS Score
4.8
EPSS Score
0.004
Published
2026-06-09
Issue summary: A specially crafted PKCS#7 or S/MIME signed message could
trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap
corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData
digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may
incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent
use of the BIO by the calling application results in a use-after-free
condition.
In the common case this occurs when the application later calls
BIO_free() on the BIO originally passed to PKCS7_verify(). Depending
on allocator behavior and application-specific BIO usage patterns, this
may result in a crash or other memory corruption. In some application
contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL
PKCS#7 APIs may be affected. Applications using the CMS APIs for this
processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this
issue, as the affected code is outside the OpenSSL FIPS module boundary.
CVSS Score
8.8
EPSS Score
0.036
Published
2026-06-09
Issue summary: When an application drives an AES-OCB context through the
public EVP_Cipher() one-shot interface, the application-supplied
initialisation vector (IV) is silently discarded.
Impact summary: Every message encrypted under the same key uses the
same effective nonce regardless of the IV supplied by the caller,
resulting in (key, nonce) reuse and loss of confidentiality. If the
same code path is used to compute the authentication tag, the tag
depends only on the (key, IV) pair and not on the plaintext or
ciphertext, allowing universal forgery of arbitrary ciphertext from a
single captured message.
OpenSSL provides two ways to drive a cipher: the documented streaming
interface (EVP_CipherUpdate / EVP_CipherFinal_ex) and a lower-level
one-shot, EVP_Cipher(), whose documentation explicitly recommends
against use by applications in favour of EVP_CipherUpdate() and
EVP_CipherFinal_ex(). The OCB provider's streaming handler flushes
the application-supplied IV into the OCB context before processing
data; the one-shot handler did not. Every call to EVP_Cipher() on an
AES-OCB context therefore ran with the all-zero key-derived offset
state left by cipher initialisation, regardless of the caller's IV.
If EVP_EncryptFinal_ex() is subsequently used to obtain the
authentication tag, the deferred IV setup runs at that point and
clears the running checksum that should have been accumulated over the
plaintext. The resulting tag is a function of (key, IV) only and
verifies against any ciphertext produced under the same (key, IV)
pair.
The OpenSSL SSL/TLS implementation is not affected: AES-OCB is not a
TLS cipher suite, and libssl does not call EVP_Cipher() in any case.
Applications that drive AES-OCB through the documented streaming AEAD
API (EVP_CipherUpdate / EVP_CipherFinal_ex) are not affected. Only
applications that combine the AES-OCB cipher with the EVP_Cipher()
one-shot API are vulnerable.
The FIPS modules in 4.0, 3.6, 3.5, 3.4 and 3.0 are not affected by
this issue, as AES-OCB is outside the OpenSSL FIPS module boundary.
CVSS Score
7.5
EPSS Score
0.006
Published
2026-06-09
Page 1