Forum Widgets
Recent Discussions
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, 2025Delinea 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, 2025
Improved 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
Plugin 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
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 2026Improvement 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
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 determinedCyberArk PVWA Credentials from CCP
Summary Tenable is proud to announce an enhancement to credentialed scanning using CyberArk Auto-Discovery. Specifically, as it relates to how customers can manage Password Vault Web Access (PVWA) credentials in the CyberArk Vault, and fetch them from the Central Credential Provider (CCP). When using CyberArk Auto-Discovery, the scanner accesses the Password Vault Web Access (PVWA) API to enumerate accounts to be dynamically added as targets to the scan, and the scanner uses a username and password to authenticate to this API. This new feature offers the ability to store the username and password combination in CyberArk itself, eliminating the need to manually manage these credentials. New Feature The feature adds a new drop-down menu, named “PVWA REST API Authentication Type”, which has two options, “Username and Password” and “Gather from CCP”. “Username and Password” is the default and previous behavior of manually entering the PVWA username and password. “Gather from CCP” provides the ability to gather these values from the vault, by instead providing the Account Name (unique credential identifier) of the account containing PVWA credentials. Please note that this change only affects configurations using CyberArk Auto-Discovery as a Windows, Database or SSH authentication method, because these are the only integrations that interface with the PVWA. The following other integrations are unaffected by this change: CyberArk (without auto-discovery) CyberArk Secrets Manager CyberArk (Legacy) Additionally, this change requires a minimum Nessus scanner version of 10.10. Attempting to use this feature with an older Nessus version will fail with an error in the debugging log report which reads: Please note that fetching PVWA creds from the Central Credential Provider requires Nessus scanner version 10.10 or later. For more information, please refer to the CyberArk integrations documentation: https://docs.tenable.com/Integrations.htm Impact There is no change necessary for customer configurations. Customers with existing Auto-Discovery credentials will continue to use username and password authentication, but will have the option to try the new feature by selecting “Gather from CCP”. Release Date April 1st 2026 for T.VM and Nessus, TDB for T.SC
New Audit Attachments: Gold Image, XCCDF, and JSON Summary...
New Audit Attachments: Gold Image, XCCDF, and JSON Summary To support additional functionality and the export of compliance results, the following plugins have been developed: Compliance Export Gold Image Audit (174791) - a plugin that gathers the results of an existing compliance scan results and creates a “gold” image audit using the “known good” feature. The expected use of this feature is to scan a baseline target in your infrastructure, and then use the resulting audit to scan the rest of the targets to gauge how closely they match the baseline. This will replace the functionality that was previously provided by the python script at https://github.com/tenable/audit_scripts/tree/master/baseline. Compliance Export JSON (174790) - a plugin that gathers the results of an existing compliance scan and creates a JSON file attachment for each audit file that was executed on the scan targets. The JSON file will include data about the audit file, the scan, and the compliance results. The expected use of the files is to provide more precise export of compliance data from individual scan results. Compliance Export XCCDF (174792) - a plugin that gathers the results of an existing compliance scan and provides the results as an XCCDF format. The expected use of these files is to be imported into tools like STIG Viewer. A single XCCDF will be attached to the plugin for each audit file that contains DISA references. Each of these plugins will have to be enabled using the advanced general preferences found in the Policy Compliance Auditing and Advanced scan templates. The preferences names are: Generate gold image .audit Generate XCCDF result file Generate JSON result file When the plugins are enabled and compliance results have been generated, the results will become available in the Vulnerability category with the files attached to the plugin results. All preferences are turned off by default and recommended to only be used in instances where the attached files are required. Target Release Date Sep 15, 2023 Additional Notes Initial release is for Nessus and Tenable Vulnerability Management only. The preferences will be added to Tenable Security Center at a later date.
