Component Installs Require Paranoid Checks
Summary With this update, products that are deemed to be components of another application, will now require the scan to be run in paranoid mode to trigger generic vulnerability detection plugins. In this context, “generic vulnerability detection plugins” refers to plugins that cover advisories published by the component vendor (e.g., plugin ID 242325, SQLite < 3.50.2 Memory Corruption) rather than the operating system or “parent” application that distributes the component, either as a part of the operating system or a dependent tool of the parent application. Overview Tenable covers software that can be either installed as base level software, or be included as component software of a larger product installation. Base level software can be updated without any impact to the base product functionality. Component software is typically updated as part of the vendor update for the larger packaged product, and the individual components are not updatable. Non-paranoid scans will report base software vulnerabilities that are actionable. Paranoid scans will report on base software vulnerabilities as well component software vulnerabilities that are not actionable, but still package a potentially vulnerable version of the component. To enhance the accuracy of our vulnerability detection and provide users with greater control over scan results, we are implementing an update affecting how we flag vulnerabilities in software components. Our detection plugins for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules can now identify when these packages are installed as components of another parent application (e.g., SQLite bundled with Trend Micro’s Deep Security Agent), rather than as standalone installs. Key Changes: Non-Paranoid Scans: Scans running in the default mode will no longer flag generic vulnerability detection plugins for these component installs. This is because vulnerabilities in components generally cannot be patched directly; users must wait for the parent application's vendor to issue an update. OS Vendor Advisories Unaffected: This change does not affect plugins for OS vendor security advisories that cover the same vulnerabilities (e.g., plugin ID 243452, RHEL 9 : sqlite (RHSA-2025:12522)). Paranoid Scans: For scans running in paranoid mode, generic vulnerability detection plugins will still trigger for component installs if the detected version is lower than the expected fixed version. Expected Impact: Customers running non-paranoid scans should anticipate seeing a reduction in potential vulnerability findings for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules that are installed as components. Technical Details: The changes are entirely contained within two shared libraries, vcf.inc and vdf.inc, utilized by the affected plugins. This update impacts approximately 750 plugins specific to OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, and SQLite. Targeted Release Date: TBD
Research Release Highlight - Backported Vulnerability Detection Improvements
Summary Backporting is the practice of using parts of a newer version of software to patch previous versions of the same software, most commonly to resolve security issues that also affect previous versions. For example, if a vulnerability is patched in version 2.0 of a piece of software, but version 1.0 is also affected by the same security hole, the changes are also provided as a patch to version 1.0 to ensure it remains secure. Tenable Research identifies backported software installs based on the server banners that the service returns. Previously, when a backported install was detected during a non-paranoid scan, downstream vulnerability plugins would not report the install as vulnerable. During a paranoid scan, vulnerability plugins would act upon the version returned in the banner and would flag if a vulnerable version was installed. Exact details of this process were outlined in this article. This approach was false positive prone and was difficult to maintain accurately due to inconsistent & untimely information from vendors detailing their backported fixes. Change As discussed in the above article, Tenable Research previously maintained a list of known backported banners. If a delta existed between the release of a backported fix & an update made by Tenable Research, a false positive result may have occurred in scans during this time. Following this change, any banners which indicate the software is packaged by a Linux distribution will be deemed to be backported by default. These types of banners typically follow the format of <product>/<version> (<Operating System>) ( E.g., Apache/1.2.3 (Ubuntu) ). Impact During non-paranoid scans, customers can expect improved coverage for products which contain backport fixes that are detected remotely. As a result of this, a reduction in false positives being reported is also expected. Enabling paranoia in a scan configuration will continue to cause backported installs to be treated as regular installs by vulnerability checks. For more accurate vulnerability checks which don’t rely upon the content in a server banner, customers can leverage credentialed or agent-based local checks. Target Release Date January 22, 2026Improved Resource Management Control
Summary Improved resource management control for plugins leveraging Windows Management Instrumentation (WMI) on Nessus Agent 11.1.0 or higher. Impact Customers with Nessus Agent 11.1.0 and later versions will have the ability to granularly control the CPU resources consumed during scans. This update ensures that plugins respect the resource usage setting selected during scan configuration by launching commands as children of the Nessus Agent, rather than invoking them via WMI. The release of these plugins will continue through January, with a phased approach over three weeks. The first release will be January 13th, the second January 20th, and the final planned plugin update on January 27th. Target Release Date Phase 1 plugin set: January 13, 2025 Phase 2 plugin set: January 20, 2025 Phase 3 plugin set: January 27, 2025Distinct Agent Plugin Databases for RPM-Based Distributions
Summary Tenable will now provide separate agent plugin databases for RPM-based Linux distributions. Impact Historically, the majority of plugins for RPM-based Linux distributions have all been distributed via a single artifact. Starting with Nessus Agent 11.1.0, Tenable will now publish separate artifacts based on the following plugin families: Alma Linux Local Security Checks CentOS Local Security Checks Miracle Linux Local Security Checks Oracle Linux Local Security Checks Red Hat Enterprise Linux Local Security Checks Rocky Linux Local Security Checks As a result, customers will see a reduction in the overall size of the agent database (15-31% reduction at rest, 7-14% downloaded), directly leading to smaller updates and reduced resource consumption during the update process. This improvement will be available to all customers using Agent 11.1.0 or later versions. Target Release Date January 13, 2026Research Highlight - New Plugin Family: Miracle Linux Local Security Checks
Summary Tenable will now provide vulnerability check plugins for Miracle Linux. Impact Customers with Miracle Linux systems in their environments will be able to scan them for vulnerabilities. These plugins will belong to the “Miracle Linux Local Security Checks” family. At initial release, there will be approximately 1,500 new plugins for Miracle Linux. Use of these plugins will require Agent 11.1.0 and above. Target Release Date January 13, 2026Node.js Module Enumeration Detection Updates
Summary Tenable has updated the Node.js module 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 Node.js module 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 Node.js module maintainer. In addition, some Node.js installations on macOS that originated from third-party package managers, or from source, were not detected by the Node.js detection plugin. This would prevent the Node.js module enumeration plugin from running on those macOS assets. In some cases, a large volume of Node.js modules detected would cause the enumeration plugin to crash when attempting to report the list of modules in plugin output. After this update, these issues have been addressed. Vulnerable Node.js modules 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. Node.js installs on Windows and macOS that were not previously detected due to the installation method will now be detected, and their installed modules will be enumerated. The module enumeration plugins will no longer report the list of detected modules in plugin output; rather, they will use only internal storage mechanisms to record the detected modules, so that Node.js vulnerability plugins can continue to use that data for version checks. Impact Most customers will notice a reduction in the volume of Node.js module vulnerabilities reported. Some Windows and macOS scan results may show an increase in detected vulnerabilities if Node.js was not previously detected based on the installation method. If a large number of modules is present on a scan target and had previously caused the plugin to malfunction and report no vulnerabilities, those targets may show previously unreported vulnerabilities, as the module enumeration plugin would now complete and allow the vulnerability plugins to execute. Plugins affected 200172 - Node.js Modules Installed (Windows) 179440 - Node.js Modules Installed (macOS) 178772 - Node.js Modules Installed (Linux) 110839 - Node.js Installed (Windows) 142903 - Node.js Installed (macOS) Target Release Date January 5, 2026Python 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, 2025
GA Release - Tenable Add-on for Splunk v8.0.1 is Now Available
Hi everyone, We are thrilled to announce the latest major update to the Tenable Add-on for Splunk. Version 8.0.1 is now live and was released on September 30, 2025. Released: September 30, 2025 Get It Now: Visit the Tenable Add-on for Splunk on Splunkbase by searching for "Tenable Add-on for Splunk" or going to splunkbase.splunk.com/app/4060 What's New in Version 8.0.1: Fixed an issue with custom SSL certificates for the Tenable SecurityCenter input Improved compliance data collection by preserving original field valuesxx Compatibility Matrix: Browsers: Google Chrome, Mozilla Firefox Operating Systems: Platform independent Splunk Enterprise: Versions 10.0.x, 9.4.x, and 9.3.x Supported Deployments: Splunk Cluster, Splunk Standalone, and Distributed Deployment Known Issues and Limitations: None A shoutout to everyone who made this release possible. Thanks, Ahmad Maruf Tenable Ecosystem Product ManagementMachine 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