New Windows DACL Compliance Check Types Now Available
Summary Tenable is pleased to announce the release of three new atomic compliance check types for Windows auditing: FILE_DACL, REGISTRY_DACL, and SERVICE_DACL. These check types give audit authors a cleaner, more expressive way to assess discretionary access control list (DACL) permissions on files, registry keys, and services. Change These check types improve upon FILE_ACL, REGISTRY_ACL, and SERVICE_ACL check types. The rename to DACL reflects the correct Windows security terminology and aligns with how permission auditing is actually described in benchmarks and hardening guidance. The Audits & Compliance team will be using these check types for all published audits going forward and will be updating existing content to use them. Impact Easier check writing - Each permission check is a single, self-contained atomic check. There is no need to pair a check with a companion ACL structure. The access control criteria are expressed directly in the check itself, reducing the surface area for authoring errors. Easier tailoring - Because all relevant information lives within the atomic check block, policy customization is straightforward. Reviewers, implementers, and content consumers can read exactly what a check requires without cross-referencing a separate structure in the .audit file. Documentation - Usage and examples are available in the Nessus Compliance Checks Reference: FILE_DACL https://docs.tenable.com/nessus/compliance-checks-reference/Content/FILE_DACL.htm REGISTRY_DACL https://docs.tenable.com/nessus/compliance-checks-reference/Content/REGISTRY_DACL.htm SERVICE_DACL https://docs.tenable.com/nessus/compliance-checks-reference/Content/SERVICE_DACL.htm Target Release Date August 27, 2026Research Release Highlight: HTTP/3 Detection Support in NASL Plugins
Summary This update introduces a significant infrastructure enhancement for NASL plugins, enabling support for the HTTP/3 protocol. While the underlying framework now supports HTTP/3, there are currently no plugins that leverage the HTTP/3 protocol. Individual plugins will be updated by Tenable as appropriate to utilize this capability over time. Change The core of this update will allow NASL plugins to dynamically negotiate and utilize either HTTP/1 or HTTP/3 for requests. We are releasing http3_detect.nasl (Plugin ID: Pending) as the initial plugin to leverage this new framework, providing the foundation for future protocol-aware detections over UDP. To utilize HTTP/3, customers must explicitly enable 'UDP port scanning', 'Search for SSL/TLS/DTLS services' and set an appropriate port range in ‘Search for DTLS on’ within their scan policy settings. Care should be taken as UDP port scanning can significantly slow down scans. Customer Impact Existing plugins remain unaffected and will continue to operate over HTTP/1 unless specifically updated by the Tenable Research team. The introduction of http3_detect.nasl serves as the first step in broader protocol support without impacting current scan performance for non-UDP focused scans. Target Release Date August 10, 2026
Improvement 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
NuGet Package Enumeration Updates
Summary Tenable has updated the NuGet package enumeration plugins to improve detection of installed NuGet packages on Linux/Unix scan targets. Change Before this update, the NuGet package enumeration plugins did not attempt to associate detected packages with an RPM or DEB package managed by the Linux distribution. This could cause packages to report vulnerabilities both based on a Linux distribution vendor's advisory and a CVE advisory from the NuGet package maintainer. After this update, these issues have been addressed. NuGet 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. Impact Most customers will notice improved accuracy in NuGet package vulnerability reporting. Scan results may show changes in detected vulnerabilities based on how packages were previously assessed. Affected plugins 190687 - NuGet Installed Packages (Linux / Unix) Target Release Date June 1, 2026
Cisco Meraki API Host Guidance
Summary Tenable is announcing changes to our documentation for the Cisco Meraki API integration. Customers using a “unique” host in the “Cisco Meraki Host” field of the credential should use “api.meraki.com”, or a region-specific instead if applicable. Please refer to the documentation for full guidance. Tenable and Cisco Meraki Integration Guide Impact Customers using the Cisco Meraki API integration are encouraged to check their configurations and update them accordingly. This change in guidance addresses cases where some customers were experiencing HTTP 308 redirects, resulting in integration failures. This is also closely related to cases where customers were experiencing HTTP 403 errors, which has been addressed by changes in the Cisco Meraki API Web Application Firewall (WAF). Release Date Dec 15th, 2025Improved Linux RPM Package Handling
Summary Improvements have been made to our rpm2 package handling library to increase speed and efficiency. Specifically, the package data collected during a scan in each rpm-list KB item is parsed and preserved into the KB, allowing them to survive between plugin executions. As a result, the work of parsing that data is now only done once, instead of once per plugin execution. Additionally, support for performing rpm checks against Source Packages has been added. This allows plugins to make a single call to perform checks against all of a Source Package’s associated Binary Packages. Change Improved Package Handling Instead of storing RPM package data in a variable that disappears after plugin execution, our rpm2 package handling library now stores that data in the KB using the following format: Host/rpm/pkg/<package name>= RPM Name In the event that there are multiple versions of the same package, they each get stored under the package name: Host/rpm/pkg/<package name>= RPM Name (ver 2.1.3) Host/rpm/pkg/<package name>= RPM Name (ver 2.4.0) This allows easy organization and retrieval by the rpm2 package handling library. Once all the package data is stored in the KB, we add this additional item: Host/rpm-processed=1 If this KB item is found, it indicates that we’ve already parsed and stored the package data and do not need to do so again. Top-level library functions that calling plugins leverage have been updated to use these new KB items. Source Package Support A “source” argument has been added to key library calls to also perform a Source Package Check against the given reference when handling rpm packages to determine all the associated Binaries of the specified Source Package and perform normal rpm checks on each. Each of the associated Binary Packages will be reported accordingly, and if any were vulnerable installs were found on the host, the initiating rpm check call will return 1 Example: my_source_package builds: my_bin_package A, my_bin_package B, my_bin_package C rpm_check(reference:my_source_package, source:true) -> rpm_check(reference:my_bin_package A) returns 0 -> rpm_check(reference:my_bin_package B) returns 0 -> rpm_check(reference:my_bin_package C) returns 1 At least one bin package was vulnerable, so return 1 Impact No change is needed for plugins already using rpm2 package handling library to take advantage of these Package Handling improvements.Customers will see the exact same results as they would have before this change, but their scans may be slightly faster. Note: Currently no plugins take advantage of the new library Source Package Support functionality. Target Release Date April 29, 2026
Research Release Highlight - Potential Vulnerabilities
Summary In this Release Highlight, Tenable Research is officially introducing Potential Vulnerabilities. A potential vulnerability is a finding that has a lower degree of certainty as to whether the assessed application is or is not vulnerable. The family of Potential Vulnerabilities consists of six categories: Backported, Managed, Component, Configuration Checks, Low Fidelity Checks and Incomplete or Unknown Version. The vulnerable findings surfaced by detection plugins will be tagged and reported appropriately to distinguish potential vulnerabilities from regular findings, while indicating which Potential Vulnerabilities category(ies) they correspond to. Potential vulnerabilities for Component installations are shown in scan results by default, but can be hidden by disabling the relevant scan setting. To modify this setting in your scan policy, go to Settings > Assessment > Accuracy > Override Normal Accuracy > Assess component installs for potential vulnerabilities. Please refer to this article for more information on Component scanning. The visibility of potential vulnerabilities for Backported and Managed installations remains unchanged and will continue to rely on the scan’s paranoid status. Please refer to this article for more information on Paranoia scan settings. Overview At this time, Tenable Research has identified six cases that lead to vulnerability findings with a reduced degree of certainty. Each one serves as a potential vulnerability category: Backported applications Nessus often relies on applications’ banners to detect them remotely (i.e. without auth), but the practice of backporting makes application banners less reliable sources of information. A detected application’s backported banner may often advertise the same application version as a non-backported banner, with little to no indication of its backported nature. Nessus attempts to mark application banners as backported whenever possible and subsequent vulnerability checks against applications whose banners are deemed backported produce findings that are considered to have a reduced degree of certainty. Managed applications Detected application binaries on Linux systems are sometimes associated with packages that are distributed and managed by the Linux distro through the distro’s package manager. These binaries often carry different vulnerabilities and security fixes than their non-managed counterparts and even their counterparts managed by other distros. Nessus attempts to associate binaries to distro-managed packages and performs distro-specific vulnerability checks against any binaries that are found to have such an association. In an effort to provide the widest vulnerability coverage possible for Tenable customers, non-distro-specific vulnerability checks (like those in the ‘Misc’ plugin family) may still assess managed binaries, but their findings are considered to have a reduced degree of certainty. Component applications Entire applications or application binaries that Nessus detects may sometimes be bundled with another application as one of its components. The main application typically manages its component applications, making it very challenging or impossible to directly remediate a vulnerability identified in a component (e.g. by updating or removing it) without adversely affecting the main application. Nessus attempts to identify component applications and any subsequent vulnerability checks against applications marked as components produce findings that are considered to have a reduced degree of certainty. Configuration Checks Some vulnerabilities may affect an application only when running in a specific configuration. While performing a configuration check provides a higher degree of certainty, detection plugins sometimes report a vulnerable version based only on the version number without performing the required configuration check. Generally this will be the case when Nessus is unable to perform the configuration check, or the method of performing the configuration check is not (publicly) available. In these cases, the vulnerable findings surfaced by detection plugins are considered to have a reduced degree of certainty. Low Fidelity Checks Some vulnerabilities may require many different or complex conditions to be met to be considered truly present. In some cases, vulnerability detections may instead perform a simpler series of checks, without performing all of the necessary conditional checks. This category includes other lower-confidence detection workflows that a detection plugin may opt to perform out of necessity. For example, drawing important decision-making data from less reliable sources or selecting a version to compare against out of multiple detected. In all these scenarios, the findings are considered to have a reduced degree of certainty. Incomplete or Unknown Version The detected version of an application may sometimes not be granular enough to confidently determine the vulnerability status of that application. This also includes cases where a version number is present but the necessary hotfix, patch, etc. data is missing. And cases where we cannot obtain a version and can only detect the presence of the product (ex: the version is hidden behind a login page)These findings are considered to have a reduced degree of certainty. Vulnerability detection plugins have long recognized Backported or Managed installations, factoring this information into each plugin’s vulnerability checking logic. This capability has recently been extended with Component installations. The remaining three potential vulnerability categories, i.e. Configuration Checks, Low Fidelity Checks, Incomplete or Unknown Version, are set to release later in 2026. Changes in Vulnerability Detections Vulnerability detection plugins are enhanced with this release to take the six Potential Vulnerability categories into account when reporting vulnerable findings. Their reports will now include a dedicated line of output indicating whether the vulnerability finding is potential and the potential vulnerability category it corresponds to. The following are a few examples of the expected changes in vulnerability detection plugin output, when a Potential Vulnerability is found and reported. Note that these results stem from Paranoid scans, with Component scanning enabled. Backported applications A vulnerable instance of the Apache HTTP server is running on a Linux host. It is identified as backported based on its banner, which indicates that it is a CentOS-specific release: Before Apache vulnerability plugins (like 100995, whose output is shown below) are currently flagging this instance as vulnerable without marking it as a potential vulnerability: After With the changes introduced, these vulnerabilities are marked as potential due to the Apache instance being backported: Component applications A vulnerable instance of Sqlite is found on a Windows host, as a component of the YourPhone built-in Windows app, This instance of Sqlite is bundled with and managed by the YourPhone application. Before Vulnerability plugins (like 242325, whose output is shown below) are currently flagging this instance as vulnerable without marking it as a potential vulnerability: After With the changes introduced, these vulnerabilities are marked as potential due to the Sqlite instance being a component of another application: Managed applications A vulnerable instance of Sqlite is found on a Linux host. This instance of the app has been installed by the OS’ package manager and is therefore managed by the OS. Before Vulnerability plugins (like 242325, whose output is shown below) are currently flagging this instance as vulnerable without marking it as a potential vulnerability: After With the changes introduced, these vulnerabilities are marked as potential due to the Sqlite instance being managed by the OS: Impact This release brings new plugin output for vulnerable findings of application installations tagged as Backported, Managed or Component. Future releases will add similar new plugin output for the remaining three Potential Vulnerability categories (Configuration Checks, Low Fidelity Checks, Incomplete or Unknown Version). Over time, Tenable Research will expand the number of detections that tag application installations as Components and vulnerable findings with the appropriate Potential Vulnerability category. Target Release Date 06 APR 2026
Tenable Post-Quantum Cryptography Inventory Support
Summary The advent of quantum computing presents a significant threat to current cryptographic algorithms. Organizations worldwide are beginning the critical transition to post-quantum cryptography (PQC) resistant algorithms to ensure long-term data security. Government mandates, such as the U.S. National Security Memorandum 10 (NSM-10), outlines deadlines for PQC migration and specific actions agencies must take to migrate vulnerable systems. Our PQC support is designed to help customers inventory use of TLS and SSH quantum-resistant and vulnerable algorithms within their infrastructure using remote Nessus-based scans. Cipher Inventory and Reporting Post-Quantum Cipher Plugins Two remote-based scan informational reporting plugins for TLS and SSH protocols inform customers of their transition posture according to NIST Post-Quantum Encryption Standards. Services Using Post Quantum Cryptography: Reports on services equipped with at least one post-quantum cipher. It will specify which post-quantum ciphers were discovered, reporting by port and protocol. Services Not Using Post Quantum Cryptography: Reports on services that support no post-quantum ciphers. These plugins will be enabled by default and included in existing scans. Cryptographic Inventory Plugin Reporting To enable a JSON-based inventory of each target by service and cipher, enable through either a preference on your Advanced Network Scan or by running the Cryptographic Inventory scan template. These preferences will initially be supported in Nessus and Tenable Vulnerability Management. They are planned to be added to Tenable Security Center at a later date. Warning: Enabling this preference through the Advanced Network Scan is expected to increase the overall size of the plugin output per target and resulting Nessus database size. If you do not need to produce this inventory at all or on your regular scan cadence, it’s recommended to instead run the Cryptographic Inventory scan template to decrease the potential impact to your normal scan results. Options to Enable Inventory Reporting Advanced Scan Preference Post Quantum Cryptography Scan Template Cryptographic Inventory Plugin Details The plugin enabled with the preference or scan template is an information plugin called Target Cipher Inventory. Within the output of this plugin, you will find a JSON structure containing the TLS and SSH inventories for the scanned target. You can export this inventory based on plugin output using the Tenable API if needed. For TLS, the structure contains: Attribute Definition Encaps Protocol encapsulation employed such as TLSv1, TLSv2, TLSv3 Port Port used for TLS communication Curve Group Encryption method Ciphersuite Algorithm used to secure the TLS connection For SSH, the structure contains: Attribute Definition Proto Protocol of SSH Port Port used for SSH communication Name Algorithm used to secure the protocol Type Use of the named algorithm such as “message auth” Release Date Tenable Vulnerability Management and Tenable Nessus: December 8, 2025 Tenable Security Center: - December 8, 2025 for the informational plugins - Cryptographic Inventory scan template release to be determinedImprovement: 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, 2026Component 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, 2026
