Forum Widgets
Recent Discussions
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 determined
CyberArk 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.AuditLang VSCode Extension Summary Tenable has created a...
AuditLang VSCode Extension Summary Tenable has created a Visual Studio Code extension to assist with custom audit writing and validation. Features include: Syntax highlighting Check snippets Command shortcuts for Compliance Checks reference documentation, download links, etc. Parse/Syntax checking For up-to-date features and installation information you can search for 'Tenable AuditLang' in VS Code -> Extensions: Marketplace, or visit https://marketplace.visualstudio.com/items?itemName=Tenable.vscode-auditlang If you have any use cases you’d like to see added to the extension, please either contact your CSM or add a suggestion through the Tenable Products Suggestion Portal. Please use your Community credentials to access the suggestions portal and choose the product “Plugins, Audits, and Compliance” on submittal. Target Release Date ImmediateImprovement: Handling Component Installs for Vulnerability Assessment
Background On Friday, February 6, 2026, Tenable Research published a plugin update that changed the way component installs are assessed for vulnerabilities. Those changes are outlined in a previous release highlight: Component Installs Require Paranoid Checks, This update essentially reverts this change, while adding new functionality to allow users to choose whether or not they want component installs assessed for vulnerabilities. Component installs are no longer influenced by scan paranoia settings. What are “Component Installs”? Software components, such as applications or language modules/libraries, are installed and managed by a primary "parent" package or application. The crucial point is that these components often cannot be updated individually. Instead, their vulnerability assessment and upgrade are entirely dependent on an update of the parent package. For instance, the SQLite database component is installed as part of the Trend Micro Deep Security Agent and is updated only when the Agent itself is updated. Nessus uses several factors to determine if a detected product is a component, or a standalone installation, including: Was the product installed by a package manager? These products are not considered components, as they are managed by the package manager and not a “parent” application Is the component a “language library”, i.e. a library or module used by the interpreter of a programming language like Python or Node.js? These enumerated libraries are marked as components by default. Does the product reside in a directory that is recognized for installations that are not component-based? Changes By default, component installs are once again assessed for vulnerabilities, as was the case prior to the release of the aforementioned update. If users wish to turn this setting off, so that component installs will not be assessed by generic vulnerability detection plugins, they can do so via the newly created scan preference. The end result of this change should be that fewer “false positives”, i.e. reported vulnerabilities for components that are “owned” by another application, are shown in scan results. Components with vulnerabilities that cannot be addressed independently of the “parent” application will not show in scan results. However, some customers have expressed a desire to see these vulnerabilities in their scan results anyway, to ensure full awareness of the risk profile of every application in their environment. This is still possible through the updated scan configuration settings. To modify this setting in your scan policy, go to Settings > Assessment > Accuracy > Override Normal Accuracy > Assess component installs for potential vulnerabilities. This setting is ON (checkbox is ticked) by default, so users must enable the Override Normal Accuracy checkbox (which is OFF / unchecked by default) if they wish to disable the setting and ensure that component installs are not assessed by generic vulnerability detection plugins in this scan. Please note that this update makes no other changes to the existing paranoia logic, outside of what is described above. For now, “Managed”, “Managed by OS” and “Backported” installs are still controlled by the Show/Avoid potential false alarms radio button. How can I tell if the detected install is a component or not? In addition to the above, we have also updated the relevant detection plugins so they will show if the component flag is set or not. At present, this includes detection plugins for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, Python Packages, Node.js modules and, soon to follow, Ruby and Nuget libraries. Using plugin ID 174788, SQLite Detection (Windows), here is a before and after example of the expected plugin output. Before: After: Expected Impact With the new default setting in place, users should anticipate an increase in vulnerability findings for the products in scope, returning to a level similar to what was observed before the first update. If users do not wish to surface these additional potential vulnerabilities, they should disable the "Assess component installs for potential vulnerabilities” setting. If the new scan preference is disabled, the volume of findings will remain consistent with current levels, when scanning with normal accuracy (paranoia) settings. Affected Plugins 12288, global_settings.nasl (updated to support the new scan policy preference) Any plugin that operates downstream of those in the list below: SQLite: 174788 - sqlite_nix_installed.nasl 171077 - sqlite_win_installed.nasl OpenSSL: 168007 - openssl_nix_installed.nasl 168149 - openssl_win_installed.nasl Curl: 182774 - curl_nix_installed.nasl 171860 - curl_win_installed.nasl LibCurl: 182848 - libcurl_nix_installed.nasl Apache HTTPD: 141394 - apache_http_server_nix_installed.nasl 141262 - apache_httpd_win_installed.nasl Apache Tomcat: 130175 - apache_tomcat_nix_installed.nasl 130590 - tomcat_win_installed.nasl Python Packages: 164122 - python_packages_installed_nix.nasl 139241 - python_win_installed.nasl Node.js Modules: 178772 - nodejs_modules_linux_installed.nasl 179440 - nodejs_modules_mac_installed.nasl 200172 - nodejs_modules_win_installed.nasl Targeted Release Date Tenable Nessus and Vulnerability Management: Monday, March 9, 2026 (ETA 22:30 Eastern Standard Time) Tenable Security Center: Monday, March 16, 2026
