Forum Widgets
Recent Discussions
Overview of Callbacks in Log4j Remote Detection Plugins The...
Overview of Callbacks in Log4j Remote Detection Plugins The following is an overview of callbacks in Tenable plugins for Log4Shell that perform remote detection 155998, 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166, 156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669. A HTTP request is sent by the scanner to the target being scanned with a benign payload containing a unique token. The target, if vulnerable, will act on the payload. Tenable tracks the target’s action on the payload via a callback to our hosted environment (plugins 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166,156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669) based on the unique token that was embedded in the initial request or via the LDAP connection callback to the scanner for plugin 155998. The callback is needed given the nature of the vulnerability as execution of the payload happens on the target being scanned. In plugin 155998, the callback happens to the scanner. This is the reason the plugin is not supported on Tenable.io cloud scanners In plugins 156014, 156016, 156017, 156035, 156056, 156115, 156132, 156157, 156158, 156162, 156166, 156197, 156232, 156256, 156257, 156258, 156375, 156445, 156559, and 156669 as part of execution of the payload, the target tries to resolve a domain owned by Tenable. While resolving the domain, Tenable is able to see the unique token that was sent in the initial request and thereby can track the callback. These plugins come with the major benefit that credentials are not required for scanning. However, the callbacks need to be successful for the plugin to be able to identify the exposure. Hence, communication between the target being scanned and the callback server must not be interrupted by intermediary devices. For more details: https://community.tenable.com/s/feed/0D53a00008E3hKzCAJ https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability
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 TBD
CyberArk Client Certificate Authentication Issue Summary...
CyberArk Client Certificate Authentication Issue Summary Tenable has discovered an issue with our CyberArk Integration and its Client Certificate Authentication to the CyberArk CCP/AIM Web Service API. Customers that have deployed the CyberArk CCP component on Windows Server 2022+ have experienced unsuccessful attempts authenticating to the CCP/AIM Web Service API using Client Certificate Authentication with our CyberArk Integration. This is due to an issue with Windows Internet Information Services (IIS) and certificate authentication over TLS 1.3 and HTTP/2. Change Customers using a Windows Server 2022+ to host their CyberArk CCP must disable TLS v1.3 and HTTP/2 on the IIS manager in order to successfully use Tenable’s CyberArk Integrations that support Client Certificate Authentication. The following Microsoft article describes the issue. https://techcommunity.microsoft.com/blog/iis-support-blog/windows-server-2022-iis-web-site-tls-1-3-does-not-work-with-client-certificate-a/4129738 Impact There are no changes to the integration. Release Date IMMEDIATEVulnerability Scanning Container Directory Exclusion Summary
Vulnerability Scanning Container Directory Exclusion Summary Directories that store container image layers will be excluded by default from vulnerability scanning for Tenable Vulnerability Management, Security Center and Nessus. The directories that will be excluded are those configured for container storage by the container management solution. Docker: The "Docker Root Dir:" as returned by the "docker info" command. This is /var/lib/docker by default. Podman: The "graphRoot:" as returned by the "podman system info" command. This defaults to /var/lib/containers/storage. containerd: The "root =" directory as returned by the "containerd config dump" and "containerd config default commands. This location is /var/lib/containers/storage by default. CRI-O: The "storage graph root:" as returned by running "crio status info". This location is /var/lib/containers/storage by default. What is the impact? Vulnerabilities previously detected as a result of scanning these directories will become mitigated on the next scan and findings not returned in future scans. These findings are a result of examining the container image layers on the filesystem. The container may not necessarily be running and represent risk to your organization and customers generally consider these results as false positives since they are managed Docker deployments. Tenable Cloud Security is designed to secure container images and provide pre-deployment validation. Recursively scanning these directories is a resource and time consuming process. The exclusion of the directories may also result in decreased scan times. Can I override the change? You could add an Include Filepath rule to your scan configuration in order to override the default exclusion behavior. This may be found under the Scan Policy Advanced Options. A note of caution that overriding the default behavior could affect scan performance or give results that are unable to be remediated since within a managed container. In order to include a directory that is automatically excluded, the user include filepath has to match the excluded directly exactly. Example: If your Docker configuration uses /var/lib/docker for container storage you would add /var/lib/docker to your user filepath inclusions. Adding a more or less specific location will have no effect. What are the affected plugins? At the time of this release highlight publication, the following plugins are leveraging find: 142023 - Apache Cassandra Installed (Linux) 133766 - Apache Maven Installed (Linux / Unix) 135172 - Oracle NoSQL Database Installed (Linux) 117706 - MagniComp SysInfo Installed (Linux/UNIX) 111679 - FasterXML Jackson Databind Detection for Linux/UNIX 112063 - Kubernetes Installed (Linux) 136340 - nginx Installed (Linux/UNIX) 131566 - Atlassian Jira Installed (Unix / Linux) 147817 - Java Detection and Identification (Linux / Unix) 132771 - Palo Alto Cortex XSOAR Installed (Unix / Linux) 132872 - Foxit Reader Installed (Linux) 174788 - SQLite Local Detection (Linux) 151883 - Libgcrypt Installed (Linux/UNIX) 99671 - Apache Struts Detection for Linux/UNIX 156000 - Apache Log4j Installed (Linux / Unix) 141394 - Apache HTTP Server Installed (Linux) 71642 - Oracle Installed Software Enumeration (Linux / Unix) 156551 - Oracle MySQL Enterprise Monitor Installed (macOS) 124276 - Oracle Tuxedo Installed (Linux/UNIX) 73913 - Oracle WebLogic Server Detection 133962 - Sophos Anti-Virus Installed (Linux) 186361 - VMWare Tools or Open VM Tools Installed (Linux) 187057 - OwnCloud OwnCloud Installed (Linux) 70349 - Adobe Acrobat Installed (Mac OS X) 72202 - JBoss Detection 147022 - SAP Adaptive Server Enterprise (ASE) Installed (Linux) 163488 - Terraform Configuration Detection for Linux/UNIX 77028 - IBM Installation Manager Detection (Linux / Unix) 145032 - IBM WebSphere eXtreme Scale (Linux) 144633 - IBM MQ Server and Client Installed (Linux) 136341 - Dell EMC Data Protection Central Installed (Linux) 133964 - SELinux Status Check 159273 - Dockerfile Detection for Linux/UNIX 174164 - Google Protobuf Go Module Installed (Linux/UNIX) 158567 - Citrix Workspace App Installed (nix) 55420 - Adobe Reader Installed (Mac OS X) Target Release Date April 30, 2025Tenable Research is providing the following supporting...
Tenable Research is providing the following supporting information about the 31 NASL detection plugins and two WAS plugin recently released in response to a critical vulnerability reported in Log4j (Log4Shell). As a reminder, it is recommended that thorough_tests are enabled for all scans using these CVE-2021-44228, CVE-2021-45046, CVE-2021-4104, and CVE-2021-45105 plugins. NASL plugins 156183 Apache Log4j 2.x < 2.17.0 DoS Version check for known vuln Log4j versions related to CVE-2021-45105 in Windows, Unix and Linux systems 156057 Apache Log4j 2.x < 2.16.0 Version check for known vuln Log4j versions related to CVE-2021-45046 in Windows, Unix and Linux systems 156165 Apache Log4j 2.x < 2.16.0 RCE Version check for known vuln Log4j versions related to CVE-2021-45046 in MacOS systems 156164 Apache Log4Shell CVE-2021-45046 Bypass Remote Code Execution - (Direct Check HTTP) Direct Check compatible with Tenable.io Cloud Scanners and restrictive networks Delivers jndi:ldap crafted payloads including Session, JSession and PHPSession into the HTTP headers and then tracks the injection via DNS when the callback is made. Callback is needed given the nature of the vulnerability wherein the target / victim connects back to the host sending the original request and the host is vulnerable if the callback happens This plugin uses DNS (default port 53) for network communication. The following Apache Log4Shell CVE-2021-44228 Direct Checks share common techniques applied on different ports and protocols. They all share the following attributes: Direct Checks compatible with Tenable.io Cloud Scanners and restrictive networks Callback is needed given the nature of the vulnerability wherein the target / victim connects back to the host sending the original request and the host is vulnerable if the callback happens These plugins DNS (default port 53) for network communication. Delivers jndi:ldap crafted header script to select ports on a scan target and then tracks the injection via DNS when the callback is made CVE-2021-44228 direct check not requiring authentication 156669 Apache Log4Shell RCE detection via callback correlation (Direct Check - MSRPC) 156559 Apache Log4Shell RCE detection via callback correlation (Direct Check - RPCBIND) 156445 Apache Log4Shell RCE detection via callback correlation (Direct Check - PPTP) 156375 Apache Log4Shell RCE detection via callback correlation (Direct Check - UPnP) 156258 Apache Log4Shell RCE detection via callback correlation (Direct Check - NTP) 156257 Apache Log4Shell RCE detection via callback correlation (Direct Check - DNS) 156256 Apache Log4Shell RCE detection via callback correlation (Direct Check - SNMP) 156232 Apache Log4Shell RCE detection via callback correlation (Direct Check - SMB) 156197 Apache Log4Shell RCE detection via callback correlation (Direct Check - NetBIOS) 156166 Apache Log4Shell RCE detection via callback correlation (Direct Check - SSH) 156162 Apache Log4Shell RCE detection via callback correlation (Direct Check - Telnet) 156158 Apache Log4Shell RCE detection via callback correlation (Direct Check - IMAP) 156157 Apache Log4Shell RCE detection via callback correlation (Direct Check - POP3) 156132 Apache Log4Shell RCE detection via callback correlation (Direct Check - SMTP) 156115 Apache Log4Shell RCE detection via callback correlation (Direct Check - FTP) 156056 Apache Log4Shell RCE detection via callback correlation (Direct Check - any open port) 156035 VMware vCenter Log4Shell (Direct Check HTTP) Delivers jndi:ldap crafted payloads into the HTTP header of VMWare vCenter applications installed on the remote host on a scan target and then tracks the injection via DNS when the callback is made 156017 Apache Log4Shell RCE detection via callback correlation (Direct Check - SIP) 156016 Apache Log4Shell RCE detection via Path Enumeration (Direct Check HTTP) 156014 Apache Log4Shell RCE detection via callback correlation (Direct Check HTTP) CVE-2021-44228 direct check not requiring authentication Direct Check compatible with Tenable.io Cloud Scanners and restrictive networks Injects payload into the HTTP headers and then tracks the injection via DNS when the callback is made Callback is needed given the nature of the vulnerability wherein the target / victim connects back to the host sending the original request and the host is vulnerable if the callback happens This plugin uses DNS (default port 53) for network communication. 155998 Apache Log4j Message Lookup Substitution RCE (Log4Shell) (Direct Check) CVE-2021-44228 direct check not requiring authentication Scanner sends jndi:ldap string to target and listens for LDAP BIND request from target It is not compatible with Tenable.io cloud scanners and may fail to return results in certain networks due to firewall rules or interference from other security devices. Callback is needed given the nature of the vulnerability wherein the target / victim connects back to the host sending the original request and the host is vulnerable if the callback happens This plugin uses ephemeral ports 50,000-60,000 for network communication 156001 Apache Log4j JAR Detection (Windows) Local Windows detection **recommend Thorough Tests** Checks running processes for Java instances running with Log4j in classpath and records the file paths Searches the file system for .jar files with known vuln Log4j filename matches (if thorough tests is enabled) 156000 Apache Log4j Installed (Unix) Local Linux detection Checks rpm packages for vulnerable Log4j matches (RedHat, Gentoo, SuSE, etc.) Search the file system paths for known vulnerable Log4j matches (if thorough tests is enabled) 155999 Apache Log4j < 2.15.0 Remote Code Execution Local Linux Detection (uses 156000) Version check for known vuln Log4j versions in Unix and Linux systems 156002 Apache Log4j < 2.15.0 Remote Code Execution Local Windows detection (uses 156001) Version check for known vuln Log4j versions in Windows systems 156032 EOL plugin for Log4j 1.x Apache Log4j version < 1.x End of Life / Unsupported Version Detection 156103 Apache Log4j 1.2 JMSAppender Remote Code Execution (CVE-2021-4104) The version of Apache Log4j on the remote host is 1.2. It is, therefore, affected by a remote code execution vulnerability when specifically configured to use JMSAppender. WAS plugins 113075- Apache Log4j Remote Code Execution (Log4Shell) CVE-2021-44228 direct check not requiring authentication Inject payload into the HTTP headers, POST/GET values, XML, JSON, cookies, etc. and then track the injection via DNS when the callback is made Callback is needed given the nature of the vulnerability wherein the target / victim connects back to the host sending the original request and the host is vulnerable if the callback happens 113076- Apache Log4j Remote Code Execution (Log4Shell) CVE-2021-44228 WAS Log4Shell file detection plugin Scan the web application directories for known vulnerable version of the Log4j installation file and flag the host if foundNessus now has Entra LAPS Support Summary: Nessus now has...
Nessus now has Entra LAPS Support Summary: Nessus now has the ability to leverage accounts managed by Microsoft Entra 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. Now that Nessus can communicate with an Entra LAPS setup, customers no longer need to have or provide those extra privileged accounts. This means less exposure and less redundancy in a customer’s environment. Change: With this LAPS support change, during the startup phase of a scan, Nessus will reach out to a Microsoft Entra Tenant and pull a list of all Local Admin Accounts managed by LAPS. Nessus will then attempt to use these Entra provided LAPS managed accounts as credentials when attempting to access a target host. The LAPS credentials found are not stored or kept in the scanner configuration any way and only exist in memory at runtime. Each time a Scan is initiated with LAPS support enabled, it will do a fresh pull of credentials. How to enable it: To make use of Nessus’ Entra LAPS support, customers need a Registered App in their Entra Tenant with the DeviceLocalCredential.Read.All permission. These Registered App permissions are what allows an App to access the LAPS managed accounts. Customers with an existing Registered App can configure them for use in Nessus by simply granting the Registered App the DeviceLocalCredential.Read.All permission, allowing Nessus to access LAPS data. Customers without a Registered App will need to create a new one, and provide it as a [Cloud Services Microsoft Azure/Entra Credential] in your Scan Policy. For additional information see: https://docs.tenable.com/identity-exposure/3_x/Content/Admin/entra_id_support.htm#Configure-Microsoft-Entra-ID-settings and https://docs.tenable.com/vulnerability-management/Content/Settings/Credentials/CreateManagedCredential.htm Impact: Customers using Rotating Host passwords managed through Microsoft Entra LAPS can now leverage these credentials in their Nessus scans for more secure scanning configurations. Target Release Date: ImmediateCisco Meraki Integration
Summary Tenable is proud to announce our new integration with Cisco Meraki Dashboard. Cisco Meraki Dashboard is a centralized cloud-based platform used to manage and monitor Cisco Meraki devices. It provides a web-based interface for configuring, troubleshooting, and securing global network and IoT deployments. Tenable’s integration with the Cisco Meraki Dashboard API allows users to leverage our vulnerability management solutions against devices that are managed in their Meraki environment including security appliances, switches, routers, and other supported devices. Scope Customers using Tenable Vulnerability Management and Nessus Manager will be able to configure up to a maximum of five Cisco Meraki credentials in a single scan policy. The Cisco Meraki credential can be found under the "Miscellaneous" category of credentials. Detailed information about the integration and configurations can be found by visiting our integration documentation page in the link for Cisco Meraki. https://docs.tenable.com/Integrations.htm Plugins Plugins related to the integration can be divided into two categories; integration and supporting plugins. The integration plugins gather the credential settings, collect data from the Cisco Meraki API, and store this data for usage by the supporting plugins. Whereas supporting plugins detect the presence of Cisco Meraki devices and perform vulnerability detections against the device attributes; mainly primarily firmware. Integration Plugins Cisco Meraki Settings Cisco Meraki Data Collection Integration Status Supporting Plugins Cisco Meraki Detection Tenable Research will also release 6 initial plugins to detect Cisco Meraki versions vulnerable to several different high-impact CVEs. Please note that these plugins will require a paranoia level of 2 (“Show potential false alarms”). Impact The Nessus Scan Information plugin (plugin ID 19506) will report credentialed checks for Cisco Meraki devices through the use of the Cisco Meraki integration. Customers will see credentialed checks ‘no’ if a Cisco Meraki Device was detected while using the integration and the firmware version that we collected for the device is not configured or absent. Otherwise, customers can expect to see ‘yes, via HTTPS’ if successful. Release Date Tenable Vulnerability Management and Nessus Manager: July 3rd, 2025 Tenable Security Center: TDB
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, 2025Tenable Research Release Highlight Nessus Agent Reset...
Tenable Research Release Highlight Nessus Agent Reset Plugin and Scan Template Summary Tenable Research has released a Credentialed Scan plugin and Scan Template “Nessus 10.8.0 / 10.8.1 Agent Reset” in support of addressing the issues in the Nessus Agent 10.8.0 and 10.8.1. Change New Scan Template: “Nessus 10.8.0 / 10.8.1 Agent Reset” Pre-requisite: Ensure that the agent version is set to 10.8.2 or 10.7.x in Agent Profile (for TVM) and Nessus Manager (for TSC). This Scan Template and Credentialed Scan plugin will run OS specific scripts to remotely reset the agent plugins on Windows, Mac OS or ‘Nix based Nessus Agent host machines on 10.8.0 or 10.8.1. These scripts and the permissions level each script requires are detailed in the Nessus Agent 10.8.2 Release Notes (https://docs.tenable.com/release-notes/Content/nessus-agent/2025.htm#10.8.2) under the [Perform a plugin reset] section. Notes: The Nessus Agent Reset plugin will only run from the provided Scan Template and will not reset Nessus Agents when run from any other Scan Template. For Ubuntu/Debian Unix credentials, please ensure that only one set of privilege escalation credentials are provided with the required permissions level for the OS script to execute. 13 JAN 2025 UPDATE: Please note that triggering a plugin reset will result in a large spike in network traffic. Impact Without this script, customers would have to logon to each Nessus Agent host and run the appropriate Nessus Agent Reset script for that host OS. Using this Scan Template and Credentialed Scan plugin, customers can run the Nessus Agent Reset scripts on each updated Nessus Agent from a Remote Credentialed Scan, with the necessary credentials and permissions, using Nessus, Nessus Manager, T.VM, and T.SC (released 08 JAN). Target Release Date 07 JAN 2025Improved 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
