The remote Ubuntu 22.04 LTS / 24.04 LTS / 26.04 LTS host has packages installed that are affected by multiple vulnerabilities as referenced in the USN-8847-1 advisory.

    It was discovered that OpenSSL incorrectly handled certain certificate revocation list distribution point     names. An attacker could possibly use this issue to cause OpenSSL to consume excessive memory, resulting     in a denial of service. (CVE-2026-35189)

    It was discovered that OpenSSL incorrectly handled QUIC unvalidated amplification credit accounting. An     attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 26.04     LTS. (CVE-2026-35191)

    It was discovered that OpenSSL incorrectly implemented scalar multiplication for non-NIST elliptic curves.
    An attacker could possibly use this issue to perform a timing side-channel attack and obtain sensitive     information. (CVE-2026-54872)

    It was discovered that OpenSSL incorrectly implemented SM2 scalar multiplication on ARM64 and RISC-V     architectures. An attacker could possibly use this issue to perform a timing side-channel attack and     obtain sensitive information. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-54875)

    It was discovered that OpenSSL incorrectly handled SSL context switching during a TLS handshake. An     attacker could possibly use this issue to cause an out-of-bounds read, resulting in a denial of service or     obtaining sensitive information. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-72897)

    It was discovered that OpenSSL incorrectly enforced QUIC connection- level flow control for streams. An     attacker could possibly use this issue to cause OpenSSL to consume excessive memory, resulting in a denial     of service. This issue only affected Ubuntu 26.04 LTS. (CVE-2026-75804)

    It was discovered that OpenSSL incorrectly handled a NULL pointer in CMP client revocation response     processing. An attacker could possibly use this issue to cause a denial of service. (CVE-2026-75805)

    It was discovered that OpenSSL incorrectly handled undersized DTLS 1.2 AEAD records before authentication.
    An attacker could possibly use this issue to cause a denial of service. (CVE-2026-75806)

    It was discovered that OpenSSL incorrectly implemented SM2 signature generation. An attacker could     possibly use this issue to perform a timing side-channel attack and obtain sensitive information.
    (CVE-2026-77696)

    It was discovered that OpenSSL incorrectly handled DTLS retransmission of handshake messages. An attacker     could possibly use this issue to cause incorrect handshake behavior or a denial of service.
    (CVE-2026-84782)

    It was discovered that OpenSSL incorrectly handled QUIC RETIRE_CONNECTION_ID frames. An attacker could     possibly use this issue to cause OpenSSL to consume excessive memory, resulting in a denial of service.
    This issue only affected Ubuntu 26.04 LTS. (CVE-2026-84784)

