nessus network monitor CVEs · No public exploit

Look up CVE IDs Status Exploitation Severity

Reset

Overview 10 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

10matches 0in Waratek scope0.0% 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0% Outside Waratek scope 2 20.0% Not applicable 8 80.0% Withdrawn CVE 0 0.0%

Critical 0 0.0% High 9 90.0% Medium 1 10.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 10 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 10 100.0%

split by StatusSeverityProtectionExploit maturity peak 3 / quarter

Q4 201 Not applicable1 High1 not blocked1 No public exploit1 Q1 212 Outside Waratek scope1 Not applicable1 High1 Medium1 not blocked2 No public exploit2 Q2 210 Q3 211 Outside Waratek scope1 High1 not blocked1 No public exploit1 Q4 210 Q1 220 Q2 220 Q3 220 Q4 220 Q1 230 Q2 230 Q3 230 Q4 233 Not applicable3 High3 not blocked3 No public exploit3 Q1 240 Q2 240 Q3 241 Not applicable1 High1 not blocked1 No public exploit1 Q4 240 Q1 250 Q2 252 Not applicable2 High2 not blocked2 No public exploit2

Q4 20Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25

10 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2025-24917	High	2025-05-23	Not applicable	No public exploit	In Tenable Network Monitor versions prior to 6.5.1 on a Windows host, it was found that a non-administrative user could stage files in a local directory to run arbitrary code with SYSTEM privileges, potentially leading to local privilege escalation.
CVE-2025-24916	High	2025-05-23	Not applicable	No public exploit	When installing Tenable Network Monitor to a non-default location on a Windows host, Tenable Network Monitor versions prior to 6.5.1 did not enforce secure permissions for sub-directories. This could allow for local privilege escalation if users had not secured the directories in the non-default installation location.
CVE-2024-9158	High	2024-09-30	Not applicable	No public exploit	A stored cross site scripting vulnerability exists in Nessus Network Monitor where an authenticated, privileged local attacker could inject arbitrary code into the NNM UI via the local CLI.
CVE-2023-5624	High	2023-10-26	Not applicable	No public exploit	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-5623	High	2023-10-26	Not applicable	No public exploit	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-5622	High	2023-10-26	Not applicable	No public exploit	Under certain conditions, Nessus Network Monitor could allow a low privileged user to escalate privileges to NT AUTHORITY\SYSTEM on Windows hosts by replacing a specially crafted file.
CVE-2021-3712	High	2021-08-24	Outside Waratek scope	No public exploit	ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).
CVE-2021-3450	High	2021-03-25	Not applicable	No public exploit	The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).
CVE-2021-23841	Medium	2021-02-16	Outside Waratek scope	No public exploit	The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).
CVE-2020-5794	High	2020-11-06	Not applicable	No public exploit	A vulnerability in Nessus Network Monitor versions 5.11.0, 5.11.1, and 5.12.0 for Windows could allow an authenticated local attacker to execute arbitrary code by copying user-supplied files to a specially constructed path in a specifically named user directory. The attacker needs valid credentials on the Windows system to exploit this vulnerability.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2025-24917

High

2025-05-23

Not applicable

No public exploit

In Tenable Network Monitor versions prior to 6.5.1 on a Windows host, it was found that a non-administrative user could stage files in a local directory to run arbitrary code with SYSTEM privileges, potentially leading to local privilege escalation.

CVE-2025-24916

High

2025-05-23

Not applicable

No public exploit

When installing Tenable Network Monitor to a non-default location on a Windows host, Tenable Network Monitor versions prior to 6.5.1 did not enforce secure permissions for sub-directories. This could allow for local privilege escalation if users had not secured the directories in the non-default installation location.

CVE-2024-9158

High

2024-09-30

Not applicable

No public exploit

A stored cross site scripting vulnerability exists in Nessus Network Monitor where an authenticated, privileged local attacker could inject arbitrary code into the NNM UI via the local CLI.

CVE-2023-5624

High

2023-10-26

Not applicable

No public exploit

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-5623

High

2023-10-26

Not applicable

No public exploit

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-5622

High

2023-10-26

Not applicable

No public exploit

Under certain conditions, Nessus Network Monitor could allow a low privileged user to escalate privileges to NT AUTHORITY\SYSTEM on Windows hosts by replacing a specially crafted file.

CVE-2021-3712

High

2021-08-24

Outside Waratek scope

No public exploit

ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).

CVE-2021-3450

High

2021-03-25

Not applicable

No public exploit

The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).

CVE-2021-23841

Medium

2021-02-16

Outside Waratek scope

No public exploit

The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

CVE-2020-5794

High

2020-11-06

Not applicable

No public exploit

A vulnerability in Nessus Network Monitor versions 5.11.0, 5.11.1, and 5.12.0 for Windows could allow an authenticated local attacker to execute arbitrary code by copying user-supplied files to a specially constructed path in a specifically named user directory. The attacker needs valid credentials on the Windows system to exploit this vulnerability.