Forum Widgets
Recent Discussions
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
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-vulnerabilityNessus 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: Immediate
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 - SSH Session Reuse
Summary Nessus scan will support an opt-in feature to reuse SSH sessions during a scan where possible when running Nessus versions 10.9.0 and greater. This update was made in response to numerous customer requests for reducing the number of new SSH connections established during remote network scans and the associated increase in network traffic. Change A new scan configuration template option will be available for customers to actively enable the [Reuse SSH connections] configuration in their scan policies in Advanced Settings under Advanced Performance Options. Customers can return to the classic SSH connection functionality by changing [Reuse SSH connections] to the default “off” setting in their scan policies. Customers must be running a version of Nessus 10.9.0 or greater that supports this feature and have a Plugin Feed that displays the scan configuration policy user interface and NASL plugin set with the SSH session reuse functionality. Impact Customers should see a significant decrease in the total number of SSH sessions established during a Nessus scan as well as a reduction in load on Enterprise authorization, access, and accounting (AAA) tooling such as RADIUS servers and other connection management services. There should be no difference in scan results between scans that leverage SSH Session Reuse and scans that do not. If customers experience any such issues, the feature can easily be toggled off to return SSH connections during scans to the classic connection functionality. Target Release Date January 15, 2026Vulnerability 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 found
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 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: TDBImproved Resource Management Control
Summary Improved resource management control for plugins leveraging Windows Management Instrumentation (WMI) on Nessus Agent 11.1.0 or higher. Impact Customers with Nessus Agent 11.1.0 and later versions will have the ability to granularly control the CPU resources consumed during scans. This update ensures that plugins respect the resource usage setting selected during scan configuration by launching commands as children of the Nessus Agent, rather than invoking them via WMI. The release of these plugins will continue through January, with a phased approach over three weeks. The first release will be January 13th, the second January 20th, and the final planned plugin update on February 9th. Target Release Date Phase 1 plugin set: January 13, 2026 Phase 2 plugin set: January 20, 2026 Phase 3 plugin set: February 9, 2026
