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