Tenable has extracted the preceding description block directly from the Ubuntu 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 Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1793092125 advisory.

  - Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes     disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted     certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service     in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without     Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for     size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of     resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the     client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix     postpones processing of the CRL distribution points extensions in certificates to the time when the     processed value is required for CRL processing. This avoids keeping large memory allocations for a long     time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module     boundary. (CVE-2026-35189)

  - Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX     part way through a handshake may access memory beyond the end of an internal array if the replacement     context knows about more provider signature algorithms than the context the connection was created from.
    Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be     able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on     the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A     TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that     created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context     was aware of. That count sizes an internal array of per-slot certificate validity flags. An application     may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most     commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh     the recorded count. A provider signature algorithm's slot index is its position in the list of whichever     context resolves it, so if the replacement context is aware of more of them than the original, an     algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's     signature algorithms then reads one four byte word past the end for each such algorithm and, where the     word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata     and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which     the server also has configured, have this effect. Codepoints the replacement context does not recognise     are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS     1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which     requires separate library contexts, a provider loaded between the two being created, or providers which     differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS     provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms     with legitimate clients, since the same stale count hides the corresponding certificates, so the     misconfiguration is likely to be noticed. For that reason, and because the configuration is not the     default, 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. (CVE-2026-72897)

  - Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers     may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious     remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive     ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of     Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control     limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer     must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream     frame, it validates that the size of the received stream frame stays within flow control limits. If either     limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a     flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-     level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams -     each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent     on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the     conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control     limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and     unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The     remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no     The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.
    (CVE-2026-75804)

  - Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is     suspended part-way through. The retransmitted message can be read past the message buffer and the     retransmission overwrites the internal state the suspended write needs to resume correctly. Impact     summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or     cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-     of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write     can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more     data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the     retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.
    The retransmission logic reused the same internal buffer and position tracking as the message that was     still being written, without resetting the position back to the start of the message being retransmitted.
    As a result the retransmission was read starting from wherever the suspended write had left off, producing     a mislabelled message whose body was leftover bytes from the other, larger message still in flight -     content that was never meant to be sent at that point, and which could run past the end of the allocated     buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion     while another write is suspended overwrites the same shared bookkeeping that the suspended write depends     on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(),     SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with     the message and aborts the process in a debugging build. The fix resets the retransmission's read position     to the start of the message before resending, and skips retransmission entirely whenever a handshake write     is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code     is outside the FIPS module boundary. (CVE-2026-84782)

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

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1793092125 advisory.

  - Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes     disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted     certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service     in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without     Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for     size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of     resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the     client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix     postpones processing of the CRL distribution points extensions in certificates to the time when the     processed value is required for CRL processing. This avoids keeping large memory allocations for a long     time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module     boundary. (CVE-2026-35189)

  - Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX     part way through a handshake may access memory beyond the end of an internal array if the replacement     context knows about more provider signature algorithms than the context the connection was created from.
    Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be     able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on     the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A     TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that     created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context     was aware of. That count sizes an internal array of per-slot certificate validity flags. An application     may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most     commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh     the recorded count. A provider signature algorithm's slot index is its position in the list of whichever     context resolves it, so if the replacement context is aware of more of them than the original, an     algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's     signature algorithms then reads one four byte word past the end for each such algorithm and, where the     word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata     and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which     the server also has configured, have this effect. Codepoints the replacement context does not recognise     are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS     1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which     requires separate library contexts, a provider loaded between the two being created, or providers which     differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS     provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms     with legitimate clients, since the same stale count hides the corresponding certificates, so the     misconfiguration is likely to be noticed. For that reason, and because the configuration is not the     default, 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. (CVE-2026-72897)

  - Issue summary: OpenSSL QUIC stack does not enforce connection level flow control for streams. Remote peers     may send more bytes as long as they fit within the stream flow control limits. Impact summary: A malicious     remote peer may exploit the lack of connection flow control for streams to make the QUIC stack receive     ~100MB of memory instead of 768 KiB (default flow control window size). CWE: CWE-770: Allocation of     Resources Without Limits or Throttling Description: The local QUIC stack advertises two flow control     limits to its remote peer: stream flow control limit and connection flow control limit. The remote peer     must follow both limits when transmitting stream data. Whenever the local QUIC stack receives a stream     frame, it validates that the size of the received stream frame stays within flow control limits. If either     limit is exceeded (stream level or connection level), then the QUIC stack must close the connection with a     flow control error. The vulnerable OpenSSL QUIC stack enforces the stream-level but not the connection-     level limit. To exploit the issue, three conditions must be met: - the remote peer opens several streams -     each stream must stay within the stream-level flow control limit - there must be no zero-offset byte sent     on any of the streams (to prevent the vulnerable QUIC stack from consuming data). By meeting the     conditions above, the remote peer may make the local stack allocate 2 x MAX_STREAMS x (stream flow control     limit) bytes of memory. MAX_STREAMS defaults to 100, and the limit applies to both bidirectional and     unidirectional streams, making it 200 in total. The default flow control window for a stream is 512kB. The     remote peer may force the vulnerable QUIC stack to allocate 100MB of heap per connection. FIPS impact: no     The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.
    (CVE-2026-75804)

  - Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is     suspended part-way through. The retransmitted message can be read past the message buffer and the     retransmission overwrites the internal state the suspended write needs to resume correctly. Impact     summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or     cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-     of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write     can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more     data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the     retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.
    The retransmission logic reused the same internal buffer and position tracking as the message that was     still being written, without resetting the position back to the start of the message being retransmitted.
    As a result the retransmission was read starting from wherever the suspended write had left off, producing     a mislabelled message whose body was leftover bytes from the other, larger message still in flight -     content that was never meant to be sent at that point, and which could run past the end of the allocated     buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion     while another write is suspended overwrites the same shared bookkeeping that the suspended write depends     on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(),     SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with     the message and aborts the process in a debugging build. The fix resets the retransmission's read position     to the start of the message before resending, and skips retransmission entirely whenever a handshake write     is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code     is outside the FIPS module boundary. (CVE-2026-84782)

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

  - Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is     suspended part-way through. The retransmitted message can be read past the message buffer and the     retransmission overwrites the internal state the suspended write needs to resume correctly. Impact     summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or     cause a crash and a Denial of Service when the read reaches an unmapped memory region. CWE: CWE-125: Out-     of-bounds Read Description: DTLS handshake messages can be written out in multiple fragments, and a write     can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more     data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the     retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.
    The retransmission logic reused the same internal buffer and position tracking as the message that was     still being written, without resetting the position back to the start of the message being retransmitted.
    As a result the retransmission was read starting from wherever the suspended write had left off, producing     a mislabelled message whose body was leftover bytes from the other, larger message still in flight -     content that was never meant to be sent at that point, and which could run past the end of the allocated     buffer. Separately, even when the retransmission is positioned correctly, allowing it to run to completion     while another write is suspended overwrites the same shared bookkeeping that the suspended write depends     on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(),     SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with     the message and aborts the process in a debugging build. The fix resets the retransmission's read position     to the start of the message before resending, and skips retransmission entirely whenever a handshake write     is still suspended, deferring to the next call that resumes it instead. FIPS impact: no The affected code     is outside the FIPS module boundary. (CVE-2026-84782)

  - Issue summary: A certificate with many nameRelativeToCRLIssuer CRL distribution points causes     disproportionate heap growth when OpenSSL caches X.509 extensions. Impact summary: Receiving a crafted     certificate from a malicious peer can lead to significant memory pressure and possible Denial of Service     in clients or in servers that solicit client certificates. CWE: CWE-770: Allocation of Resources Without     Limits or Throttling Description: A certificate or a set of certificates that fits under the limit for     size of certificates accepted from the peer (~100 KiB) can result in allocation of several hundred MiB of     resident memory on the receiving side during a normal TLS handshake. This may be enough to crash the     client or server, if multiple concurrent connections lead to similarly large memory allocations. The fix     postpones processing of the CRL distribution points extensions in certificates to the time when the     processed value is required for CRL processing. This avoids keeping large memory allocations for a long     time when such certificates are received. FIPS impact: no The affected code is outside the FIPS module     boundary. (CVE-2026-35189)

  - Issue summary: The OpenSSL QUIC server, when configured to not preform address validation, can be forced     to count incoming packets multiple times in its unvalidated credit computation, leading to a violation of     the RFC 9000 unvalidated connection amplification limit of 3 times the amount of data received. Impact     summary: A remote attacker able to spoof packets to a server using the OpenSSL QUIC implementation might     use the server for an amplification of a DDoS attack. CWE: CWE-440: Expected Behavior Violation     Description: OpenSSL's QUIC stack, when operating as a server, enforces client address validation (RFC     9000, Section 8), to confirm the peer address is not used for a traffic amplification attack. If this     feature is disabled on the server, the QUIC stack limits the amount of server data that can be sent to 3     times the amount of data received from the peer address, until such time as the TLS handshake is     completed. The OpenSSL QUIC server, when operating in non-validation mode, adds the length of the whole     datagram received to the unvalidated credit limit when processing each QUIC packet in the datagram. A     remote peer may, after establishing a connection with an initial client hello frame, send a subsequent     datagram containing multiple QUIC packets, leading the server to account the entire datagram length for     each packet in the datagram, resulting in the server believing that the peer has sent more data than it     actually has, thereby violating the 3x amplification limit mandated by the RFC. FIPS impact: no As the     QUIC stack lives outside the FIPS module boundary, no FIPS modules are affected by this CVE.
    (CVE-2026-35191)

  - Issue summary: The QUIC stream reassembly algorithm performance deteriorates progressively as packets are     arriving out of order. The worst case has a quadratic complexity proportional to the number of stream     frames kept in the buffer for the received stream data. Impact summary: A remote QUIC peer that completes     the handshake can create a connection-scoped CPU pressure and potentially a Denial of Service using     compliant STREAM frames inside the advertised receive window, with low attacker bandwidth. CWE: CWE-407:
    Inefficient Algorithmic Complexity Description: OpenSSL manages received QUIC stream fragments using a     doubly-linked list. While it optimizes for append operations (at the end of the list), it falls back to a     head-to-tail linear search for any fragment that does not immediately follow the current `tail`. By     manipulating the sequence of offsets, an attacker can force the server to perform O(n^2) operations,     consuming excessive CPU time for the QUIC process. FIPS impact: no The FIPS module is not affected as the     QUIC implementation is outside of the OpenSSL FIPS module boundary. (CVE-2026-42772)

  - Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature     operations with curves that do not have a dedicated implementation leaks information about the secret     nonce through timing. Impact summary: An attacker able to measure signing times may learn information     about the per-signature secret nonce, which over many signatures can, via a lattice / Hidden Number     Problem attack, lead to recovery of the private key. CWE: CWE-208: Observable Timing Discrepancy     Description: The generic elliptic-curve scalar multiplication used for curves that do not have a dedicated     constant-time implementation pads the secret scalar with non-constant-time BIGNUM operations, so the time     taken depends on the value of the secret scalar derived from the ECDSA and SM2 nonce. The leak is very     small; observing it requires a large number of measurements. The effect is largest for curves whose group     order lies on a machine-word boundary, such as brainpoolP384r1. Applications using ECDSA signing over the     Brainpool and other generic prime curves, and SM2 signing on platforms that use the generic     implementation, are vulnerable to this issue. The NIST curves P-256, P-384 and P-521 use dedicated     constant-time implementations and are not affected. FIPS Impact: no The FIPS modules are not affected: the     approved NIST curves used in the FIPS provider have dedicated constant-time implementations and do not use     the affected code path. (CVE-2026-54872)

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 FreeBSD installed on the remote host is prior to tested version. It is, therefore, affected by multiple vulnerabilities as referenced in the 0d183075-bcb5-11f1-b09d-8447094a420f advisory.

    The OpenSSL project reports:

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

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

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3204 advisory.

    Issue summary: A certificate with many nameRelativeToCRLIssuer CRLdistribution points causes     disproportionate heap growth when OpenSSL cachesX.509 extensions.

    Impact summary: Receiving a crafted certificate from a malicious peer can leadto significant memory     pressure and possible Denial of Service in clients orin servers that solicit client certificates.

    CWE: CWE-770: Allocation of Resources Without Limits or Throttling

    Description: A certificate or a set of certificates that fits under the limit forsize of certificates     accepted from the peer (~100 KiB) can result in allocationof several hundred MiB of resident memory on the     receiving sideduring a normal TLS handshake.  This may be enough to crash the client orserver, if multiple     concurrent connections lead to similarly large memoryallocations.

    The fix postpones processing of the CRL distribution points extensions incertificates to the time when the     processed value is required for CRL processing.This avoids keeping large memory allocations for a long     time when suchcertificates are received.

    FIPS impact: noThe affected code is outside the FIPS module boundary. (CVE-2026-35189)

    Issue summary: The OpenSSL QUIC server, when configured to not preform addressvalidation, can be forced to     count incoming packets multiple times in itsunvalidated credit computation, leading to a violation of the     RFC 9000unvalidated connection amplification limit of 3 times the amount of datareceived.

    Impact summary: A remote attacker able to spoof packets to a server using theOpenSSL QUIC implementation     might use the server for an amplification ofa DDoS attack.

    CWE: CWE-440: Expected Behavior Violation

    Description: OpenSSL's QUIC stack, when operating as a server, enforces clientaddress validation (RFC     9000, Section 8), to confirm the peer address is notused for a traffic amplification attack.  If this     feature is disabled on theserver, the QUIC stack limits the amount of server data that can be sent to     3times the amount of data received from the peer address, until such time as theTLS handshake is     completed.

    The OpenSSL QUIC server, when operating in non-validation mode, adds thelength of the whole datagram     received to the unvalidated credit limit whenprocessing each QUIC packet in the datagram. A remote peer     may,after establishing a connection with an initial client hello frame, send asubsequent datagram     containing multiple QUIC packets, leading the server toaccount the entire datagram length for each packet     in the datagram, resultingin the server believing that the peer has sent more data than it actually     has,thereby violating the 3x amplification limit mandated by the RFC.

    FIPS impact: noAs the QUIC stack lives outside the FIPS module boundary, no FIPS modulesare affected by     this CVE. (CVE-2026-35191)

    Issue summary: The QUIC stream reassembly algorithm performance deterioratesprogressively as packets are     arriving out of order. The worst case hasa quadratic complexity proportional to the number of stream     frames kept inthe buffer for the received stream data.

    Impact summary: A remote QUIC peer that completes the handshake can createa connection-scoped CPU pressure     and potentially a Denial of Service usingcompliant STREAM frames inside the advertised receive window,     with lowattacker bandwidth.

    CWE: CWE-407: Inefficient Algorithmic Complexity

    Description: OpenSSL manages received QUIC stream fragments using adoubly-linked list. While it optimizes     for append operations (at the end ofthe list), it falls back to a head-to-tail linear search for any     fragmentthat does not immediately follow the current `tail`.

    By manipulating the sequence of offsets, an attacker can force the serverto perform O(n^2) operations,     consuming excessive CPU time for theQUIC process.

    FIPS impact: noThe FIPS module is not affected as the QUIC implementation is outside ofthe OpenSSL FIPS     module boundary. (CVE-2026-42772)

    Issue summary: The generic elliptic-curve scalar multiplication used forECDSA and SM2 signature operations     with curves that do not have a dedicatedimplementation leaks information about the secret nonce through     timing.

    Impact summary: An attacker able to measure signing times may learninformation about the per-signature     secret nonce, which over many signaturescan, via a lattice / Hidden Number Problem attack, lead to     recovery of theprivate key.

    CWE: CWE-208: Observable Timing Discrepancy

    Description: The generic elliptic-curve scalar multiplication used forcurves that do not have a dedicated     constant-time implementation pads thesecret scalar with non-constant-time BIGNUM operations, so the time     takendepends on the value of the secret scalar derived from the ECDSA and SM2 nonce.

    The leak is very small; observing it requires a large number ofmeasurements. The effect is largest for     curves whose group order lieson a machine-word boundary, such as brainpoolP384r1.

    Applications using ECDSA signing over the Brainpool and other generic primecurves, and SM2 signing on     platforms that use the generic implementation,are vulnerable to this issue.

    The NIST curves P-256, P-384 and P-521 use dedicated constant-timeimplementations and are not affected.

    FIPS Impact: noThe FIPS modules are not affected: the approved NIST curves used in the FIPSprovider have     dedicated constant-time implementations and do not use theaffected code path. (CVE-2026-54872)

    Issue summary: QUIC process may keep memory for QUIC packetbuffer for much longer period than necessary.

    Impact summary: Remote peer can exploit this vulnerabilityby sending maliciously crafted packets, making     the localQUIC stack to keep the memory for packet buffers allocated.The time for which the memory remains     allocated is entirelyunder the control of the potentially malicious remote peer.

    CWE: CWE-770: Allocation of Resources Without Limits or Throttling

    Description: To save copy operation from the packet buffer to thestream reassemble buffer the QUIC stack     leaves the stream dataon the packet buffer waiting to be copied to a buffer providedby the local receiving     application. The QUIC stack releasesa reference to the packet buffer only after the data are copiedto the     application buffer. This design is more efficient forlegitimate data transfers but enables an attacker to     allocate a lotmore memory than actually required by the data kept in the receivingstream buffer.

    To mitigate the vulnerability, the QUIC stack now calculatesand monitors memory overhead for every stream.
    The memory overheadfor a single stream frame is calculated as a difference between thesize of the whole     packet that carries the stream frame and the sizeof the stream frame itself. The memory overhead for a     single streamframe is added to the total (cumulative) memory overhead QUIC stackkeeps for each stream.
    Once the cumulative memory overhead exceeds64kB, the QUIC stack moves the stream frame data from the     packetbuffer to the stream buffer, starting with the next packet received.

    FIPS impact: noThe FIPS module is not affected as the QUIC implementation is outside ofthe OpenSSL FIPS     module boundary. (CVE-2026-54873)

    Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch aconnection to a different SSL_CTX part     way through a handshake may accessmemory beyond the end of an internal array if the replacement context     knowsabout more provider signature algorithms than the context the connection wascreated from.
    Applications which never call SSL_set_SSL_CTX() are notaffected.

    Impact summary: A remote peer may be able to cause a small out-of-boundsread, and in some circumstances a     fixed-value out-of-bounds write, on theserver heap. This may lead to a Denial of Service.

    CWE: CWE-787: Out-of-bounds Write

    Description: A TLS connection records how many certificate slots it haswhen it is created, taken from the     SSL_CTX that created it: the built-incertificate types plus one slot for each provider TLS-SIGALG entry     thatcontext was aware of. That count sizes an internal array of per-slotcertificate validity flags.

    An application may replace a connection's SSL_CTX part way through thehandshake by calling     SSL_set_SSL_CTX(), most commonly from a servernamecallback in order to serve a different virtual host.
    Doing so did notrefresh the recorded count. A provider signature algorithm's slot index isits position in     the list of whichever context resolves it, so if thereplacement context is aware of more of them than the     original, analgorithm offered by the peer can resolve to an index beyond the end of thearray. Processing     the peer's signature algorithms then reads one four byteword past the end for each such algorithm and,     where the word read is zero,writes a fixed value over it. A peer offering many of them can corrupt     heapmetadata and abort the process.

    Only provider signature algorithms which occupy one of the excess slots,and which the server also has     configured, have this effect. Codepoints thereplacement context does not recognise are discarded without     being resolvedto a slot, and provider signature algorithms are usable only from TLS 1.3.

    The two contexts must therefore be aware of different numbers of providersignature algorithms, which     requires separate library contexts, a providerloaded between the two being created, or providers which     differ in whatthey advertise - in 4.0, for example, the default provider advertises SM2where the FIPS     provider does not. A deployment meeting the condition isalso unable to negotiate the affected algorithms     with legitimate clients,since the same stale count hides the corresponding certificates, so     themisconfiguration is likely to be noticed. For that reason, and because theconfiguration is not the     default, this issue has been assessed as Lowseverity.

    FIPS impact: noNo FIPS modules are affected by this issue as the affected code is outsidethe OpenSSL FIPS     module boundary. (CVE-2026-72897)

    Issue summary: OpenSSL QUIC stack does not enforce connectionlevel flow control for streams. Remote peers     may send more bytesas long as they fit within the stream flow control limits.

    Impact summary: A malicious remote peer may exploit the lack of connectionflow control for streams to make     the QUIC stack receive ~100MB of memoryinstead of 768 KiB (default flow control window size).

    CWE: CWE-770: Allocation of Resources Without Limits or Throttling

    Description: The local QUIC stack advertises two flow control limitsto its remote peer: stream flow     control limit and connection flowcontrol limit. The remote peer must follow both limits when     transmittingstream data.

    Whenever the local QUIC stack receives a stream frame, it validatesthat the size of the received stream     frame stays within flow control limits.If either limit is exceeded (stream level or connection level),     thenthe QUIC stack must close the connection with a flow control error.

    The vulnerable OpenSSL QUIC stack enforces the stream-level but notthe connection-level limit. To exploit     the issue, three conditions must be met:- the remote peer opens several streams- each stream must stay     within the stream-level flow control limit- there must be no zero-offset byte sent on any of the     streams(to prevent the vulnerable QUIC stack from consuming data).By meeting the conditions above, the     remote peer may make the local stackallocate 2 x MAX_STREAMS x (stream flow control limit) bytesof memory.
    MAX_STREAMS defaults to 100, and the limit applies to bothbidirectional and unidirectional streams, making     it 200 in total. The defaultflow control window for a stream is 512kB. The remote peer mayforce the     vulnerable QUIC stack to allocate 100MB of heap per connection.

    FIPS impact: noThe FIPS module is not affected as the QUIC implementation is outside ofthe OpenSSL FIPS     module boundary. (CVE-2026-75804)

    Issue summary: A CMP client that requests certificate revocation on the basisof a PKCS#10 CSR may     dereference a NULL pointer and terminate abnormally whenprocessing a crafted revocation response.

    Impact summary: The NULL pointer dereference happens on a read whichleads to a crash and a Denial of     Service for the affected client application.

    CWE: CWE-476: NULL-pointer dereference

    Description: A CMP client revoking a certificate has to tell the server whichcertificate to revoke, and     may do so by supplying a PKCS#10 CSR instead of thecertificate itself or its issuer name and serial     number. This is'openssl cmp -cmd rr -csr <file>' on the command line, orOSSL_CMP_exec_RR_ses() with the     certificate supplied viaOSSL_CMP_CTX_set1_p10CSR() through the API.

    A CSR does not contain the issuer name and serial number of the certificate,so the client does not send     them. A server may optionally name thecertificate it revoked in its response, and the client then compares     thatname against what it sent. Having sent neither an issuer name nor a serialnumber, it has nothing to     compare against, and a server returning a speciallycrafted name causes the client to read from a NULL     pointer and crash.

    The revocation response is checked for valid message protection beforethe affected code is reached, so an     attacker must be a malicious orcompromised CMP server, or a man-in-the-middle in possession of thesecret     used for message protection. Clients that identify the certificateto be revoked by a certificate or by     issuer and serial number ratherthan by a PKCS#10 CSR are not affected.

    FIPS impact: noNo FIPS modules are affected by this issue, as the CMP protocolimplementation is outside     the OpenSSL FIPS module boundary. (CVE-2026-75805)

    Issue summary: An established DTLS 1.2 association using an AEAD cipher suitecan be terminated by a single     unauthenticated datagram whose encryptedfragment is shorter than the mandatory explicit IV and     authentication tagoverhead.

    Impact summary: An attacker who can send a datagram that is routed to anexisting DTLS 1.2 association can     tear that association down without knowingany key material. This is a Denial of Service limited to the     targetedassociation. There is no memory safety or confidentiality impact.

    CWE: CWE-1284: Improper Validation of Specified Quantity in Input

    Description: In TLS 1.2 and DTLS 1.2 every record protected by an AEAD ciphersuite carries an explicit IV     followed by the ciphertext and an authenticationtag. When decrypting such a record the record layer passed     the record length tothe cipher implementation before checking that the record was long enough tocontain     the explicit IV and the tag. For a record shorter than that overhead thecipher implementation rejected the     impossible length, and the record layertreated this as an internal failure and raised a fatal     internal_error alertinstead of treating the record as one that failed authentication.

    In TLS 1.2 the same record causes a fatal internal_error alert instead of theexpected bad_record_mac     alert. Since any undecryptable record alreadyterminates a TLS connection, this is a protocol conformance     issue rather thana security issue in TLS.

    The fix validates the record length against the explicit IV and tag lengthbefore any AEAD processing, so     that TLS reports bad_record_mac and DTLSsilently discards the record.

    FIPS impact: noThe affected code is outside the FIPS module boundary. (CVE-2026-75806)

    A flaw was found in OpenSSL. The Datagram Transport Layer Security (DTLS) retransmission mechanism fails     to properly handle handshake message writes that are suspended before completion. A remote attacker could     exploit this vulnerability during handshake message retransmission, causing OpenSSL to read past the     message buffer or overwrite internal state required to resume writing. This issue can result in     information disclosure through out-of-bounds memory reads or cause a Denial of Service (DoS) by crashing     the process. (CVE-2026-84782)

    Issue summary: A malicious remote peer may flood the local QUICstack with NEW_CONNECTION_ID frames by     avoiding a limit check onhow many connection IDs the remote QUIC stack can use.

    Impact summary: The local QUIC stack sends a RETIRE_CONN_ID framefor every NEW_CONNECTION_ID frame it     receives. The RETIRE_CONN_IDframe is dispatched via the Control Frame Queue (CFQ). If the remotepeer also     withholds ACKs, then it can force the local stackto allocate ~400MB (depending on ACK delay).

    CWE: CWE-770: Allocation of Resources Without Limits or Throttling

    Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanismby which a remote peer can notify     the local QUIC stack to change thedestination connection ID (a.k.a. CID) the local stack uses toidentify     the connection at the remote peer. Each CID is associatedwith a sequence number. The sequence number is     transmittedin NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CIDwhich is being either     associated with a connection or retired.

    The remote peer sends a NEW_CONNECTION_ID frame to let the local stack knowa new CID is being associated     with an existing connection. TheNEW_CONNECTION_ID frame carries the new CID, its sequence number, and     theretire-prior-to number. The retire-prior-to identifies existingCIDs that are to be retired. The local     QUIC stack must send aRETIRE_CONNECTION_ID for every destination CID whose sequence numberis less than     retire-prior-to. The CID becomes retired after thelocal stack receives an ACK for its RETIRE_CONNECTION_ID     frame.

    Although the OpenSSL QUIC stack supports at most one destination CIDfor every connection, it can be     tricked into processing more thanone RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUICstack     currently retires the destination CID as soon as it receivesthe NEW_CONNECTION_ID, while in fact the     destination CID mustbe retired after an ACK for the RETIRE_CONNECTION_ID frame is received.Correcting the     flawed logic also fixes the backlog growth.

    [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

    FIPS impact: noThe FIPS module is not affected as the QUIC implementation is outside ofthe OpenSSL FIPS     module boundary. (CVE-2026-84784)

Tenable has extracted the preceding description block directly from the tested product 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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Issue summary: A TLS server that calls SSL_set_SSL_CTX() to switch a connection to a different SSL_CTX     part way through a handshake may access memory beyond the end of an internal array if the replacement     context knows about more provider signature algorithms than the context the connection was created from.
    Applications which never call SSL_set_SSL_CTX() are not affected. Impact summary: A remote peer may be     able to cause a small out-of-bounds read, and in some circumstances a fixed-value out-of-bounds write, on     the server heap. This may lead to a Denial of Service. CWE: CWE-787: Out-of-bounds Write Description: A     TLS connection records how many certificate slots it has when it is created, taken from the SSL_CTX that     created it: the built-in certificate types plus one slot for each provider TLS-SIGALG entry that context     was aware of. That count sizes an internal array of per-slot certificate validity flags. An application     may replace a connection's SSL_CTX part way through the handshake by calling SSL_set_SSL_CTX(), most     commonly from a servername callback in order to serve a different virtual host. Doing so did not refresh     the recorded count. A provider signature algorithm's slot index is its position in the list of whichever     context resolves it, so if the replacement context is aware of more of them than the original, an     algorithm offered by the peer can resolve to an index beyond the end of the array. Processing the peer's     signature algorithms then reads one four byte word past the end for each such algorithm and, where the     word read is zero, writes a fixed value over it. A peer offering many of them can corrupt heap metadata     and abort the process. Only provider signature algorithms which occupy one of the excess slots, and which     the server also has configured, have this effect. Codepoints the replacement context does not recognise     are discarded without being resolved to a slot, and provider signature algorithms are usable only from TLS     1.3. The two contexts must therefore be aware of different numbers of provider signature algorithms, which     requires separate library contexts, a provider loaded between the two being created, or providers which     differ in what they advertise - in 4.0, for example, the default provider advertises SM2 where the FIPS     provider does not. A deployment meeting the condition is also unable to negotiate the affected algorithms     with legitimate clients, since the same stale count hides the corresponding certificates, so the     misconfiguration is likely to be noticed. For that reason, and because the configuration is not the     default, 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. (CVE-2026-72897)

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

ID	名前	製品	ファミリー	公開日	更新日	深刻度
351469	Ubuntu 22.04 LTS / 24.04 LTS / 26.04 LTS : OpenSSL vulnerabilities (USN-8847-1)	Nessus	Ubuntu Local Security Checks	2026/9/30	2026/10/2	high
372417	Rocky Linux 9.6 [TuxCare] Security Update: openssl / openssl-devel / openssl-libs / openssl-perl Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793092125)	Nessus	Rocky Linux Local Security Checks	2026/10/27	2026/10/27	high
372418	AlmaLinux 9.6 [TuxCare] Security Update: openssl / openssl-devel / openssl-libs / openssl-perl Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793092125)	Nessus	Alma Linux Local Security Checks	2026/10/27	2026/10/27	high
352194	OpenSSL 3.6.0 < 3.6.5 Multiple Vulnerabilities	Nessus	Web Servers	2026/9/30	2026/10/2	high
353457	FreeBSD : OpenSSL -- Multiple vulnerabilities (0d183075-bcb5-11f1-b09d-8447094a420f)	Nessus	FreeBSD Local Security Checks	2026/10/1	2026/10/2	high
365185	Amazon Linux 2023 : openssl, openssl-devel, openssl-fips-provider-latest (ALAS2023-2026-3204)	Nessus	Amazon Linux Local Security Checks	2026/10/12	2026/10/12	high
351202	Linux Distros Unpatched Vulnerability : CVE-2026-72897	Nessus	Misc.	2026/9/29	2026/11/6	high

検出

プラグインの検索

high

high

high

high

high

high

high