Component Installs Require Paranoid Checks (DEPRECATED)
Update - March 4, 2026 After considering customer feedback, we. have decided to re-evaluate these changes and come up with a better way of handling Component installs. For the latest information, please refer to the new release highlight: Improvement: Handling Component Installs for Vulnerability Assessment Summary With this update, products that are deemed to be components of another application, will now require the scan to be run in paranoid mode to trigger generic vulnerability detection plugins. In this context, “generic vulnerability detection plugins” refers to plugins that cover advisories published by the component vendor (e.g., plugin ID 242325, SQLite < 3.50.2 Memory Corruption) rather than the operating system or “parent” application that distributes the component, either as a part of the operating system or a dependent tool of the parent application. Overview Tenable covers software that can be either installed as base level software, or be included as component software of a larger product installation. Base level software can be updated without any impact to the base product functionality. Component software is typically updated as part of the vendor update for the larger packaged product, and the individual components are not updatable. Non-paranoid scans will report base software vulnerabilities that are actionable. Paranoid scans will report on base software vulnerabilities as well component software vulnerabilities that are not actionable, but still package a potentially vulnerable version of the component. To enhance the accuracy of our vulnerability detection and provide users with greater control over scan results, we are implementing an update affecting how we flag vulnerabilities in software components. Our detection plugins for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules can now identify when these packages are installed as components of another parent application (e.g., SQLite bundled with Trend Micro’s Deep Security Agent), rather than as standalone installs. Key Changes: Non-Paranoid Scans: Scans running in the default mode will no longer flag generic vulnerability detection plugins for these component installs. This is because vulnerabilities in components generally cannot be patched directly; users must wait for the parent application's vendor to issue an update. OS Vendor Advisories Unaffected: This change does not affect plugins for OS vendor security advisories that cover the same vulnerabilities (e.g., plugin ID 243452, RHEL 9 : sqlite (RHSA-2025:12522)). Paranoid Scans: For scans running in paranoid mode, generic vulnerability detection plugins will still trigger for component installs if the detected version is lower than the expected fixed version. Expected Impact: Customers running non-paranoid scans should anticipate seeing a reduction in potential vulnerability findings for OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, SQLite, PHP, Python packages and Node.js modules that are installed as components. Technical Details: The changes are entirely contained within two shared libraries, vcf.inc and vdf.inc, utilized by the affected plugins. This update impacts approximately 750 plugins specific to OpenSSL, Curl, LibCurl, Apache HTTPD, Apache Tomcat, and SQLite. Targeted Release Date: Friday, February 6, 2026Improvement: 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
Deep dive into Tenable Hexa AI—the agentic engine of Tenable One 🚀
We know that for a long time, security teams had a buffer. There was a window of time: days or even weeks between a new vulnerability being found and an attacker actually using it. That window has officially collapsed. With frontier AI models now discovering and weaponizing vulnerabilities in minutes, the old way of doing things is a major risk. If your team is stuck in a cycle of manual triage, cross-referencing spreadsheets, and navigating the operational friction of coordinating handoffs between departments, you are moving at human speed against an AI-driven threat. Today at EXPOSURE 2026, we officially announced the general availability of Tenable Hexa AI. Tenable Hexa AI is the agentic engine of the Tenable One Exposure Management Platform designed to help you accelerate risk reduction and reclaim your time. What makes Tenable Hexa AI a game-changer? Your choice of agents: You can use our pre-built, out-of-the-box agents to start reducing risk immediately, or create custom agents tailored to your organization’s environment using the Model Context Protocol (MCP) server. Advanced multi-step reasoning: Seamlessly reason across modern attack surfaces to solve complex security challenges in a single request. Automated remediation workflows: Automatically generate and route customized remediation tickets and audit-ready reports directly within the platform to kickstart your response. End-to-end exposure path insights: Uncover hidden risks via identity-aware search. Gain deep visibility into exposure paths by instantly querying service accounts, privileged users, and AD groups. Why it’s different Tenable Hexa AI wins on contextual supremacy. It is fueled by Tenable’s Exposure Data Fabric—the industry’s most comprehensive repository of contextualized exposure data. While others are guessing based on generic public models, Tenable Hexa AI is making informed decisions based on your actual business risk. Explore the details Whether you want to read the strategic vision or see the engine in action, we’ve made all the resources available below: Read the press release: Get the full scoop on our GA announcement and how Tenable is leading the shift to agentic exposure management. Visit the Tenable Hexa AI webpage: Explore features, use cases, and how the Exposure Data Fabric powers these capabilities. Read the launch blog: A deep dive from our product leadership on the agentic engine and why verifiable trust is at the core of Tenable Hexa AI. Take the guided walkthrough: Get a step-by-step demo of Tenable Hexa AI in action. Explore real-world use cases: Get prompting guidance with our Tenable Hexa AI Prompt Cookbook. Take a deep dive with documentation and release notes: VM Release Notes EM Release Notes Tenable Hexa AI Settings VM User Interface Guide | Use Tenable Hexa AI via MCP Server EM User Interface Guide | Use Tenable Hexa AI via MCP Server How to get started To discuss how Tenable Hexa AI could help your team, please contact your Tenable account representative or reach out to Customer Care. Have questions? Join our Tenable Hexa AI customer office hours. Get the details here.Improvement 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, 2026Overview 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-vulnerabilityImproved 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, 2025Vulnerability 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, 2025
May 2026 Tenable Product Newsletter
Check out our May newsletter to learn about the latest product and research updates, events, and educational content — all to help you get more value from your Tenable solutions. Tenable One Tenable Hexa AI: Intelligence into action at machine speed. We are thrilled to announce that Tenable Hexa AI, the agentic engine of the Tenable One Exposure Management Platform, is now generally available. Tenable Hexa AI orchestrates and automates security workflows to accelerate risk reduction. Built-in or custom agents: Start immediately with our pre-built agents for common security tasks like asset management and dashboard creation, or build custom agents via the MCP server for your unique environment. Execute the fix: Tenable Hexa AI handles complex multi-step tasks like identifying the root cause of a threat and automatically creating the necessary remediation tickets. Automate with confidence: You define the guardrails. Every action is fully auditable and requires the level of human oversight you choose, so you can scale automation without risking your production environment. Get more details on Tenable Connect or read the documentation. To learn more about how to leverage Tenable Hexa AI, reach out to your account team or contact us. The Tenable One Open Connector Connect more. See more. Act faster. We built Tenable One to be the open, connected hub that turns your scattered tools into a one-stop shop for risk reduction. While our standard Connectors already keep your favorite tools in sync, we’re taking integration to the next level with the new Tenable One Open Connector. We're no longer just talking about official integrations; we're talking about bringing in your data from across unsupported or custom tools, spreadsheets, and even homegrown internal systems. What this means for you: Get a more complete view of risk by bringing your security data together in a single, contextual view. Unlock an open, flexible platform for your security stack by staying independent of pre-built integrations. Act faster with automated data syncs that keep your information always current. Tailor your data mapping to enable precise segmentation that fits your organization’s needs. Ready to achieve a truly unified view of your entire attack surface? Read the blog and view the demo. To get started, see the setup guide. Lifecycle management in attack path analysis Take control of your security workflows with our new lifecycle management features in attack path analysis. You can now manually transition attack techniques through specific stages — To Do, In Review, In Progress, Resolved, and Excluded — to ensure seamless collaboration across your team. What’s new: Manual technique control: Track progress accurately by assigning specific statuses to each technique. Smart attack path sync: When you update a technique’s status, the system automatically updates the status of all related attack paths to reflect that change. Unified workflow: Align your team around a shared lifecycle, providing a clear and consistent view of every identified threat. Learn more. Tenable One + Recorded Future integration Our new Recorded Future connector bridges the gap between your internal exposure data and the external threat landscape, giving you a single source of truth to accelerate remediation where it matters most. By layering Recorded Future’s threat intelligence over Tenable’s deep attack surface visibility, you can now achieve: Truly unified visibility: View high-fidelity threat intelligence alongside your full exposure data in one pane of glass. Holistic context: Instantly see how internal asset criticality aligns with real-world exploit trends. Targeted remediation: Ignore the noise and focus exclusively on the vulnerabilities threat actors are actively weaponizing in the wild. Learn more. Tenable integrates with the Claude Compliance API for AI governance Tenable has announced an integration between the Tenable One Exposure Management Platform and the Claude Compliance API. This new capability provides security and compliance teams with unprecedented visibility and governance over enterprise AI usage directly within their existing workflows. Key highlights of this release include: Granular visibility: Monitor enterprise Claude AI interactions, including chats and file uploads, natively within Tenable One. Risk detection: Identify malicious or suspicious activity across your AI ecosystem. Regulatory alignment: Ensure AI usage complies with corporate acceptable-use policies and global mandates like the EU AI Act. This integration is available immediately for all Tenable One customers, allowing organizations to safely adopt Claude Enterprise at scale while proactively managing AI-related risks. Tenable One Cloud Exposure This month, we are focusing on automated orchestration and shifting security further left into native developer workflows. What's New: Retroactive cloud automations: Apply new or re-enabled automation rules retrospectively to your entire backlog of cloud findings to wipe out historical cloud risks in a single click. 280 cloud-native secret types: Our original generic categories are now split into 280 specific data types (like GitHub App Tokens), allowing you to customize sensitivity criteria to fit your exact cloud compliance requirements. Native PR scanning (IaC): Catch security risks natively inside GitHub and Azure DevOps pull requests so developers can fix configuration errors directly on the relevant lines of code before merging. Windows container scans: Maintain robust protection across your entire application footprint with shift-left vulnerability scanning that now supports Windows-based container images within cloud CI/CD pipelines. On-demand registry scans: Manually push critical cloud container images or full repositories to the top of the scan queue to instantly verify your security fixes. For more information on these updates, please view “documentation” inside the Tenable One Cloud Exposure interface. Tenable One Vulnerability Management Automate remediation with direct ticketing Stop bouncing between disconnected tools. You can now create Jira or ServiceNow tickets directly within your Explore Findings view and launch Exposure Response Initiatives straight from Vulnerability Intelligence. Even better, Tenable automatically closes these tickets the moment a vulnerability is fixed, eliminating tedious manual cleanup for your team. To keep your security and IT teams aligned, we've also added live ticket log tracking inside the finding details page, new ticket filters for your findings table, and easy exports for Exposure Response logs. To get started, check out our documentation or interactive tour. Clear your blind spots and validate your security coverage To protect your network, you need to know your security tools are working correctly. New dashboards and reports help you eliminate hidden gaps and prioritize fixes faster. The program health dashboard monitors your deployment health and scanning coverage. It gives you a central view to ensure your security agents are active and fully patched, preventing silent operational failures. The program health report unifies fragmented asset data and scan authentication indicators into a single document. It resolves conflicting inventories and credential issues, giving you a clean, trusted report to plan and execute remediation. The endpoint application visibility dashboard cuts out the hours your team spends hunting down software inventories. It automatically consolidates application data across endpoints so you can prioritize fixes based on real-world exploit likelihood and deployment scale. Nessus Whether you are a seasoned pro with Nessus or just starting out as a first-time user, don’t forget to check out our on-demand training courses and learn from the team that built Nessus. Nessus Fundamentals: Maximize your Nessus Professional or Expert deployments. You’ll master the essential building blocks of vulnerability assessment, conquering everything from initial installation and asset discovery to compliance checks and in-depth analysis. No prerequisites necessary. Nessus Advanced: Elevate your Nessus Expert skills. You’ll build upon your foundational knowledge to take command of external attack surface discovery, web app scans, and results analysis. Accelerate your time-to-value with a full year of unlimited access to expert-led video instruction. You will master critical workflows, maximize your security ROI, and earn a digital badge and Certificate of Completion to validate your hard-earned expertise. Learn more and enroll today at www.tenable.com/buy/training Tenable Security Center Tenable Security Center 6.8 Focus on the vulnerabilities that matter with AI-powered VPR insights and mitigation guidance. This release streamlines your operations with unified asset repositories for IPv4, IPv6, and Agents, and improves efficiency with new background query processing and scan optimization capabilities. View the full release notes to learn more. Tenable Patch Management Scale patching and simplify upgrades Broader environment coverage, faster endpoint updates, and a much smoother platform upgrade are available with the latest releases. Version 10.1.971.12 (SaaS & on-premise) expands your coverage across new Linux distributions and architectures. On your endpoints, you can now run lightweight, native driver and BIOS updates without the heavy files that cause CPU bloat, and deploy Windows upgrades via bandwidth-saving peer-to-peer rollouts. This release also cuts console memory usage, hardens library security, and fixes interface bugs affecting patch previews. Version 10.1.972.14 (server) delivers a targeted hotfix that corrects server upgrade task-sequencing and strategy validation issues, ensuring you a seamless, error-free migration from older versions. Broader environment coverage, faster endpoint updates, and a much smoother platform upgrade are available with the latest releases. Version 10.1.971.12 (SaaS and on-premises): Expands your coverage across new Linux distributions and architectures. On your endpoints, you can now run lightweight, native driver and BIOS updates without the heavy files that cause CPU bloat, and deploy Windows upgrades via bandwidth-saving peer-to-peer rollouts. This release also cuts console memory usage, hardens library security, and fixes interface bugs affecting patch previews. Version 10.1.972.14 (server): Delivers a targeted hotfix that corrects server upgrade task-sequencing and strategy validation issues, ensuring a seamless, error-free migration from older versions. How to update: SaaS tenants have been updated automatically. For on-prem deployments, download the latest installers via the Tenable Downloads Portal. For the further details, check out the release notes. Tenable One OT Exposure Tenable OT Security 4.6 Our latest release introduces a variety of new features and performance enhancements, including refined scan controls and streamlined workflows for large-scale enterprise environments. Massive subnet scaling: Now supports up to 5,000 subnets per ICP, significantly increasing visibility for distributed large enterprise deployments. Centralized network management: A new Monitored Networks page includes bulk-add capabilities and the ability to stage inactive networks before monitoring. Precision scanning: New scan customization options allow you to define specific credential usage per scan for safe discovery of sensitive assets. Streamlined platform navigation: Updated workflow for SSO/SAML users allows you to instantly pivot back to Tenable One with a single click. Remote agent updates and query restrictions: Update OT agents directly from the ICP, remove local site visits or manual CLI intervention, and restrict specific protocol queries with OT agents. Enhanced diagnostics: Deeper metadata in asset log exports for faster troubleshooting. IoT connector updates: Major stability and performance upgrades for Milestone, AvigilonES, and Exacq Edge integrations for IoT asset discovery. Update required: Tenable OT Security 4.5 Service Pack (version 4.5.61) All customers running version 4.5 should apply this upgrade immediately for optimal system stability and performance when processing high volumes of network conversations. This update also addresses communication gaps with Rockwell Stratix devices and Nessus scans. View the full release notes. Tenable Ecosystem Tenable App for Microsoft Sentinel v3.1.2 Version 3.1.2 of the Tenable App for Microsoft Sentinel is now available, bringing connector enhancements and schema updates to optimize your integration. What’s new: TIE data connector: The UI now supports multiple rsyslog configurations. Schema updates: Updated table schemas for Tenable One Vulnerability Management and Tenable One Web App Scanning vulnerabilities within the ARM Template. Improved data handling: The Tenable Vulnerability SDK now utilizes indexed_at instead of last_found. We highly recommend upgrading to v3.1.2 to ensure full support for these latest changes. For more details, please read Tenable Documentation or visit the Azure Marketplace to download. Please note, this application is also available via the Microsoft Azure Gov Cloud marketplace. Tenable events and webinars Tune in for product updates, demos, how-to advice and Q&A. See all upcoming live and on-demand webinars at https://www.tenable.com/webinars. Customer Office Hours These are recurring ask-me-anything sessions for Tenable Security Center, Tenable One Vulnerability Management, Tenable One Cloud Exposure, Tenable One Identity Exposure and Tenable One OT Exposure. Time-zone-appropriate sessions are available for the Americas, Europe (including the Middle East and Africa and Asia Pacific (APJ). Learn more and register here. On-demand TenableTalk Live: Responding to Mythos and Frontier AI vulnerability discovery: Catch the replay of this conversation about the impact of frontier AI models on the threat landscape and how security teams can evolve vulnerability discovery into a machine-speed agentic defense. Watch on LinkedIn or in Tenable Connect. Tenable customer update: April 2026: Watch this quarterly Tenable customer update to learn how to use AI to augment your security team, secure your expanding AI attack surface, uncover hidden risk across your connected IT/OT environments, and more. Products covered: Tenable One, Tenable One AI Exposure, Tenable One Vulnerability Management, OT functionality, third-party data connections, and Tenable Security Center. Tenable Research Research Security Operations Subscribe to the Research team blog posts here. Why the approaching flood of vulnerabilities changes everything — and what to do about it New content Almost 7,000 new published vulnerability plugins. More than 60 new audits delivered to customers. Read Tenable documentation.Modern infrastructure, minimal effort: the next Tenable Patch Management release is here
The April 2026 release of Tenable Patch Management is officially live. This update focuses on the unpatchables—modern ARM architectures, massive Windows feature updates, and performance-heavy drivers—giving you broader coverage without the operational lag. What’s changing and why it matters: Support for the modern cloud (Linux ARM): The value: Organizations are increasingly adopting ARM-based architectures (like AWS Graviton) for better cost and power efficiency. Tenable Patch Management now provides full patch lifecycle management for ARM-based versions of RHEL, Ubuntu, Debian, and more. Use case: If your DevOps team is scaling web-scale applications on ARM-based cloud instances, you can now include these specialized endpoints in your standard autonomous patch strategies, ensuring they receive the same security rigor as your traditional x86 fleet. Zero-friction windows upgrades: The value: We’ve automated the big ones. Windows 10/11 Feature Updates are notoriously difficult to manage due to their size and complexity. Tenable Patch Management now automates the eligibility checks and phased rollouts of these updates, utilizing peer-to-peer distribution to protect your bandwidth. Use case: A security manager can set a policy to roll out the latest Windows 11 Feature Update in waves, starting with a canary group in IT for validation before moving to broader business units, ensuring a smooth transition without disrupting global operations. Lightweight driver patching: The value: We’ve ditched heavy CAB-based catalogs. Get lightning-fast visibility into Dell, HP, and Lenovo drivers using native OS metadata. Use case: You can now perform frequent driver scans across thousands of remote laptops without worrying about "scan bloat" or slowing down employee machines during peak hours. Expanded Linux coverage & platform speed: The value: Stay current with the latest enterprise environments. We’ve added comprehensive support for Amazon Linux 2023 (AL2023), the latest Fedora (42/43) releases, and the newest SUSE and OpenSUSE iterations (including SLES/SLED 15 SP7 & 16). Combined with our migration to Java 25 virtual threads, we’ve slashed the memory footprint for both client and server, making the platform faster and leaner. In addition to all of the new features, we’re also making the following UI enhancements and bug fixes: Patch filter preview: Resolved a bug where multiple filter categories in the Strategy Editor (e.g., Tenable.vpr, risk.cvssscores) failed to return results when using the "Preview Filtered Software" function. Simple preview: Fixed an issue in the Simple Strategy Editor where the "Preview Targeted Patches" button returned empty results for products with a SoftwareProduct parent, including all Windows OS, Linux, and Driver patches. Pre-staging bug: Fixed a critical issue where Windows Update deployments would fail to start if the "pre-staging" option was enabled. Save as API: Resolved a REST API error that occurred when using the "Save As" feature on an existing strategy template. Character limits: Increased the character limit for User Interaction settings text fields (specifically the HTTP POST Message field) to prevent data truncation and database errors. Get the full details This release is available for both Tenable Patch Management SaaS and On-Prem customers. For a deep dive into the new distributions (Amazon Linux 2023, SLES 16, Fedora 42 & 43) and technical specs, check out the resources below: 👉 [Release Notes] 👉 [Technical Documentation] 👉 [Downloads]Tenable 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
