Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64 processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However given the contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue. As a workaround the AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.

An update of the openssl package has been released.

The version of Tenable.ad installed on the remote host is prior to 3.59.5. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2024-11 advisory.

  - The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

  - Envoy is a cloud-native, open source edge and service proxy. Envoyproxy with a Brotli filter can get into     an endless loop during decompression of Brotli data with extra input. (CVE-2024-32976)

  - Envoy is a cloud-native, open source edge and service proxy. Envoy exposed an out-of-memory (OOM) vector     from the mirror response, since async HTTP client will buffer the response with an unbounded buffer.
    (CVE-2024-34364)

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 kata-containers-cc / hvloader / kata-containers / nodejs18 installed on the remote CBL Mariner 2.0 host is prior to tested version. It is, therefore, affected by a vulnerability as referenced in the CVE-2023-4807 advisory.

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

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

According to the versions of the openssl packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

  - Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or     parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to     generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(),     DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may     experience long delays. Where the key or parameters that are being checked have been obtained from an     untrusted source this may lead to a Denial of Service. While DH_check() performs all the necessary checks     (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable     for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an     excessively large P, it doesn't check for an excessively large Q. An application that calls     DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source     could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also     called by a number of other OpenSSL functions. An application calling any of those other functions may     similarly be affected. The other functions affected by this are DH_check_pub_key_ex(),     EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line     application when using the '-pubcheck' option, as well as the OpenSSL genpkey command line application.
    The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers     are not affected by this issue. (CVE-2023-5678)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the openssl packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to its self-reported version, the Tenable Nessus application running on the remote host is prior to 10.6.2. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-37 advisory.

  - Nessus leverages third-party software to help provide underlying functionality. Several of the third-party     components (OpenSSL, zlib) were found to contain vulnerabilities, and updated versions have been made     available by the providers.Out of caution and in line with best practice, Tenable has opted to upgrade     these components to address the potential impact of the issues. Nessus 10.6.2 updates OpenSSL to version     3.0.12, and zlib fixes have been applied to address the identified vulnerabilities.Additionally, one other     vulnerability was discovered, reported and fixed:Under certain conditions, a low privileged attacker could     load a specially crafted file during installation or upgrade to escalate privileges on Windows and Linux     hosts. - CVE-2023-5847 Tenable has released Nessus 10.6.2 to address these issues. The installation files     can be obtained from the Tenable Downloads Portal (https://www.tenable.com/downloads/nessus).
    (CVE-2023-45853, CVE-2023-4807, CVE-2023-5847)

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

According to its self-reported version, the Tenable Nessus Agent running on the remote host is 10.4.2. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-38 advisory.

  - Nessus Agent leverages third-party software to help provide underlying functionality. Several of the     third-party components (OpenSSL, zlib) were found to contain vulnerabilities, and updated versions have     been made available by the providers.Out of caution and in line with best practice, Tenable has opted to     upgrade these components to address the potential impact of the issues. Nessus Agent 10.4.3 updates     OpenSSL to version 3.0.12 and zlib fixes have been applied to address the identified     vulnerabilities.Additionally, one other vulnerability was discovered, reported and fixed:Under certain     conditions, a low privileged attacker could load a specially crafted file during installation or upgrade     to escalate privileges on Windows and Linux hosts. - CVE-2023-5847 Tenable has released Nessus Agent     10.4.3 to address these issues. The installation files can be obtained from the Tenable Downloads Portal     (https://www.tenable.com/downloads/nessus-agents). (CVE-2023-3446, CVE-2023-3817, CVE-2023-45853,     CVE-2023-4807, CVE-2023-5847)

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

According to its self-reported version, the Tenable Nessus application running on the remote host is prior to 10.5.6. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-36 advisory.

  - Nessus leverages third-party software to help provide underlying functionality. One of the third-party     components (OpenSSL) was found to contain vulnerabilities, and updated versions have been made available     by the provider.Out of caution and in line with best practice, Tenable has opted to upgrade these     components to address the potential impact of the issues. Nessus 10.5.6 updates OpenSSL to version 3.0.12     to address the identified vulnerabilities.Additionally, one other vulnerability was discovered, reported     and fixed:Under certain conditions, a low privileged attacker could load a specially crafted file during     installation or upgrade to escalate privileges on Windows and Linux hosts. - CVE-2023-5847 Tenable has     released Nessus 10.5.6 to address these issues. The installation files can only be obtained via the Nessus     Feed. (CVE-2023-4807, CVE-2023-5847)

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

According to its self-reported version, the Nessus Network Monitor running on the remote host is prior to 6.3.0. It is, therefore, affected by multiple vulnerabilities as referenced in the TNS-2023-34 advisory.

  - Nessus Network Monitor leverages third-party software to help provide underlying functionality. Several of     the third-party components (OpenSSL, curl, chosen, datatables) were found to contain vulnerabilities, and     updated versions have been made available by the providers. Out of caution and in line with best practice,     Tenable has opted to upgrade these components to address the potential impact of the issues. Nessus Network     Monitor 6.3.0 updates OpenSSL to version 3.0.11, curl to version 8.4.0, chosen to version 1.8.7 and datatables     to version 1.13.6. (CVE-2018-25050, CVE-2021-23445, CVE-2023-0465, CVE-2023-0466, CVE-2023-1255, CVE-2023-2650,     CVE-2023-3446, CVE-2023-38039, CVE-2023-3817, CVE-2023-4807)

  - Under certain conditions, Nessus Network Monitor could allow a low privileged user to escalate privileges to     NT AUTHORITY\SYSTEM on Windows hosts. (CVE-2023-5622)

  - NNM failed to properly set ACLs on its installation directory, which could allow a low privileged user to run     arbitrary code with SYSTEM privileges where NNM is installed to a non-standard location. (CVE-2023-5623)

  - Under certain conditions, Nessus Network Monitor was found to not properly enforce input validation. This     could allow an admin user to alter parameters that could potentially allow a blindSQL injection. (CVE-2023-5624)

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

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

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

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

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

  - Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might     corrupt the internal state of applications on the Windows 64 platform when running on newer X86_64     processors supporting the AVX512-IFMA instructions. Impact summary: If in an application that uses the     OpenSSL library an attacker can influence whether the POLY1305 MAC algorithm is used, the application     state might be corrupted with various application dependent consequences. The POLY1305 MAC (message     authentication code) implementation in OpenSSL does not save the contents of non-volatile XMM registers on     Windows 64 platform when calculating the MAC of data larger than 64 bytes. Before returning to the caller     all the XMM registers are set to zero rather than restoring their previous content. The vulnerable code is     used only on newer x86_64 processors supporting the AVX512-IFMA instructions. The consequences of this     kind of internal application state corruption can be various - from no consequences, if the calling     application does not depend on the contents of non-volatile XMM registers at all, to the worst     consequences, where the attacker could get complete control of the application process. However given the     contents of the registers are just zeroized so the attacker cannot put arbitrary values inside, the most     likely consequence, if any, would be an incorrect result of some application dependent calculations or a     crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the     CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of     this AEAD cipher is with TLS protocol versions 1.2 and 1.3 and a malicious client can influence whether     this AEAD cipher is used by the server. This implies that server applications using OpenSSL can be     potentially impacted. However we are currently not aware of any concrete application that would be     affected by this issue therefore we consider this a Low severity security issue. As a workaround the     AVX512-IFMA instructions support can be disabled at runtime by setting the environment variable     OPENSSL_ia32cap: OPENSSL_ia32cap=:~0x200000 The FIPS provider is not affected by this issue.
    (CVE-2023-4807)

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

ID	Name	Product	Family	Severity
204154	Photon OS 4.0: Openssl PHSA-2023-4.0-0472	Nessus	PhotonOS Local Security Checks	high
203635	Photon OS 5.0: Openssl PHSA-2023-5.0-0096	Nessus	PhotonOS Local Security Checks	high
201946	Tenable.ad < 3.59.5 Multiple Vulnerabilities (TNS-2024-11)	Nessus	Misc.	high
201810	CBL Mariner 2.0 Security Update: kata-containers-cc / hvloader / kata-containers / nodejs18 (CVE-2023-4807)	Nessus	MarinerOS Local Security Checks	high
192367	EulerOS Virtualization 2.11.0 : openssl (EulerOS-SA-2024-1445)	Nessus	Huawei Local Security Checks	high
192330	EulerOS Virtualization 2.11.1 : openssl (EulerOS-SA-2024-1417)	Nessus	Huawei Local Security Checks	high
188601	EulerOS 2.0 SP11 : openssl (EulerOS-SA-2023-3283)	Nessus	Huawei Local Security Checks	high
188487	EulerOS 2.0 SP11 : openssl (EulerOS-SA-2023-3255)	Nessus	Huawei Local Security Checks	high
184164	Tenable Nessus < 10.6.2 Multiple Vulnerabilities (TNS-2023-37)	Nessus	Misc.	high
184128	Tenable Nessus Agent 10.4.2 Multiple Vulnerabilities (TNS-2023-38)	Nessus	Misc.	high
184127	Tenable Nessus < 10.5.6 Multiple Vulnerabilities (TNS-2023-36)	Nessus	Misc.	high
183921	Nessus Network Monitor < 6.3.0 Multiple Vulnerabilities (TNS-2023-34)	Nessus	Misc.	high
181290	OpenSSL 3.1.0 < 3.1.3 Vulnerability	Nessus	Web Servers	high
181289	OpenSSL 3.0.0 < 3.0.11 Vulnerability	Nessus	Web Servers	high
181288	OpenSSL 1.1.1 < 1.1.1w Vulnerability	Nessus	Web Servers	high

Detections

Analytics

CVE-2023-4807

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high