The version of OpenSSL installed on the remote host is prior to 1.1.1zk. It is, therefore, affected by a vulnerability as referenced in the 1.1.1zk advisory.

  - 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. Fixed in     OpenSSL 1.0.2zt (Affected since 1.0.2). (CVE-2026-107496)

Note that Nessus has not tested for this issue 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.1.1. It is, therefore, affected by multiple vulnerabilities as referenced in the 4.1.1 advisory.

  - 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. Fixed in     OpenSSL 1.1.1zk (Affected since 1.1.1). (CVE-2026-107496)

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 1.0.2zt. It is, therefore, affected by a vulnerability as referenced in the 1.0.2zt advisory.

  - 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. Fixed in     OpenSSL 1.0.2zt (Affected since 1.0.2). (CVE-2026-107496)

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

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

  - 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. Fixed in     OpenSSL 1.0.2zt (Affected since 1.0.2). (CVE-2026-107496)

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

The version of OpenSSL installed on the remote host is prior to 3.0.24. It is, therefore, affected by a vulnerability as referenced in the 3.0.24 advisory.

  - 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. Fixed in     OpenSSL 3.0.24 (Affected since 3.0.0). (CVE-2026-107496)

Note that Nessus has not tested for this issue 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.4. It is, therefore, affected by multiple vulnerabilities as referenced in the 4.0.4 advisory.

  - 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. Fixed in OpenSSL 3.5.10     (Affected since 3.5.0). (CVE-2026-95691)

  - 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. Fixed in OpenSSL 3.5.10 (Affected since 3.5.0). (CVE-2026-95692)

  - 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.0, 3.6, 3.5,     3.4, and 3.0 are not affected by this CVE as the affected protocol is not implemented in the FIPS module.
    Fixed in OpenSSL 3.5.10 (Affected since 3.5.0). (CVE-2026-88822)

  - 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. Fixed in     OpenSSL 1.0.2zt (Affected since 1.0.2). (CVE-2026-107496)

  - 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. Fixed in OpenSSL     3.5.10 (Affected since 3.5.0). (CVE-2026-88823)

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.10. It is, therefore, affected by multiple vulnerabilities as referenced in the 3.5.10 advisory.

  - 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. Fixed in OpenSSL 3.5.10     (Affected since 3.5.0). (CVE-2026-95691)

  - 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. Fixed in OpenSSL 3.5.10 (Affected since 3.5.0). (CVE-2026-95692)

  - 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.0, 3.6, 3.5,     3.4, and 3.0 are not affected by this CVE as the affected protocol is not implemented in the FIPS module.
    Fixed in OpenSSL 3.5.10 (Affected since 3.5.0). (CVE-2026-88822)

  - 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. Fixed in     OpenSSL 1.0.2zt (Affected since 1.0.2). (CVE-2026-107496)

  - 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. Fixed in OpenSSL     3.5.10 (Affected since 3.5.0). (CVE-2026-88823)

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	Published	Updated	Severity
378067	OpenSSL 1.1.1 < 1.1.1zk Vulnerability	Nessus	Web Servers	11/10/2026	11/10/2026	high
378065	OpenSSL 4.1.0 < 4.1.1 Multiple Vulnerabilities	Nessus	Web Servers	11/10/2026	11/10/2026	high
378069	OpenSSL 1.0.2 < 1.0.2zt Vulnerability	Nessus	Web Servers	11/10/2026	11/10/2026	high
378220	Linux Distros Unpatched Vulnerability : CVE-2026-107496	Nessus	Misc.	11/10/2026	11/10/2026	critical
378066	OpenSSL 3.0.0 < 3.0.24 Vulnerability	Nessus	Web Servers	11/10/2026	11/10/2026	medium
378068	OpenSSL 4.0.0 < 4.0.4 Multiple Vulnerabilities	Nessus	Web Servers	11/10/2026	11/10/2026	high
378070	OpenSSL 3.5.0 < 3.5.10 Multiple Vulnerabilities	Nessus	Web Servers	11/10/2026	11/10/2026	high

Detections

Analytics

Plugins Search

high

high

high

critical

medium

high

high