Improvement To Plugin 142960 “HSTS Missing From HTTPS Server (RFC 6797)”
Summary Plugin 142960 now validates the identity of an HTTPS service in line with the current RFC 9525 as opposed to the obsolete RFC 6125. When a service's TLS certificate contains Subject Alternative Name (SAN) entries, the plugin compares the target hostname against those SANs only and no longer considers the certificate's Common Name (CN). If the certificate has no SANs, the plugin falls back to using the CN, so coverage for legacy certificates is unchanged. Background Plugin 142960 checks whether a detected web server supports HTTP Strict Transport Security (HSTS). Before it evaluates the service, the plugin must confirm that the service's TLS certificate covers the identity of the host. This confirms that the server is authorized to answer for that host, and that the finding describes the target host and not whichever service happened to respond on its behalf. If the identity check fails, the plugin cannot evaluate the service. Until now, the plugin performed this check by comparing the resolvable hostname against the CN of the certificate presented on the relevant port. If the CN covered the hostname, the service was evaluated for HSTS. RFC 9525, which supersedes the identity-matching guidance in RFC 6125 (which allowed for the checking of CNs) states that when a certificate carries one or more SAN entries, hostname identity must be validated against those SANs only. The CN must not be used for this purpose, even if it matches the hostname. The RFC gives several reasons: the CN is ambiguous, it cannot hold multiple identifiers, and its use leads to security and parsing inconsistencies. This change was prompted by a case in which a host's service could only be identified through the SAN of its certificate and not through the CN. Research into that case led to RFC 9525, and the update follows its guidance. Changes Service identity validation in plugin 142960 now works as follows: If SANs were enumerated from the service's TLS certificate, the hostname is compared against the SANs only. The CN is not used, even when it matches the hostname. If no SANs were enumerated from the certificate, the plugin uses the CN to validate the service identity, as it did before. Impact For services whose certificates include SANs, the outcome of the identity check depends only on the SAN values. A service whose SANs cover the hostname but whose CN does not will now be validated and evaluated for HSTS. A service whose CN matches the hostname but whose SANs do not will no longer pass validation, so the plugin will not evaluate it. Services with certificates that have no SANs are evaluated as before. Affected Plugins 142960 - HSTS Missing From HTTPS Server (RFC 6797) Targeted Release Date Monday, October 12, 2026Plugin Support - TuxCare Extended Support
Summary Tenable is introducing vulnerability detection plugins for Linux distributions covered by TuxCare's extended lifecycle support programs. Customers using TuxCare's Enterprise Support will now receive accurate vulnerability findings that account for patches delivered by these third-party vendors. Change Before this update, Tenable had no dedicated vulnerability detection for TuxCare's third-party support advisories. Hosts running distributions covered by this extended support program were not recognized as having access to third-party patches, which could result in inaccurate or missing findings for vulnerabilities that TuxCare had already addressed. After this update, Tenable will publish plugins sourced directly from TuxCare advisory feeds. These plugins detect vulnerabilities for which third-party patches are available from TuxCare. Additionally, existing unpatched vulnerability plugins will be updated to check for third-party patch availability, preventing false positive unpatched findings on hosts with an active TuxCare subscription. Note: Findings resolved by these plugins require an active paid subscription to TuxCare's extended lifecycle support service. Impact Customers running TuxCare-supported distributions will receive dedicated vulnerability coverage for those environments. Customers who have already applied available third-party patches may see previously reported unpatched findings correctly resolved. Customers who have not yet applied available patches will see new findings corresponding to vulnerabilities addressed in TuxCare advisories. Target Release Date September 28, 2026Plugin Support - CIQ Extended Support
Summary Tenable is introducing vulnerability detection plugins for Linux distributions covered by CIQ's extended lifecycle support programs. Customers using CIQ's extended support, CIQ Bridge for CentOS 7, Rocky Linux Long-Term Support, and RLC Pro, will now receive accurate vulnerability findings that account for patches delivered by these third-party vendors. Change Before this update, Tenable had no dedicated vulnerability detection for third-party support advisories published by CIQ. Hosts running distributions covered by this extended support program were not recognized as having access to third-party patches, which could result in inaccurate or missing findings for vulnerabilities that CIQ had already addressed. After this update, Tenable will publish plugins sourced directly from CIQ advisory feeds. These plugins detect vulnerabilities for which third-party patches are available from CIQ. Additionally, existing unpatched vulnerability plugins will be updated to check for third-party patch availability, preventing false positive unpatched findings on hosts with an active CIQ subscription. Note: Findings resolved by these plugins require an active paid subscription to CIQ extended lifecycle support service. Impact Customers running CIQ-supported distributions will receive dedicated vulnerability coverage for those environments. Customers who have already applied available third-party patches may see previously reported unpatched findings correctly resolved. Customers who have not yet applied available patches will see new findings corresponding to vulnerabilities addressed in CIQ advisories. Target Release Date September 28, 2026
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
Research Release Highlight – "Fully Scan Operational Technology" Default Setting Change
Summary The "Fully Scan Operational Technology" (OT) preference controls whether Nessus actively scans OT/ICS devices during a scan. This setting is intended to be disabled by default to avoid unintended disruption to sensitive operational technology environments. A long-standing setting in the Do not scan operational technology devices plugin caused this preference to default to enabled in a Basic Network Scan when the discovery type is not set to Custom. Change The default value for "Fully Scan Operational Technology" preference has been corrected from yes to no. Impact This fix will affect existing Basic Network scans automatically upon the next feed update — no scan recreation is required. Customers using Basic Network Scan policies with a non-custom discovery scan type will see the following behavioral change: Before change: "Fully Scan Operational Technology" was silently enabled, meaning OT devices may have been actively scanned. After change: "Fully Scan Operational Technology" will correctly default to disabled. Customers who intentionally want to scan OT devices should explicitly enable the "Fully Scan Operational Technology" preference by switching their scan policy's discovery type to Custom, which will expose the preference in the UI and allow it to be toggled on. Affected products: Tenable Security Center (SC), Tenable Vulnerability Management (TVM), and Nessus Target Release Date July 13, 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, 2026Plugin output for language library enumeration
Summary The plugins that enumerate Node.js, Python, and Ruby packages will now list the discovered packages in their output. Change Before this update, Tenable had updated some of the “language library” enumeration plugins - specifically for Node.js, Python, and Ruby - so that they would no longer list the discovered packages in the plugin output. This was a performance-related decision. When scanning assets with a substantial number of discovered packages, Tenable found that in many cases the size of the findings set would be so large that it would exhaust the memory allocated to the plugin and cause the plugin to crash without reporting. This would prevent downstream vulnerability plugins from detecting vulnerable packages and result in false negatives. Tenable found this to be a less desirable outcome, and began investigating solutions to make these findings sets available at the platform level. Customer feedback has led us to revert this change and develop an alternative solution for reporting from these plugins. After this update, the plugins below will now list the discovered packages, along with their path and version, in the plugin output, which can be used to locate specific installed packages on assets. Tenable will continue to investigate a platform-level feature to allow customers to locate specific language libraries across all managed assets in Tenable One. Impact Plugin output for updated plugins will include a list of detected packages. This may substantially increase the size of scan results in accordance with the number of detected packages. Plugins 200172 - Node.js Modules Installed (Windows) 179440 - Node.js Modules Installed (Linux) 178772 - Node.js Modules Installed (macOS) 181215 - Python Installed Packages (Windows) 164122 - Python Installed Packages (Linux/macOS) 240646 - Ruby Gem Modules Installed (macOS) 207585 - Ruby Gem Modules Installed (Windows) 207584 - Ruby Gem Modules Installed (Linux) Target Release Date April 27, 2026
Stop Guessing, Start Securing: New Secrets Validation for WAS
Finding a leaked credential in your web application is a bad day. Finding out that credential is live and grants access to your GitHub or cloud environment? That’s a crisis. To help you distinguish between a harmless string of text and a major security hole, we’ve launched Secrets Validation for Tenable Web App Scanning (WAS). Turn maybe into action You no longer have to manually test every API key or token your scanner unearths. When Tenable WAS identifies a sensitive credential—like a GitHub token—it now goes a step further. Our Validated Secret Detected plugin safely attempts to connect to the service to verify if that secret is live and exploitable. Why this matters for you: Prioritize with confidence: You can stop chasing "dead" keys and focus your remediation efforts on secrets that actually pose a real-world risk. Clear visibility: If a secret is valid, we flag it clearly in your results, giving you the evidence you need to escalate the fix immediately. Broadening coverage: We are continuously expanding validation support across our existing library of detected secrets. How to get started You can find the full setup details in our Secrets Validation documentation. This feature enhances the detection capabilities already found in these key plugins: Generic Secret Disclosure: Credentials for private services. Third-Party Service Secret Disclosure: API keys for public cloud and SaaS platforms. AI Service Secret Disclosure: API keys for public AI services.
New Dell OS10 Compliance Plugin and Audit files
Summary Customers can now measure compliance against Dell OS10 devices with new plugin ID Dell OS10 Compliance Checks (275781) on Tenable Vulnerability Management and Nessus. This plugin is published as a part of the Policy Compliance template and will use the existing SSH credential type. The plugin will retrieve all target data using "show" commands and will evaluate actual values against a given audit policy. Three audits implementing the DISA STIG will be released along with the plugin: DISA Dell OS10 Switch Layer 2 Switch STIG v1r1 20 checks DISA Dell OS10 Switch NDM STIG v1r1 39 checks DISA Dell OS10 Switch Router STIG v1r1 42 checks These audits contain a total of 101 checks. Some examples include: OS10-NDM-000010 The Dell OS10 Switch must limit the number of concurrent sessions to an organization-defined number for each administrator account and/or administrator account type. OS10-NDM-000410 The Dell OS10 Switch must enforce password complexity by requiring that at least one uppercase character be used. OS10-L2S-000240 The Dell OS10 Switch must not use the default VLAN for management traffic. OS10-RTR-001040 The Dell OS10 Router must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces. Additional Notes For those that are interested in creating custom audit content for their environment, please see the plugin documentation for all supported keywords and uses at https://docs.tenable.com/nessus/compliance-checks-reference/Content/dell-os10.htm. Target Release Date Nessus/Tenable.VM - Immediate Tenable.sc - To be determined