Component Installs Require Paranoid Checks (DEPRECATED)
Update - March 4, 2026 After considering customer feedback, we. have decided to re-evaluate these changes and come up with a better way of handling Component installs. For the latest information, please refer to the new release highlight: Improvement: Handling Component Installs for Vulnerability Assessment 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: Friday, February 6, 2026Improvement: Handling Component Installs for Vulnerability Assessment
Background On Friday, February 6, 2026, Tenable Research published a plugin update that changed the way component installs are assessed for vulnerabilities. Those changes are outlined in a previous release highlight: Component Installs Require Paranoid Checks, This update essentially reverts this change, while adding new functionality to allow users to choose whether or not they want component installs assessed for vulnerabilities. Component installs are no longer influenced by scan paranoia settings. What are “Component Installs”? Software components, such as applications or language modules/libraries, are installed and managed by a primary "parent" package or application. The crucial point is that these components often cannot be updated individually. Instead, their vulnerability assessment and upgrade are entirely dependent on an update of the parent package. For instance, the SQLite database component is installed as part of the Trend Micro Deep Security Agent and is updated only when the Agent itself is updated. Nessus uses several factors to determine if a detected product is a component, or a standalone installation, including: Was the product installed by a package manager? These products are not considered components, as they are managed by the package manager and not a “parent” application Is the component a “language library”, i.e. a library or module used by the interpreter of a programming language like Python or Node.js? These enumerated libraries are marked as components by default. Does the product reside in a directory that is recognized for installations that are not component-based? Changes By default, component installs are once again assessed for vulnerabilities, as was the case prior to the release of the aforementioned update. If users wish to turn this setting off, so that component installs will not be assessed by generic vulnerability detection plugins, they can do so via the newly created scan preference. The end result of this change should be that fewer “false positives”, i.e. reported vulnerabilities for components that are “owned” by another application, are shown in scan results. Components with vulnerabilities that cannot be addressed independently of the “parent” application will not show in scan results. However, some customers have expressed a desire to see these vulnerabilities in their scan results anyway, to ensure full awareness of the risk profile of every application in their environment. This is still possible through the updated scan configuration settings. To modify this setting in your scan policy, go to Settings > Assessment > Accuracy > Override Normal Accuracy > Assess component installs for potential vulnerabilities. This setting is ON (checkbox is ticked) by default, so users must enable the Override Normal Accuracy checkbox (which is OFF / unchecked by default) if they wish to disable the setting and ensure that component installs are not assessed by generic vulnerability detection plugins in this scan. Please note that this update makes no other changes to the existing paranoia logic, outside of what is described above. For now, “Managed”, “Managed by OS” and “Backported” installs are still controlled by the Show/Avoid potential false alarms radio button. How can I tell if the detected install is a component or not? In addition to the above, we have also updated the relevant detection plugins so they will show if the component flag is set or not. At present, this includes detection plugins for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, Python Packages, Node.js modules and, soon to follow, Ruby and Nuget libraries. Using plugin ID 174788, SQLite Detection (Windows), here is a before and after example of the expected plugin output. Before: After: Expected Impact With the new default setting in place, users should anticipate an increase in vulnerability findings for the products in scope, returning to a level similar to what was observed before the first update. If users do not wish to surface these additional potential vulnerabilities, they should disable the "Assess component installs for potential vulnerabilities” setting. If the new scan preference is disabled, the volume of findings will remain consistent with current levels, when scanning with normal accuracy (paranoia) settings. Affected Plugins 12288, global_settings.nasl (updated to support the new scan policy preference) Any plugin that operates downstream of those in the list below: SQLite: 174788 - sqlite_nix_installed.nasl 171077 - sqlite_win_installed.nasl OpenSSL: 168007 - openssl_nix_installed.nasl 168149 - openssl_win_installed.nasl Curl: 182774 - curl_nix_installed.nasl 171860 - curl_win_installed.nasl LibCurl: 182848 - libcurl_nix_installed.nasl Apache HTTPD: 141394 - apache_http_server_nix_installed.nasl 141262 - apache_httpd_win_installed.nasl Apache Tomcat: 130175 - apache_tomcat_nix_installed.nasl 130590 - tomcat_win_installed.nasl Python Packages: 164122 - python_packages_installed_nix.nasl 139241 - python_win_installed.nasl Node.js Modules: 178772 - nodejs_modules_linux_installed.nasl 179440 - nodejs_modules_mac_installed.nasl 200172 - nodejs_modules_win_installed.nasl Targeted Release Date Tenable Nessus and Vulnerability Management: Monday, March 9, 2026 (ETA 22:30 Eastern Standard Time) Tenable Security Center: Monday, March 16, 2026
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 TBDImproved 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, 2025Improved 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 February 9th. Target Release Date Phase 1 plugin set: January 13, 2026 Phase 2 plugin set: January 20, 2026 Phase 3 plugin set: February 9, 2026Improvement to Printer OS Fingerprinting
Updated: April 3, 2026 Summary Scanned printers will now have an OS artefact surfaced in their scan host metadata if the target has been identified as a printer when the “Scan Network Printers” policy option is disabled. This change will not cause any additional asset licenses to be consumed within Tenable VM or Tenable Security Center. Background Printers are notoriously unstable scan targets. Oftentimes, they can behave erratically when scanned, so some users prefer to avoid scanning them altogether. At present, there is a switch in the scan policies to prevent further scanning of a host when it's identified as a printer. To enable this setting, go to Settings -> Host Discovery -> Fragile devices - Scan Network Printers (Currently, this is a checkbox setting, default value “off”). With that said, how can the scanner know the target is a printer if it cannot be scanned? In reality, the scanner still performs very basic fingerprinting (usually via SNMP) in order to gather enough information to make an educated guess at the device type. When the scan target is thought to be a printer, it essentially gets marked as “Host/dead" in the scan KB. When this happens, the scanner will not perform any further active scanning. Changes With this update, the fingerprint used to identify the printer as such, will now be stored in the scan Knowledge Base (KB) so it can be processed by os_fingerprint2.nasl ("Post-scan OS Identification", plugin ID 83349) and surfaced as metadata in the scan result. The relevant policy setting located at Settings -> Host Discovery -> Fragile devices -> Scan Network Printers. With this update, the printer's OS information will now be surfaced if it is available, regardless of the selected value for this setting. Impact Users can now see the OS information for their printer devices that would have otherwise gone unreported if the scan is not configured to “Scan Network Printers”. As plugin ID 83349 generates no plugin output, only an “operating-system” tag will be added to the scan result (and stored in an exported .nessus file). This information will be visible only the in “Host/Asset Details” section of the Tenable product UI, i.e: Tenable Nessus: Scans -> [Folder] -> [Individual Scan Result] - > Host Details -> OS (sidebar) Tenable Vulnerability Management: Explore -> Assets -> [Asset] -> Details -> Operating System Scans -> Vulnerability Management Scans -> [Individual Scan Result] -> Scan Details -> Asset Details -> Operating System Tenable Security Center: Analysis -> IP Summary -> [IP address] -> System Information -> OS Scans -> Scan Results -> [Individual Scan Result] -> IP Summary -> [IP address] -> System Information -> OS Note, we expect this information to surface mainly in individual scan results. It would only be present in cumulative asset details if a licensed asset already exists for the target in question. This update will not cause additional assets to be created or consume any additional licenses. Affected Plugins 83349 - os_fingerprint2.nasl 11933 - dont_scan_printers.nasl 22481 - dont_scan_settings.nasl Targeted Release Date Wednesday, March 4, 2026
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 2021Disable Red Hat repository correlations and strictly use package version checks
Summary With this update, users will now have the ability to disable the requirement to consider the enabled yum updated repositories before proceeding to package version checks to determine vulnerability status for Red Hat Local Security Checks plugins. This option can now be toggled on/off via the scan policy.To toggle this new feature in your scan policy, navigate to Settings > Advanced > Vulnerability Options and toggle "Disable RedHat repository correlations and strictly use package version checks" on/off as desired. Background To understand how Tenable's Red Hat Local Security Checks plugins currently work, please refer to the following document: How Red Hat Local Vulnerability Checks Use Repositories To Determine Scope. Expected Impact Users should potentially expect to see more Vulnerability findings in their scans when this option is enabled. This is expected because the plugins will no longer consider whether or not the target machine has the specified repository enabled to receive the fixed package(s). Instead, the plugins will only check that any version of the affected package is installed, and proceed straight to version comparison. Tenable's RPM package parsing libraries have extensive functionality to ensure package version checks are as accurate as possible, but due to the potential differences in epoch versions and package naming and versioning discrepancies between the different repositories, potential false positives are possible when this feature is enabled. Affected Plugins Red Hat Local Security Checks Targeted Release Date Thursday, February 5, 2026 Note, not all Red Hat Local Security Check plugins can avail of the this feature yet. Only plugins that have include("rpm2.inc") can use this new feature. There is work ongoing to bring all of these plugins up to date.
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, 2025Oracle JavaVM (OJVM) Detection Update Summary Authenticated...
Oracle JavaVM (OJVM) Detection Update Summary Authenticated scans launched against Oracle database hosts will no longer report Oracle JavaVM (OJVM) patches as missing if the OJVM component is not installed. Change A series of plugins are used to detect Oracle Database patch levels. With local checks enabled plugin 71644 gathers the patch information of the Oracle Databases detected. With remote checks enabled (i.e. authenticating into the Database without authenticating in the OS) it is plugin 45624 that will gather the patch information from the Database. While plugin 71644 alone cannot detect the presence of OJVM, users can leverage plugin 45624 to detect the installation status of that component.This limitation of 71644 results in Oracle CPU plugins reporting missing OJVM patches, despite OJVM not being installed. Although reporting these missing patches follows Oracle’s best-practice guidelines, numerous customers have requested the ability to silence these reports when enabling Oracle Database remote checks in the same scan. Following this update, scans will no longer report OJVM patches as missing if the component is not found as installed by plugin 45624. To achieve this result, scans need to be provided with both OS credentials and Oracle Database credentials, and successful authentication must occur with both sets of credentials. Impact In remote scans, Oracle JavaVM vulnerabilities will only be reported if Oracle JavaVM is installed when scanned with both OS and Oracle Database credentials. This change has no impact on Nessus Agent scans, as remote database connections are no possible. Impacted Plugins 45624 (Oracle RDBMS Host Name and Patch Info) All Oracle CPU plugins pertaining to Oracle Databases. Target Release Date Tuesday, September 19, 2023
