Improved Printer Fingerprinting
Summary This document addresses an issue where network printers generate unnecessary prints when scanned, even with the "Don't Scan Printers" setting enabled. The fix involves improving the SNMP identification process for printers by falling back to default community strings and ports if an incorrect community string is initially configured. Background Currently, if a customer configures an incorrect SNMP v1/v2(c) community string for a device, Plugin ID 11933 / "Do not scan printers" fails to revert to using well-known, default SNMP v1/v2(c) community strings and ports, unlike other plugins. This failure can prevent accurate identification of network printers, leading to them being scanned and in some cases, may inadvertently queue print jobs on printers Impact The following assumes the user has enabled the "Do not scan printers" setting in their scan policy and the network printer is correctly identified as such: Potential Decrease in Reported Vulnerabilities: Network printers will be less heavily scanned, potentially leading to a decrease in reported vulnerabilities related to these devices. Slight Increase in Packet Traffic: There will be an increase of approximately three packets per host as the system attempts fallback SNMP connections. Printers Marked as "Dead": Network printers that are successfully identified via SNMP will be marked as "dead" and will not be scanned further. This change aims to enhance the effectiveness of identifying network printers using SNMP, thereby reducing unnecessary and potentially damaging traffic directed at these devices. The resulting decrease in reported vulnerabilities is an expected outcome, as identified printers will no longer be subjected to heavy scanning. Users can continue to scan network printers by enabling the "Scan Network Printers" setting under “Host Discovery -> Fragile Devices -> Scan Network Printers” in the scan policy. This ensures that printers are scanned and not marked as dead, irrespective of fingerprinting. Affected Plugins 11933 ( "Do not scan printers") Affected Scan Policy Settings Discovery -> Host Discovery -> Fragile Devices -> Scan Network Printers Tenable Security Center Tenable Vulnerability Management Tenable Nessus Target Release Date: Monday, September 15, 2025
Include/Exclude Path and Tenable Utils Unzip added to Log4j Detection
Summary Tenable has updated the Apache Log4j detection plugins. The Windows plugin will now honor the Include/Exclude Filepath configuration option. The Linux/UNIX plugin will now use the version of ‘unzip’ supplied with the Nessus Agent, when enabled in the Agent’s configuration, and correctly inspect the MANIFEST.MF and pom.properties files. Change Before this update, plugin 156000, Apache Log4j Installed (Linux / Unix), would fail to detect Log4j in specific scan scenarios. The plugin uses several inspection methods to determine if a JAR file is a copy of Log4j. During Nessus Agent scans, as well as scans with ‘localhost’ as a target, the plugin was not properly executing the unzip command to inspect META-INF/MANIFEST.MF and pom.properties files in the JAR archive. If this method was the only option that would result in a successful detection, the copy of Log4j would not be detected properly. In addition, the plugin had failed to launch the unzip binary supplied with the Agent when inspecting files in JAR archives. Note: The Nessus Agent can be configured to use find and unzip binaries that it provides, instead of those supplied by the asset’s operating system. See https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Agent_Performance_Options for more information. Also before this update, plugin 156001, Apache Log4j JAR Detection (Windows), would fail to honor the directories included or excluded for full-disk searches configured in the Windows Include Filepath and Windows Exclude Filepath directives in the Advanced Settings of a scan config. Note: Configuration of these options is described in https://docs.tenable.com/vulnerability-management/Content/Scans/AdvancedSettings.htm#Windows_filesearchOptions. After this update, plugin 156000 will use the Agent-supplied copy of unzip when configured to do so. If this option is not enabled in the scan config, the plugin will use the existing method to find and execute an archive utility supplied by the asset’s operating system. In either case, the plugin will properly inspect Log4j’s MANIFEST.MF and pom.properties files as a version source. Plugin 156001 already properly inspects these files. Also after this update, plugin 156001’s Powershell code will now honor directories included or excluded by the Filepath directives. Plugin 156000 already supported this feature. Impact When scanning Linux / UNIX assets via 'localhost' (i.e. scanning the scanner itself) or with the Nessus Agent, additional Log4j instances from MANIFEST.MF or pom.properties sources may be reported. For Linux Nessus Agents with "Use Tenable supplied binaries for find and unzip" enabled and "Agent CPU Resource Control - Scan Performance Mode" set to Low, plugin 156000 will now properly limit CPU usage during scans. As noted in the product documentation, “Note: Setting your process_priority preference value to low could cause longer running scans. You may need to increase your scan-window timeframe to account for this value.” Customers should be aware of this configuration setting and potential changes to the results provided in the Log4J detection results. When scanning Windows targets, Log4j JAR files stored in paths specified in the Windows Exclude Filepath configuration will no longer be detected. Log4j JAR files stored in paths or drives specified in the Windows Include Filepath configuration that had not been previously scanned will now be detected, assuming they can be assessed before the plugin’s configured timeout has been reached. Plugins 156000 - Apache Log4j Installed (Linux / Unix) 156001 - Apache Log4j JAR Detection (Windows) Target Release Date September 1, 2025Excluding the SUSE Linux Snapshots directory from Language Library enumeration
Summary The “language library” enumeration plugins will now exclude SUSE Linux’s snapshots directory when searching the filesystem. Change Before the update, when enumerating “language libraries” - such as Python packages, Node.js modules, etc. - on SUSE Linux hosts that use btrfs as their filesystem, reduced scan performance was observed. This is because btrfs creates and maintains snapshots in the /.snapshots directory, which can contain multiple redundant copies of files. This caused unnecessary processing on thorough scans. After the update, this snapshots directory has been excluded from searches executed by the find command for language library enumeration plugins on SUSE Linux. Impact This change is expected to improve the performance of scans on SUSE Linux assets. If language libraries were present in snapshots directory, they will no longer show up in Tenable scan results, along with any associated vulnerabilities. If customers would like to scan the snapshots directory, the "Include Filepath" option in the Advanced Scan Settings configuration can be used to force the scanning of these paths. Plugins 178772 - Node.js Modules Installed (Linux / Unix) 190687 - NuGet Installed Packages (Linux / Unix) 164122 - Python Installed Packages (Linux / Unix) 207584 - Ruby Gem Modules Installed (Linux / Unix) Target Release Date September 3, 2025
Nessus now has Windows LAPS Support
Summary: Nessus now has the ability to leverage accounts managed by Microsoft Windows LAPS. How LAPS works: Since LAPS managed accounts have their passwords rotated routinely, users cannot just directly provide the credentials in their Scan Policy. Before this change, users would instead have to make an additional privileged account on each LAPS enabled Host to provide to Nessus. Currently Nessus supports Entra LAPS allowing a scan to pull LAPS Managed Credentials from a customer’s remote Entra instance. Now, Nessus can do the same for Windows LAPS, allowing customers with local LAPS setups to gain the same benefits! Without Windows LAPS support, customers must make dedicated account for Nessus to use to scan targets Change: With this LAPS support change, during the startup phase of a scan, Nessus will reach out to a customer provided Domain Controller hosting an AD forest with LAPS enabled, and pull a list of all Local Admin Accounts for devices managed by LAPS. Nessus will then attempt to use these retrieved LAPS managed accounts as credentials when attempting to access a target host. With Windows LAPS Support, Customers need only provide a single Credential that allows Nessus to retrieve the actual credentials for LAPS Managed Devices How to enable it: To make use of Nessus’ Windows LAPS support, a customer needs only to provide the necessary info to their scan/policy via the Windows LAPS Credential. They’ll need to provide us the IP of the DC, Credentials for an account on that DC with the necessary permissions*, and the DistinguishedName of the OU that contains their LAPS managed devices. *The Account for retrieving Windows LAPS credentials needs the following permissions General Recommend the Account be added to the BUILTIN/Administrators AD Group as it grants all required permissions, including: Access to the $Admin Able to log on to the DC remotely Able to run Powershell WMI and DCOM access to Root/CIMV2 WMI Namespace LAPS Permissions LapsADReadPasswordPermission rights to the LAPS OU Be an Authorized Password Decryptor in the LAPS GPO (without this, Nessus will not be able to retrieve passwords protected by LAPS Encryption). Members of the Domain Administrators group are Authorized Password Decryptors by default. For additional information see: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview Impact: Customers using Rotating Host passwords managed through Microsoft Windows LAPS can now leverage these credentials in their Nessus scans for more secure scanning configurations. Target Release Date: Nessus, T.VM On/About 09 JUN 2025 T.SC TBDResearch Release Highlight - Changes to SMB Kerberos
Research Release Highlight - Changes to SMB Kerberos Summary Kerberos has been the default authentication mechanism for domain connected Windows devices since Windows 2008. Tenable credentialed scans of Windows targets support an explicit Kerberos credential type. The explicit credential, which names the DC and domain name, frees the Nessus sensor from having to be connected to the Windows domain being scanned and allows the scanner to be hosted on Linux or MacOS as well. The nature of this explicit Kerberos credential type has widely led to the expectation that a Kerberos scan of Windows will never use NTLM. That is not true. Currently Kerberos Windows scans will fail over to using NTLM if Kerberos does not succeed. The Kerberos protocol depends on time synchronization, FQDN target specification and bi-directional DNS name resolution, but NTLM does not. Tenable fails over to NTLM to preserve scan continuity where Kerberos on the target or scanner may not be configured correctly. As each Windows credential is tried, if Kerberos fails, a second attempt will be made using NTLM. Change We are changing Windows scans so that a scan will try all Windows credentials first before trying them again using NTLM if the credential set contains at least one Kerberos credential. This change also extends our Kerberos coverage to include Windows Configuration Manager and Active Directory Service Interfaces (ADSI) scans. Impact In certain customer environments where a single service credential (username/password) is used across multiple domains the current failover behavior causes NTLM to be used prematurely when it is possible that a subsequent Kerberos credential targeting a different domain might succeed. The change here favors Kerberos first and only fails over to NTLM after all credentials have been tried. Customers can also modify their SCCM (Windows Configuration Manager) credentials to include the domain controller's FQDN to allow those scans to use Kerberos. The net effect of these changes will be reduced dependency on NTLM in Windows scans and should produce better results in some cases. Target Release Date 07/16/2025Oracle Enterprise Manager Agent: Patch Mapping Improvements
Summary Improvements have been made to how Nessus plugins determine the active version of Oracle Enterprise Manager Agent. How Patch Mapping Works for Oracle Enterprise Manager Agent Scans Prior to these improvements, the Enterprise Manager Agent version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including Enterprise Manager Cloud Control and Agent, are enumerated in one of two 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) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 86575 (oracle_enterprise_manager_agent_installed.nbin) reports only the base version (e.g 13.5.0.0.0). The full version (patch level) is determined, processed for the relevant vulnerabilities and reported in the individual vulnerability plugins (e.g plugin ID 192753), again by referencing a Tenable managed mapping table. Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out of band cycle or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 13.5.0.0.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on the mapping tables. Plugin ID 86575 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping tables are still checked, and a version comparison is performed to determine the highest patch level present. For Enterprise Manager Agent, the vulnerability plugins like 192753 will no longer need to determine for themselves the installed version (patch level), as this will now be done via the underlying detection plugin, 86575. This plugin will now also report all of the installed patches for the ORACLE_HOME in which the detected Enterprise Manager Agent product resides. Expected Impact Improved accuracy in version detections for Oracle Enterprise Manager, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins - 86575 - oracle_enterprise_manager_agent_installed.nbin - All Oracle Enterprise Manager Agent local vulnerability check plugins (e.g 192753) Targeted Release Date - Wednesday, July 2, 2025Oracle Enterprise Manager Cloud Control: Patch Mapping Improvements
Summary Improvements have been made to how Nessus plugins determine the active version of Oracle Enterprise Manager Cloud Control. How Patch Mapping Works for Oracle Enterprise Manager Cloud Control Scans Prior to these improvements, the Enterprise Manager Cloud Control version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. The process is as follows: Installed patches for most Oracle products, including Enterprise Manager Cloud Control, are enumerated in one of two 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) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 80965 (oracle_enterprise_manager_installed.nbin) collects this information, and then reports the respective installs and their determined versions (patch levels) by comparing detected installed patches to the Tenable managed patch mapping table. Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out of band cycle or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 12.2.1.4.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on the mapping tables. Plugin ID 80965 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping tables are still checked, and a version comparison is performed to determine the highest patch level present. For Enterprise Manager Cloud Control, plugin ID 80965 will now also report all of the installed patches for the ORACLE_HOME in which the detected Enterprise Manager product resides. Expected Impact Improved accuracy in version detections for Oracle Enterprise Manager Cloud Control, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins - 80965 - oracle_enterprise_manager_installed.nbin - Potentially any Oracle Enterprise Manager Cloud Control vulnerability check plugins (e.g 209256) Targeted Release Date - Monday, June 30, 2025New Plugin Family: Tencent Linux Local Security Checks
note: This announcement is to update the target release date. Summary Tenable will now provide vulnerability check plugins for Tencent Linux. Impact Customers with Tencent Linux systems in their environments will be able to scan them for vulnerabilities. These plugins will have the family “Tencent Linux Local Security Checks”. These plugins do not have agent support at this time. Target Release Date June 16, 2025 (originally May 19, 2025)Oracle WebLogic: Patch Mapping Improvements
Oracle WebLogic: Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the installed version of Oracle WebLogic. How Patch Mapping Works for Oracle WebLogic Scans Prior to these improvements, the WebLogic version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including WebLogic, are enumerated in one of two 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) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 73913, oracle_weblogic_server_installed.nbin, collects this information, and then reports the install and its determined version (patch level). Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out-of-band cycle, or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 14.2.1.0.0.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on a mapping table. Plugin ID 73913 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping table is still checked, and a version comparison is performed to determine the highest patch level present. In its output, plugin ID 73913 will now also report all of the installed patches for the ORACLE_HOME in which the detected WebLogic application resides. Expected Impact Improved accuracy in version detections for Oracle WebLogic resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins 73913, oracle_weblogic_server_installed.nbin Potentially any Oracle WebLogic local vulnerability check plugins Targeted Release Date Monday, June 9, 2025Oracle HTTP Server: Patch Mapping Improvements
Oracle HTTP Server: Patch Mapping Improvements Summary Improvements have been made to how Nessus plugins determine the active version of Oracle HTTP Server. How Patch Mapping Works for Oracle Enterprise Manager Scans Prior to these improvements, the HTTP Server version was determined by mapping installed patch IDs to a version number based on a lookup/mapping table that we maintain and ship to scanners as part of the feed. Installed patches for most Oracle products, including HTTP Server, are enumerated in one of two 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) Both of the above plugins store patch information in a temporary database known as the “scratchpad” (a temporary SQLite Database), for later reference. Plugin ID 76617 - oracle_http_server_installed.nbin, collects this information, and then reports the install and its determined version (patch level). Problem This process alone is sometimes problematic, as Oracle releases their patches in stages or sometimes outside of the regular CPU cadence. As our mapping table is manually maintained, some patches are not mapped in time for vulnerability plugin releases, which is a semi-automated process. We have had several instances where our mapping table was not updated in a timely manner - either because Oracle released a new patch ID in an out of band cycle or they released a patch ID that we do not have visibility on. If our scan fails to identify a patch ID that exists in our mapping table, only the base version is reported (e.g. 12.2.1.4.0), possibly resulting in False Positive findings. Improvements We have identified additional methods of determining the version number, including the patch level, without depending solely on a mapping table. Plugin ID 76617 will now first attempt to use the new method of determining the version directly and will fall back to the findings of the mapping table if needed. The existing mapping table is still checked, and a version comparison is performed to determine the highest patch level present. In its output, plugin ID 76617 will now also report all of the installed patches for the ORACLE_HOME in which the detected HTTP Server resides. Expected Impact Improved accuracy in version detections for Oracle HTTP Server, resulting in fewer false positives in downstream vulnerability detection plugins. Impacted Plugins 76617 - oracle_http_server_installed.nbin Potentially any Oracle HTTP Server local vulnerability check plugins Targeted Release Date Monday, June 16, 2025
