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, 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, 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 CenterVMware Integration vSphere 9.0 Compatibility
Summary We are pleased to announce that Tenable's VMware integration for vulnerability scanning now supports VMware vSphere 9.0 (ESXi 9.0 and vCenter Server 9.0). These updates will be available in Tenable Vulnerability Management, Nessus, and Tenable Security Center. Change Tenable has updated its VMware integration to support VMware ESXi 9.0 and VMware vCenter Server 9.0. Authenticated vulnerability scans can now be performed on these targets without the need for additional credential setup. VMware vSphere 9.0 compatibility covers the following scenarios: VMware ESX SOAP API authenticated scans against ESXi 9.0 hosts VMware vCenter API authenticated scans against vCenter Server 9.0 VMware vCenter auto-discovery flows for 9.0 hosts For more information see our user documentation: Welcome to Tenable for VMware Impact No impact to current scans are expected; existing ESXi 8.x and earlier vCenter scans continue to work as before. If customers encounter issues with this integration, please open a ticket with Technical Support. Tenable will engage with VMware as needed to identify and resolve any issues. Release Date Available Immediately (May 27, 2026) for Tenable Vulnerability Management, Nessus, and Tenable Security Center Note: TDB for updates to enable VMware ESXi 9.0 and VMware vCenter Server 9.0 compatibility with Compliance and Audit scanning.