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.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-45446)

Note that Nessus relies on the presence of the package as reported by the vendor.

The remote Debian 12 / 13 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-6335 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-6335-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     June 09, 2026                         https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : openssl     CVE ID         : CVE-2026-7383 CVE-2026-9076 CVE-2026-34180 CVE-2026-34181                      CVE-2026-34182 CVE-2026-34183 CVE-2026-42764 CVE-2026-42766                      CVE-2026-42767 CVE-2026-42768 CVE-2026-42769 CVE-2026-42770                      CVE-2026-45445 CVE-2026-45446 CVE-2026-45447

    Multiple vulnerabilities have been discovered in OpenSSL, a Secure     Sockets Layer toolkit, which may result in denial of service,     information leaks, or potentially remote code execution.

    Additional details can be found in the upstream advisory:
    https://openssl-library.org/news/secadv/20260609.txt

    For the oldstable distribution (bookworm), these problems have been fixed     in version 3.0.20-1~deb12u2.

    For the stable distribution (trixie), these problems have been fixed in     version 3.5.6-1~deb13u2.

    We recommend that you upgrade your openssl packages.

    For the detailed security status of openssl please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/openssl

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 3.0.21. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.0.21 advisory.

  - Issue summary: An attacker-controlled CMP (Certificate Management Protocol) server could trigger a NULL     pointer dereference in a CMP client application. Impact summary: A NULL pointer dereference causes a crash     of the application and a Denial of Service. An attacker controlling a CMP server (or acting as a man-in-     the-middle) could craft a CMP response containing a CRMF (Certificate Request Message Format)     CertRepMessage with an EncryptedValue structure where the symmAlg field has an algorithm OID but no     parameters field. When the OpenSSL CMP client processes this response, the NULL dereference occurs,     causing a crash of the CMP client. Applications that process untrusted CMP/CRMF messages may be 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. (CVE-2026-42767)

  - 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. (CVE-2026-7383)

  - 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. (CVE-2026-9076)

  - 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. (CVE-2026-45447)

  - 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. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 4.0.1. It is, therefore, affected by multiple vulnerabilities as referenced in the 4.0.1 advisory.

  - Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack     when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or     decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's     vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack     is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without     providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI)     without stopping at the first success. An attacker who authors a message with two KTRI entries  the first     one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext     obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the     application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-     chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or     forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is     provided with the recipient certificate, and the recipient is not found, a random key is substituted. An     attacker who authors a message and is able to compare both error code and the result of the decryption,     can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an     opportunity to mount an attack described in these scenarios. We consider the existence of such application     very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks,     when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit     rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit     rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the     symmetric key. This result is deterministic for the ciphertext and the private key. The length of the     decryption result can happen to match the length of the key of the symmetric cipher that was used for the     content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks     valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this     a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The     FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing     happens outside the OpenSSL FIPS module boundary. (CVE-2026-42768)

  - 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. (CVE-2026-7383)

  - 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. (CVE-2026-9076)

  - 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. (CVE-2026-45447)

  - 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. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 3.4.6. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.4.6 advisory.

  - Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack     when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or     decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's     vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack     is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without     providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI)     without stopping at the first success. An attacker who authors a message with two KTRI entries  the first     one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext     obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the     application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-     chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or     forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is     provided with the recipient certificate, and the recipient is not found, a random key is substituted. An     attacker who authors a message and is able to compare both error code and the result of the decryption,     can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an     opportunity to mount an attack described in these scenarios. We consider the existence of such application     very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks,     when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit     rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit     rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the     symmetric key. This result is deterministic for the ciphertext and the private key. The length of the     decryption result can happen to match the length of the key of the symmetric cipher that was used for the     content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks     valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this     a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The     FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing     happens outside the OpenSSL FIPS module boundary. (CVE-2026-42768)

  - 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. (CVE-2026-7383)

  - 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. (CVE-2026-9076)

  - 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. (CVE-2026-45447)

  - 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. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 3.5.7. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.5.7 advisory.

  - Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack     when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or     decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's     vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack     is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without     providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI)     without stopping at the first success. An attacker who authors a message with two KTRI entries  the first     one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext     obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the     application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-     chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or     forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is     provided with the recipient certificate, and the recipient is not found, a random key is substituted. An     attacker who authors a message and is able to compare both error code and the result of the decryption,     can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an     opportunity to mount an attack described in these scenarios. We consider the existence of such application     very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks,     when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit     rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit     rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the     symmetric key. This result is deterministic for the ciphertext and the private key. The length of the     decryption result can happen to match the length of the key of the symmetric cipher that was used for the     content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks     valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this     a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The     FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing     happens outside the OpenSSL FIPS module boundary. (CVE-2026-42768)

  - 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. (CVE-2026-7383)

  - 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. (CVE-2026-9076)

  - 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. (CVE-2026-45447)

  - 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. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The version of OpenSSL installed on the remote host is prior to 3.6.3. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.6.3 advisory.

  - Issue summary: The CMS_decrypt and PKCS7_decrypt functions are vulnerable to Bleichenbacher-style attack     when an attacker is able to provide the CMS or S/MIME messages and observe the error code and/or     decryption output. Impact summary: The Bleichenbacher-style attack allows an attacker to use the victim's     vulnerable application as a way to decrypt or sign messages with the victim's private RSA key. The attack     is possible in 2 variants. 1. The decryption API (CMS_decrypt(), PKCS7_decrypt()) is used without     providing the recipient certificate. In this case OpenSSL iterates over every KeyTransRecipientInfo (KTRI)     without stopping at the first success. An attacker who authors a message with two KTRI entries  the first     one wrapping a real CEK under the victim's public key, the second with an arbitrary probe ciphertext     obtains opportunity to iterate the 2nd KTRI to get a valid PKCS#1 v1.5 padding if the error code of the     application is available. That is a Bleichenbacher oracle (Bleichenbacher, CRYPTO '98): an adaptive-     chosen-ciphertext side channel from which the attacker decrypts any RSA ciphertext to the victim's key or     forges any PKCS#1 v1.5 signature under it. 2. When the decryption API (CMS_decrypt(), PKCS7_decrypt()) is     provided with the recipient certificate, and the recipient is not found, a random key is substituted. An     attacker who authors a message and is able to compare both error code and the result of the decryption,     can mount a Bleichenbacher oracle. We are not aware of any applications that provide a remote attacker an     opportunity to mount an attack described in these scenarios. We consider the existence of such application     very unlikely, and for this reason this CVE has been evaluated as Low severity. To avoid these attacks,     when RSA PKCS#1 v1.5 Key Transport is in use, the invoked EVP_PKEY_decrypt() will use the implicit     rejection mechanism described in draft-irtf-cfrg-rsa-guidance. In previous OpenSSL releases the implicit     rejection was explicitly disabled. The implicit rejection mechanism always returns a plaintext value, the     symmetric key. This result is deterministic for the ciphertext and the private key. The length of the     decryption result can happen to match the length of the key of the symmetric cipher that was used for the     content encryption. When a certificate is not provided, the last RecipientInfo producing a key that looks     valid will be used. It may cause getting garbage content on decryption. As a proper way to deal with this     a recipient certificate has to be provided to identify the particular RecipientInfo for decryption. The     FIPS modules in 4.0, 3.6, 3.5, and 3.4 are not affected by this issue, as CMS and S/MIME processing     happens outside the OpenSSL FIPS module boundary. (CVE-2026-42768)

  - 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. (CVE-2026-7383)

  - 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. (CVE-2026-9076)

  - 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. (CVE-2026-45447)

  - 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. (CVE-2026-45446)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
320315	Linux Distros Unpatched Vulnerability : CVE-2026-45446	Nessus	Misc.	medium
320216	Debian dsa-6335 : libcrypto3-udeb - security update	Nessus	Debian Local Security Checks	critical
320142	OpenSSL 3.0.0 < 3.0.21 Multiple Vulnerabilities	Nessus	Web Servers	critical
320140	OpenSSL 4.0.0 < 4.0.1 Multiple Vulnerabilities	Nessus	Web Servers	critical
320138	OpenSSL 3.4.0 < 3.4.6 Multiple Vulnerabilities	Nessus	Web Servers	critical
320136	OpenSSL 3.5.0 < 3.5.7 Multiple Vulnerabilities	Nessus	Web Servers	critical
320135	OpenSSL 3.6.0 < 3.6.3 Multiple Vulnerabilities	Nessus	Web Servers	critical

Detections

Analytics

CVE-2026-45446

medium

Tenable Plugins

medium

critical

critical

critical

critical

critical

critical