Nessus now has Windows LAPS Support
Summary: Nessus now has the ability to leverage accounts managed by Microsoft Windows LAPS. How LAPS works: Since LAPS managed accounts have their passwords rotated routinely, users cannot just directly provide the credentials in their Scan Policy. Before this change, users would instead have to make an additional privileged account on each LAPS enabled Host to provide to Nessus. Currently Nessus supports Entra LAPS allowing a scan to pull LAPS Managed Credentials from a customer’s remote Entra instance. Now, Nessus can do the same for Windows LAPS, allowing customers with local LAPS setups to gain the same benefits! Without Windows LAPS support, customers must make dedicated account for Nessus to use to scan targets Change: With this LAPS support change, during the startup phase of a scan, Nessus will reach out to a customer provided Domain Controller hosting an AD forest with LAPS enabled, and pull a list of all Local Admin Accounts for devices managed by LAPS. Nessus will then attempt to use these retrieved LAPS managed accounts as credentials when attempting to access a target host. With Windows LAPS Support, Customers need only provide a single Credential that allows Nessus to retrieve the actual credentials for LAPS Managed Devices How to enable it: To make use of Nessus’ Windows LAPS support, a customer needs only to provide the necessary info to their scan/policy via the Windows LAPS Credential. They’ll need to provide us the IP of the DC, Credentials for an account on that DC with the necessary permissions*, and the DistinguishedName of the OU that contains their LAPS managed devices. *The Account for retrieving Windows LAPS credentials needs the following permissions General Recommend the Account be added to the BUILTIN/Administrators AD Group as it grants all required permissions, including: Access to the $Admin Able to log on to the DC remotely Able to run Powershell WMI and DCOM access to Root/CIMV2 WMI Namespace LAPS Permissions LapsADReadPasswordPermission rights to the LAPS OU Be an Authorized Password Decryptor in the LAPS GPO (without this, Nessus will not be able to retrieve passwords protected by LAPS Encryption). Members of the Domain Administrators group are Authorized Password Decryptors by default. For additional information see: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview Impact: Customers using Rotating Host passwords managed through Microsoft Windows LAPS can now leverage these credentials in their Nessus scans for more secure scanning configurations. Target Release Date: Nessus, T.VM On/About 09 JUN 2025 T.SC TBD
Improved Printer Fingerprinting
Summary This document addresses an issue where network printers generate unnecessary prints when scanned, even with the "Don't Scan Printers" setting enabled. The fix involves improving the SNMP identification process for printers by falling back to default community strings and ports if an incorrect community string is initially configured. Background Currently, if a customer configures an incorrect SNMP v1/v2(c) community string for a device, Plugin ID 11933 / "Do not scan printers" fails to revert to using well-known, default SNMP v1/v2(c) community strings and ports, unlike other plugins. This failure can prevent accurate identification of network printers, leading to them being scanned and in some cases, may inadvertently queue print jobs on printers Impact The following assumes the user has enabled the "Do not scan printers" setting in their scan policy and the network printer is correctly identified as such: Potential Decrease in Reported Vulnerabilities: Network printers will be less heavily scanned, potentially leading to a decrease in reported vulnerabilities related to these devices. Slight Increase in Packet Traffic: There will be an increase of approximately three packets per host as the system attempts fallback SNMP connections. Printers Marked as "Dead": Network printers that are successfully identified via SNMP will be marked as "dead" and will not be scanned further. This change aims to enhance the effectiveness of identifying network printers using SNMP, thereby reducing unnecessary and potentially damaging traffic directed at these devices. The resulting decrease in reported vulnerabilities is an expected outcome, as identified printers will no longer be subjected to heavy scanning. Users can continue to scan network printers by enabling the "Scan Network Printers" setting under “Host Discovery -> Fragile Devices -> Scan Network Printers” in the scan policy. This ensures that printers are scanned and not marked as dead, irrespective of fingerprinting. Affected Plugins 11933 ( "Do not scan printers") Affected Scan Policy Settings Discovery -> Host Discovery -> Fragile Devices -> Scan Network Printers Tenable Security Center Tenable Vulnerability Management Tenable Nessus Target Release Date: Monday, September 15, 2025
Include/Exclude Path and Tenable Utils Unzip added to Log4j Detection
Summary Tenable has updated the Apache Log4j detection plugins. The Windows plugin will now honor the Include/Exclude Filepath configuration option. The Linux/UNIX plugin will now use the version of ‘unzip’ supplied with the Nessus Agent, when enabled in the Agent’s configuration, and correctly inspect the MANIFEST.MF and pom.properties files. Change Before this update, plugin 156000, Apache Log4j Installed (Linux / Unix), would fail to detect Log4j in specific scan scenarios. The plugin uses several inspection methods to determine if a JAR file is a copy of Log4j. During Nessus Agent scans, as well as scans with ‘localhost’ as a target, the plugin was not properly executing the unzip command to inspect META-INF/MANIFEST.MF and pom.properties files in the JAR archive. If this method was the only option that would result in a successful detection, the copy of Log4j would not be detected properly. In addition, the plugin had failed to launch the unzip binary supplied with the Agent when inspecting files in JAR archives. Note: The Nessus Agent can be configured to use find and unzip binaries that it provides, instead of those supplied by the asset’s operating system. See https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Agent_Performance_Options for more information. Also before this update, plugin 156001, Apache Log4j JAR Detection (Windows), would fail to honor the directories included or excluded for full-disk searches configured in the Windows Include Filepath and Windows Exclude Filepath directives in the Advanced Settings of a scan config. Note: Configuration of these options is described in https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Windows_filesearchOptions. After this update, plugin 156000 will use the Agent-supplied copy of unzip when configured to do so. If this option is not enabled in the scan config, the plugin will use the existing method to find and execute an archive utility supplied by the asset’s operating system. In either case, the plugin will properly inspect Log4j’s MANIFEST.MF and pom.properties files as a version source. Plugin 156001 already properly inspects these files. Also after this update, plugin 156001’s Powershell code will now honor directories included or excluded by the Filepath directives. Plugin 156000 already supported this feature. Impact When scanning Linux / UNIX assets via 'localhost' (i.e. scanning the scanner itself) or with the Nessus Agent, additional Log4j instances from MANIFEST.MF or pom.properties sources may be reported. For Linux Nessus Agents with "Use Tenable supplied binaries for find and unzip" enabled and "Agent CPU Resource Control - Scan Performance Mode" set to Low, plugin 156000 will now properly limit CPU usage during scans. As noted in the product documentation, “Note: Setting your process_priority preference value to low could cause longer running scans. You may need to increase your scan-window timeframe to account for this value.” Customers should be aware of this configuration setting and potential changes to the results provided in the Log4J detection results. When scanning Windows targets, Log4j JAR files stored in paths specified in the Windows Exclude Filepath configuration will no longer be detected. Log4j JAR files stored in paths or drives specified in the Windows Include Filepath configuration that had not been previously scanned will now be detected, assuming they can be assessed before the plugin’s configured timeout has been reached. Plugins 156000 - Apache Log4j Installed (Linux / Unix) 156001 - Apache Log4j JAR Detection (Windows) Target Release Date September 1, 2025Plugin 135860 (wmi_not_available) No Longer Fires if No Viable WMI Credentials were found
Summary: After reports of wmi_not_available.nbin firing during Remote Scans (despite only being applicable to Local Scans), changes have been made to prevent this firing and reduce noise in Scan Results. Specifically, early exit conditions have been added to key WMI libraries that are triggered if no working WMI Credentials (Windows Credentials that can successfully connect to WMI) are found. Change: Plugin 24269 (wmi_available.nbin) has two new exit conditions: If the Scan policy is configured to Start the Server Service, plugin 144455 (wmi_start_server_svc.nbin) will actually be run before wmi_available. It will attempt a WMI connection with each Windows Credential provided in the Scan. In the case that none of the Provided Credentials could successfully connect to WMI, wmi_start_server_svc.nbin will leave an artifact for wmi_available.nbin to exit early. It’s not necessarily that WMI is not available on the Host, just that the scan couldn’t get in with what was provided. After the WMI Connection attempt, wmi_available.nbin will now check for a scan artifact that WMI Connection was attempted but no Credentials were found. Plugin 135860 (wmi_not_available.nbin) checks a new scan artifact. If WMI wasn’t available for any reason outside of “No Viable Credentials found/worked”, the plugin continues as normal. If the new scan artifact is not present, the plugin will not run. Impact: If no Windows Credentials provided in the Scan Policy work, or if none were provided at all, Plugin 135860 (wmi_not_available.nbin) will NOT fire during a scan. Target Release Date: October 8, 2025Python Package Enumeration - Detection Updates
Summary Tenable has updated the Python package enumeration plugins to reduce false positives and to better identify vulnerabilities when multiple packages are present on the scan target. Change Before this update, the Python package enumeration plugins did not attempt to associate detected packages with an RPM or DEB package managed by the Linux distribution. This would cause some packages to report vulnerabilities both based on a Linux distribution vendor’s advisory and a CVE advisory from the Python package maintainer. In addition, some Python packages present through symbolic links (“symlinks”) on a scan target’s filesystem would report as separate files, instead of a single actual file. Finally, some vulnerability plugins did not correctly report when multiple vulnerable Python packages were present on a scan target. After this update, these issues have been addressed. Vulnerable Python packages on Linux assets will be assessed to determine if they are managed by a Linux distribution’s package manager, and if so, will be marked as “Managed” and will not report a vulnerability, unless the Show potential false alarms setting is enabled for the scan. Vulnerable Python packages detected will be assessed to determine if they are files or symlinks, and only the actual file will be reported. However, if multiple actual files are present, vulnerability detection plugins will correctly report all instances. Impact Most customers will notice a reduction in the volume of Python package vulnerabilities reported. Some scan results may show an increase in detected vulnerabilities if multiple independent installs of a Python package are present on a scan target, but this is much less likely. Detection plugins 181215 Python Installed Packages (Windows) 164122 Python Installed Packages (Linux/UNIX) 186173 Apache Superset Installed (Linux / Unix) 196906 AI/LLM Software Report 171433 Apache Airflow Installed (Linux / Unix) 201192 Horovod Detection 198067 Intel Neural Compressor Library Detection 201189 Keras Detection 201190 NumPy Detection 205587 H2O Detection 205584 LangChain Detection 205585 LLama.cpp Python Bindings Detection 206880 MLflow Detection 205586 OpenAi Detection 214312 AWS RedShift Python Connector Detection 205590 Seaborn Detection 205589 Tensorboard Detection 205588 Theano Detection 237200 Tornado Detection 206027 ZenML Detection 200977 PyTorch Detection 201193 Ray Dashboard Detection 201191 Scikit-learn Detection 195192 TensorFlow Detection 195203 Microsoft Azure Command-Line Interface (CLI) Installed (Linux) 208299 DeepSpeed Detection 208127 AIM Detection 208134 BentoML Detection 208126 Google AI Platform (VertexAI SDK) Detection 213710 Gradio Detection 208129 H2O-3 Detection 208135 H2OGPT Detection 208137 Kedro Detection 241433 Model Context Protocol (MCP) Detection 208131 MLRun Detection 208132 Neptune AI SDK Detection 208140 Ollama Detection 208136 Prefect Detection 208139 PySpark Detection 208138 Microsoft RD-Agent Detection 208141 Tensorflow-hub Detection 208130 NVIDIA TensorRT Detection 208133 Weights & Biases Detection 208128 Weights & Biases Weave Detection Vulnerability plugins 210056 NumPy 1.9.x < 1.21.0 Buffer Overflow 210055 NumPy < 1.22.0 Vulnerability - CVE-2021-34141 210057 NumPy < 1.22.2 Null Pointer Dereference 210054 NumPy < 1.19 DoS 213084 Pandas DataFrame.query Code Injection (Unpatched) 211464 torchgeo Python Library < 0.6.1 RCE 192941 Dnspython < 2.6.0rc1 DoS 193912 aioHTTP < 3.9.4 XSS 211644 aioHTTP 3.10.6 < 3.10.11 Memory Leak 211645 aioHTTP < 3.10.11 Request Smuggling 206721 Jupyterlab Python Library < 3.6.8 / 4.0 < 4.2.5 (CVE-2024-43805) 206977 LangChain Experimental Python Library <= 0.0.14 (CVE-2023-44467) 206722 Jupyter Notebook Python Library 7.0.0 < 7.2.2 (CVE-2024-43805) 212710 Pdoc Python Library <= 14.5.1 (CVE-2024-38526) 187972 PyCryptodome < 3.19.1 Side Channel Leak 193202 PyMongo < 4.6.3 Out-of-bounds Read 213287 python-libarchive Python Library <= 4.2.1 Directory Traversal (CVE-2024-55587) 204790 Python Library Certifi < 2024.07.04 Untrusted Root Certificate 206676 Python Library Django 4.2.x < 4.2.16 / 5.0.x < 5.0.9 / 5.1.x < 5.1.1 Multiple Vulnerabilities 214945 Python Library Django 4.2.x < 4.2.18 / 5.0.x < 5.0.11 / 5.1.x < 5.1.5 DoS 237889 Python Library Django 4.2.x < 4.2.22 / 5.1.x < 5.1.10 / 5.2.x < 5.2.2 Log Injection 194476 SAP BTP Python Library sap-xssec < 4.1.0 Privilege Escalation 200807 urllib3 Python Library < 1.26.19, < 2.2.2 (CVE-2024-37891) 242322 aioHTTP < 3.12.14 Request Smuggling (CVE-2025-53643) 234572 Microsoft Azure Promptflow Python Library promptflow-core < 1.17.2 RCE 234573 Microsoft Azure Promptflow Python Library promptflow-tools < 1.6.0 RCE 241329 Python Library Pillow 11.2.x < 11.3.0 Write Buffer Overflow Target Release Date November 10, 2025
Active Directory Starter Scan Background As part of our...
Active Directory Starter Scan Background As part of our endeavor to help reduce our customers’ cyber exposure, we are releasing a Starter Scan template along with plugins that will peel the onion around Active Directory Security. We hope customers will leverage these plugins as a starting point and consider an Active Directory Vulnerability Management solution for more holistic determination, given Active Directory breaches are ever-increasing and extremely devastating. Change Ten plugins checking for common Active Directory misconfigurations / vulnerabilities are being released. Active Directory controller credentials will be required for these plugins to run. Active Directory specific scan templates are also being released for Nessus Professional, Tenable.sc and Tenable.io. Dashboards for Tenable.sc and Tenable.io will also be available. Impact Customers will be able to run scans highlighting Active Directory issues. Note that these are starter Active Directory checks. For more complete coverage, we strongly recommend considering an Active Directory VM solution. Note that these plugins are not available on Nessus Agents. Plugins 150480 AD Starter Scan - Kerberoasting 150481 AD Starter Scan - Weak Kerberos encryption 150482 AD Starter Scan - Kerberos Pre-authentication Validation 150483 AD Starter Scan - Non-Expiring Account Password 150484 AD Starter Scan - Kerberos Krbtgt 150485 AD Starter Scan - Unconstrained delegation 150486 AD Starter Scan - Dangerous Trust Relationship 150487 AD Starter Scan - Primary Group ID integrity 150488 AD Starter Scan - Null sessions 150489 AD Starter Scan - Blank passwords Release Date Thursday 29 of July 2021Oracle WebLogic: Patch Mapping Improvements
Oracle WebLogic: Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the installed version of Oracle WebLogic. How Patch Mapping Works for Oracle WebLogic Scans Prior to these improvements, the WebLogic version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including WebLogic, are enumerated in one of two possible ways: Linux Local Detections: oracle_enum_products_nix.bin (plugin ID 71642, requires SSH credentials) Windows Local Detections: oracle_enum_products_win.nbin (plugin ID 71643, requires SMB credentials) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 73913, oracle_weblogic_server_installed.nbin, collects this information, and then reports the install and its determined version (patch level). Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out-of-band cycle, or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 14.2.1.0.0.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on a mapping table. Plugin ID 73913 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping table is still checked, and a version comparison is performed to determine the highest patch level present. In its output, plugin ID 73913 will now also report all of the installed patches for the ORACLE_HOME in which the detected WebLogic application resides. Expected Impact Improved accuracy in version detections for Oracle WebLogic resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins 73913, oracle_weblogic_server_installed.nbin Potentially any Oracle WebLogic local vulnerability check plugins Targeted Release Date Monday, June 9, 2025Machine Learning SinFP Model Updates for OS Fingerprinting
Summary Updates have been released for the Tenable MLSinFP model, which predicts a host's OS based on SinFP fingerprints, by rebuilding it on a newer tech stack, incorporating new features, and using a larger dataset, resulting in improved accuracy of 67%. Change Before this update, plugin 132935 “OS Identification: SinFP with Machine Learning” was targeting operating systems commonly seen up to January 2021; consequently any newer OSs were not available as predictions. Additionally, the plugin solely relied on TCP header information for model features. After this update, the plugin targets operating systems commonly seen up to May 2025. Additionally the training dataset is larger (was 700K records, now 1.8M) and more varied (was 6K distinct SinFP fingerprints, now 100K), the predicted OSs names are cleaner and more consistent, and model features other than TCP header information are relied on. Ultimately these changes resulted in the plugin's balanced accuracy increasing to 67% (was 54%). Impact Remote detection of operating systems based on the MLSinFP method will have a slightly higher confidence score. Assets whose operating system was determined based on this method might have a different detected operating system. Plugins 132935 - OS Identification: SinFP with Machine Learning Target Release Date October 27, 2025Red Hat: Custom RPM Repository Handling Improvements...
Red Hat: Custom RPM Repository Handling Improvements Summary Users with custom Red Hat repository naming conventions in their enterprise can now upload a custom mapping file in json format that maps custom RPM repository relative URLs to the official Red Hat counterparts for the purposes of vulnerability scanning. Problem Many Red Hat and Tenable customers utilize custom repository configurations and/or mirrors. In these cases, where neither the configured repository label or URL match Red Hat’s official mapping, Tenable plugins are unable to determine what software updates are available to the scan target. This can result in an increased number of potential false positive findings for Red Hat Local Checks. Solution With this update, we have introduced a method that allows users to upload a json file via their scan policy that maps their internal custom repository relative URL to the official Red Hat label and URL of the repository it mirrors. To upload this json file to your scan policy, go to “Settings > Advanced > Vulnerability Options > Custom Red Hat Repository Mapping” and click on the “Add File” link. For a more detailed overview of how this works in practice, please refer to the following user guide: How Red Hat Local Vulnerability Checks Use Repositories To Determine Scope Impacted Plugins All plugins in the Red Hat Local Security Checks family New plugin added: Plugin ID 233963, redhat_custom_repos.nasl Updated Scan Policy Templates Nessus Scanner Advanced Scan Advanced Dynamic Scan Basic Network Scan Nessus Agents Advanced Agent Scan Basic Agent Scan Targeted Release Date Nessus and Tenable VM: Monday, April 14, 2025 Tenable Security Center: TBCResearch Release Highlight - Changes to SMB Kerberos
Research Release Highlight - Changes to SMB Kerberos Summary Kerberos has been the default authentication mechanism for domain connected Windows devices since Windows 2008. Tenable credentialed scans of Windows targets support an explicit Kerberos credential type. The explicit credential, which names the DC and domain name, frees the Nessus sensor from having to be connected to the Windows domain being scanned and allows the scanner to be hosted on Linux or MacOS as well. The nature of this explicit Kerberos credential type has widely led to the expectation that a Kerberos scan of Windows will never use NTLM. That is not true. Currently Kerberos Windows scans will fail over to using NTLM if Kerberos does not succeed. The Kerberos protocol depends on time synchronization, FQDN target specification and bi-directional DNS name resolution, but NTLM does not. Tenable fails over to NTLM to preserve scan continuity where Kerberos on the target or scanner may not be configured correctly. As each Windows credential is tried, if Kerberos fails, a second attempt will be made using NTLM. Change We are changing Windows scans so that a scan will try all Windows credentials first before trying them again using NTLM if the credential set contains at least one Kerberos credential. This change also extends our Kerberos coverage to include Windows Configuration Manager and Active Directory Service Interfaces (ADSI) scans. Impact In certain customer environments where a single service credential (username/password) is used across multiple domains the current failover behavior causes NTLM to be used prematurely when it is possible that a subsequent Kerberos credential targeting a different domain might succeed. The change here favors Kerberos first and only fails over to NTLM after all credentials have been tried. Customers can also modify their SCCM (Windows Configuration Manager) credentials to include the domain controller's FQDN to allow those scans to use Kerberos. The net effect of these changes will be reduced dependency on NTLM in Windows scans and should produce better results in some cases. Target Release Date 07/16/2025
