Forum Widgets
Recent Discussions
Research 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
New AWS Secrets Manager PAM Integration
Summary Tenable is proud to announce our new AWS Secrets Manager Privileged Access Management (PAM) integration. Customers can store scan credentials in AWS Secrets Manager and have Tenable retrieve them at scan time directly inside Tenable. These updates are immediately available for Tenable Vulnerability Management and Tenable Nessus, with plans to release this feature at a later date for Tenable Security Center. Change With this addition, scans can authenticate to targets using credentials fetched from AWS Secrets Manager using AWS Signature Version 4. This integration retrieves the secrets (username, password, optional SSH key, and optional domain) at scan time and uses them for credentialed checks, eliminating the need to store target credentials in Tenable Vulnerability Management or Tenable Nessus. AWS Secrets Manager authentication method supports the following credential types: Windows SSH Database (PostgreSQL, MongoDB, Cassandra, DB2, MySQL, SQL Server, Oracle) VMware ESX SOAP API VMware vCenter API Nutanix Prism Central Support is provided for both long-lived IAM user access keys and temporary AWS STS session tokens. Additionally, you can utilize the Escalation Credential ID to reference a separate AWS secret for SSH credential privilege escalation. Impact No impact to current scans are expected; If customers encounter issues with this integration, please open a ticket with Technical Support. For comprehensive details regarding this integration, please refer to the Tenable user documentation. Release Date July 16 2026 for Tenable Vulnerability Management and Nessus; TBD for Tenable Security CenterNew Akeyless PAM Integration
Tenable is pleased to announce a new integration with Akeyless Privileged Access Manager (PAM) for streamlined privileged access in credentialed vulnerability scans. This integration is available in Tenable Vulnerability Management and Tenable Nessus. Supported Credential Types SSH — including privilege escalation (e.g., sudo) and SSH key-based authentication 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 Supported Authentication Methods The integration supports three methods for authenticating to Akeyless: Access Key — authenticate using an Akeyless Access ID and Access Key Universal Identity (UID) — authenticate using a Universal Identity token, supplied directly or read from a file on the scanner host Certificate (mTLS) — authenticate using a client certificate and private key Impact There is no disruption to existing scan configurations. Customers using Akeyless for privileged access management are encouraged to adopt this integration for credentialed scanning to consolidate credential management and reduce risk from static credentials. For comprehensive details regarding this integration, please refer to the Tenable user documentation. Release Date July 14, 2026 for T.VM and Nessus; TDB for T.SCHashiCorp Vault Integration - New SSH Certificate Authentication
Summary Tenable is proud to announce the addition of SSH Certificate authentication to our HashiCorp Vault integration. This feature allows customers to leverage HashiCorp Vault’s SSH Secrets Engine to retrieve signed SSH certificates during credentialed scanning for use in SSH authentication to target systems. Hence providing a more secure and streamlined approach to privileged access management. This update is now available in Tenable Vulnerability Management and Tenable Nessus, with plans to release for Tenable Security Center at a later date. By using the HashiCorp Vault with the SSH Signed Certificates option, users can centralize the management of their SSH secrets while reducing sprawling. Documentation for the Hashicicorp integration will be available on our documentation page. Supported Credential Types The HashiCorp Vault integration supports: SSH, including (least privilege, privilege escalation, SSH key authentication and SSH Signed Certificates). SMB (Windows), including domain configuration. SNMPv3 Database integration, including the following database types: Oracle SQL Server MySQL MongoDB PostgreSQL DB2 Cassandra Sybase ASE VMware vCenter API VMware ESX SOAP API Nutanix Prism Central Impact There is no impact to existing scan configurations.. Release Date Immediate; July, 6th 2026 for T.VM and Nessus, TDB for T.SC
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, 2026VMware 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.
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, 2026Delinea Platform Authentication Support
Summary We are proud to announce that Tenable’s Delinea Secret Server Privileged Access Management (PAM) integration can now use Delinea Platform Authentication method. These updates are immediately available for scans in Tenable Vulnerability Management and Nessus Manager, with plans to release this feature at a later date in Tenable Security Center. Change With this addition, instead of just connecting to the standalone Secret Server, scans can now authenticate via the Delinea Platform, leveraging centralized identity and the security of the newer Delinea architecture. Delinea Platform Authentication method supports following credential types for Delinea Secret Server mode: Windows SSH Database Nutanix VMware ESX SOAP API VMware vCenter API Delinea Platform Authentication method also supports following the credential types for Delinea Secret Server Auto-Discovery mode: Windows SSH Database For more information see our user documentation: https://docs.tenable.com/integrations/Delinea/Content/Introduction.htm Impact No impact to current scans are expected; If customers encounter issues with this integration, please open a ticket with Technical Support. Tenable will engage with Delinea as needed to identify and resolve any issues. Release Date 11 May 2026 for Tenable Vulnerability Management and Nessus; TBD for Security Center
Oracle RDBMS (Database and OJVM) Patch Mapping Improvements...
Oracle RDBMS (Database and OJVM) Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the active version of the Oracle RDMS’s Database and OJVM components. How Patch Mapping Works for Oracle Database Scans Prior to these improvements, the Database and OJVM versions were mapped from installed patches and their corresponding versions via a manually maintained mapping library, oracle_database_mappings.inc. Installed patches are enumerated in one of three possible ways: Linux Local Detections: oracle_enum_products_nix.bin (plugin ID 71642, requires SSH credentials) Windows Local Detections: oracle_enum_products_win.nbin (plugin ID 71643, requires SMB credentials) Direct connection to the Database via oracle_rdbms_query_patch_info.nbin (plugin ID 45624, requires Database credentials) The patch information is stored by the scanner in a temporary database known as the “scratchpad”, for later reference. Plugin ID 71644, "oracle_rdbms_patch_info.nbin", is then run and sets the patch level (version) by checking the detected patches against the mapping in "oracle_database_mappings.inc". Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As this mapping library is manually maintained, some patches were not mapped in time for vulnerability plugin releases, which is a semi-automated process. In the event that the target system has no patches installed that match a mapping from "oracle_database_mappings.inc", only the base version is reported (e.g 21.17.0.0.0), possibly resulting in False Positive findings. Improvements As we already have a complete list of installed patches and their descriptions stored in the aforementioned “scratchpad” we have added an additional layer of patch mapping over this. Plugin ID 71644, will now first attempt to parse the patch info directly from the scratchpad and map the installed patches to their corresponding versions based on the patch description. The existing mapping library is still checked, and a version comparison is performed to determine the highest patch level present. Plugin ID 71644 will now also report the patch levels (version) for the Database and OJVM components in its output. Expected Impact Improved accuracy in version detections for Oracle Database and OJVM resulting in less false positives in downstream vulnerability detection plugins Impacted plugins 71644, oracle_rdbms_patch_info.nbin 45624, oracle_rdbms_query_patch_info.nbin Targeted Release Date Monday, April 7, 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