Forum Widgets
Recent Discussions
Research Release Highlight: New Keeper Commander PAM Integration
Summary Tenable is proud to announce a new integration with Keeper Commander for use with Keeper Security providing streamlined privileged access in credentialed vulnerability scans. This integration is available in Tenable One Vulnerability Management and Tenable Nessus. Change Supported Credential Types: SSH, including privilege escalation (e.g., sudo) and SSH key-based authentication (with optional passphrase) SMB (Windows), including domain and Kerberos authentication Database: Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, DB2, Cassandra, Sybase ASE ESXi: VMware vSphere hypervisor credentials vCenter: VMware vCenter Server credentials Nutanix: Nutanix Prism Central credentials For comprehensive details regarding this integration, please refer to the Tenable user https://docs.tenable.com/Integrations.htm. Impact There is no disruption to existing scan configurations. Customers using Keeper Security for privileged access management are encouraged to adopt this integration for credentialed scanning to consolidate credential management and reduce risk from static credentials stored in scan policies. Release Date 8 October 2026 for Tenable One Vulnerability Management and Tenable Nessus TDB for Tenable Security Center
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, 2026Arcon Converged Identity (CI) Platform
Summary Tenable One Vulnerability Management and Tenable Security Center now fully support the Arcon Converged Identity (CI) PAM solution. Using the existing Arcon PAM authentication type alongside Digital Vault API configuration, customers with Arcon CI-PAM can seamlessly retrieve credentials during scans. Change No new scan configuration fields or credential types are required. Customers using Arcon CI-PAM should configure the Authentication URL and Engine URL to point to the Digital Vault API base path (e.g. dv/api/sdk), as with Arcon DV deployments. Impact No changes to existing scan configurations are required. Customers currently using the legacy Arcon PAM API path are unaffected. Release Date 8 September 2026 for Tenable One Vulnerability Management, Nessus and Tenable Security CenterNew Microsoft Azure Key Vault Integration
Summary We are pleased to announce that Tenable's credentialed scanning now supports Microsoft Azure Key Vault as a Privileged Access Management (PAM) integration. This will be available in Tenable One Vulnerability Management and Tenable Nessus Immediately. Change Tenable's credentialed scanning has been updated to include Microsoft Azure Key Vault as a new authentication method. Security teams can now store privileged credentials in Azure Key Vault and have Tenable retrieve them automatically at scan time using OAuth2 client-credentials authentication with a Microsoft Entra ID service principal. Credentials such as sensitive passwords and SSH private keys are maintained centrally inside the vault, they are never stored in Tenable scan policies and can be rotated seamlessly without requiring manual policy updates. The Azure Key Vault integration supports the following credential types: SSH Windows (SMB) Database (Oracle, SQL Server, MySQL, PostgreSQL, DB2, MongoDB) VMware ESXi SOAP API VMware vCenter API Nutanix Prism Central Each Key Vault secret is expected to hold a JSON object containing one or more of the fields username, password, ssh_key, ssh_keyphrase, and domain, so a single secret can drive both password and SSH private-key-based target authentication. For SSH targets, privilege escalation may optionally reference a separate Key Vault secret whose password field is used as the sudo/su password. For more information see our Microsoft Azure Key Vault Integration user documentation: https://docs.tenable.com/Integrations.htm Impact No impact to current scans are expected; If customers encounter issues with this integration, please open a ticket with Technical Support. Release Date September 3, 2026 for Tenable One Vulnerability Management and Nessus TBD for Tenable Security Center
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, 2026Arcon PAM New Digital Vault API Support
Summary Tenable is proud to announce expanded support for the Arcon Privileged Access Management (PAM) integration in Nessus. The integration now supports the Arcon PAM Digital Vault (DV) API. Customers who have migrated to Arcon DV deployments can now retrieve credentials through Nessus scans without requiring new credential types or additional scan configuration fields. This integration automatically selects the correct API path based on the Authentication URL and Engine URL configured in the scan credential. If the configured URLs contain dv/api/sdk, the Digital Vault path is used; otherwise the legacy path is used. No new scan configuration fields are required. Further information regarding these changes and configuration guidance for both API paths can be found in the Arcon section of Tenable's Integrations documentation page. Change The Arcon PAM credential now supports the Digital Vault API path alongside the existing legacy API. The DV path uses a distinct authentication endpoint and credential retrieval endpoint. These differences are handled automatically by the integration based on the URLs the user configures. Customers on DV deployments should set the Authentication URL and Engine URL to point to the DV base path (e.g. dv/api/sdk). Impact Existing scan configurations using the legacy API path remain unaffected. No changes to existing scan configurations or credentials are required for customers already using the legacy API. Release Date August 25, 2026 for Tenable One Vulnerability Management and Nessus TBD for Tenable Security Center
Research Release Highlight - VMware ESXi 7.0 SEoL Update
Summary Tenable is updating the VMware ESX / ESXi Unsupported Version Detection plugin (56997) to track the vendor's End of General Support (EoGS) date rather than the End of Technical Guidance (EoTG) date. Change Before this update, Plugin 56997 determined unsupported status for VMware vSphere/ESXi 7.0 using the vendor's End of Technical Guidance (EoTG) date of April 2, 2027. EoTG marks the point at which the vendor's support becomes best-effort only; it does not reflect when the vendor actually stops shipping security patches. After this update, Plugin 56997 will use the vendor's End of General Support (EoGS) date instead, which is when the vendor discontinues security patches and critical bug fixes. This date for VMware vSphere/ESXi 7.0 EoGS is October 2, 2025. Impact Customers running VMware vSphere/ESXi 7.0 outside of the EoGS support window will now see a correct “unsupported” finding from Plugin 56997. This will introduce new critical findings into scan results for customers who have the unsupported version. Hosts that had previously been identified as unsupported should see no change to those findings. Detection plugins 56997 - VMware ESX / ESXi Unsupported Version Detection Target Release Date November 2, 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