Python 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
Plugin 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, 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, 2025
New Plugin Family: UnionTech Local Security Checks
Summary Tenable will now provide vulnerability check plugins for UnionTech Unity Operating System (UOS). Impact Customers with UnionTech Unity Operating System (ServerA and ServerE) systems in their environments will be able to scan them for vulnerabilities. These plugins will have the family “UnionTech Local Security Checks”. These plugins will not have agent support at this time, but this support is expected in a future release. Target Release Date September 30, 2025Include/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, 2025Excluding the SUSE Linux Snapshots directory from Language Library enumeration
Summary The “language library” enumeration plugins will now exclude SUSE Linux’s snapshots directory when searching the filesystem. Change Before the update, when enumerating “language libraries” - such as Python packages, Node.js modules, etc. - on SUSE Linux hosts that use btrfs as their filesystem, reduced scan performance was observed. This is because btrfs creates and maintains snapshots in the /.snapshots directory, which can contain multiple redundant copies of files. This caused unnecessary processing on thorough scans. After the update, this snapshots directory has been excluded from searches executed by the find command for language library enumeration plugins on SUSE Linux. Impact This change is expected to improve the performance of scans on SUSE Linux assets. If language libraries were present in snapshots directory, they will no longer show up in Tenable scan results, along with any associated vulnerabilities. If customers would like to scan the snapshots directory, the "Include Filepath" option in the Advanced Scan Settings configuration can be used to force the scanning of these paths. Plugins 178772 - Node.js Modules Installed (Linux / Unix) 190687 - NuGet Installed Packages (Linux / Unix) 164122 - Python Installed Packages (Linux / Unix) 207584 - Ruby Gem Modules Installed (Linux / Unix) Target Release Date September 3, 2025Nessus 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 TBDOracle Enterprise Manager Agent: Patch Mapping Improvements
Summary Improvements have been made to how Nessus plugins determine the active version of Oracle Enterprise Manager Agent. How Patch Mapping Works for Oracle Enterprise Manager Agent Scans Prior to these improvements, the Enterprise Manager Agent 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 Enterprise Manager Cloud Control and Agent, 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 86575 (oracle_enterprise_manager_agent_installed.nbin) reports only the base version (e.g 13.5.0.0.0). The full version (patch level) is determined, processed for the relevant vulnerabilities and reported in the individual vulnerability plugins (e.g plugin ID 192753), again by referencing a Tenable managed mapping table. 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. 13.5.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 the mapping tables. Plugin ID 86575 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 tables are still checked, and a version comparison is performed to determine the highest patch level present. For Enterprise Manager Agent, the vulnerability plugins like 192753 will no longer need to determine for themselves the installed version (patch level), as this will now be done via the underlying detection plugin, 86575. This plugin will now also report all of the installed patches for the ORACLE_HOME in which the detected Enterprise Manager Agent product resides. Expected Impact Improved accuracy in version detections for Oracle Enterprise Manager, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins - 86575 - oracle_enterprise_manager_agent_installed.nbin - All Oracle Enterprise Manager Agent local vulnerability check plugins (e.g 192753) Targeted Release Date - Wednesday, July 2, 2025Where Capability Meets Opportunity: Meet the Tenable Research Special Operations Team
The digital battlefield is constantly shifting. It's no longer enough to just react. We need to anticipate. But what if there was a team dedicated to seeing these threats coming, understanding adversary tactics, and sending early warning signals for what might come next? Meet the elite team that’s hunting the next major cyberattack: The Tenable Research Special Operations (RSO) team. This elite team is united with one mission: to cut through the noise and deliver critical intelligence about the most dangerous cyber threats emerging right now. They go beyond generic warnings to provide real-time, actionable insights that can help protect your business. Read the blog to learn more about RSO and how their research insights can enhance your security programOracle Enterprise Manager Cloud Control: Patch Mapping Improvements
Summary Improvements have been made to how Nessus plugins determine the active version of Oracle Enterprise Manager Cloud Control. How Patch Mapping Works for Oracle Enterprise Manager Cloud Control Scans Prior to these improvements, the Enterprise Manager Cloud Control 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. The process is as follows: Installed patches for most Oracle products, including Enterprise Manager Cloud Control, 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 80965 (oracle_enterprise_manager_installed.nbin) collects this information, and then reports the respective installs and their determined versions (patch levels) by comparing detected installed patches to the Tenable managed patch mapping table. 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. 12.2.1.4.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 the mapping tables. Plugin ID 80965 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 tables are still checked, and a version comparison is performed to determine the highest patch level present. For Enterprise Manager Cloud Control, plugin ID 80965 will now also report all of the installed patches for the ORACLE_HOME in which the detected Enterprise Manager product resides. Expected Impact Improved accuracy in version detections for Oracle Enterprise Manager Cloud Control, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins - 80965 - oracle_enterprise_manager_installed.nbin - Potentially any Oracle Enterprise Manager Cloud Control vulnerability check plugins (e.g 209256) Targeted Release Date - Monday, June 30, 2025
