Tenable Blog

Oracle addresses 1209 CVEs in its final quarterly update of 2026 with 1295 patches, including 112 critical updates.

1. The October 2026 Critical Patch Update (CPU) contains fixes for 1209 unique CVEs in 1295 security updates
2. 112 issues (8.6% of all patches) were assigned a critical severity rating
3. Oracle Fusion Middleware received the highest number of patches at 206, accounting for 15.9% of all patches

On October 20, Oracle released its Critical Patch Update (CPU) for October 2026, the final quarterly update of the year. This CPU contains fixes for 1209 unique CVEs in 1295 security updates across 33 Oracle product families. Out of the 1295 security updates published this quarter, 8.6% of patches were assigned a critical severity. Medium severity patches accounted for the bulk of security patches at 47.3%, followed by high severity patches at 36.7%.

This quarter's update includes 112 critical patches across 95 CVEs.

This quarter, the Oracle Fusion Middleware product family contained the highest number of patches at 206, accounting for 15.9% of the total patches, followed by Oracle E-Business Suite at 194 patches, which accounted for 15% of the total patches.

A full breakdown of the patches for this CPU can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Customers are advised to apply all relevant patches in this CPU. Please refer to the October 2026 advisory for full details.

A list of Tenable plugins to identify these vulnerabilities will appear here as they're released. This link uses a search filter to ensure that all matching plugin coverage will appear as it is released.

• Oracle Critical Patch Update Advisory - October 2026
• Oracle October 2026 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Discover how to secure AI agents in your cloud environment with Tenable One Cloud Exposure. We explore Microsoft Entra Agent ID and provide essential best practices for robust agentic AI identity security.

1. Understand your current maturity level and then build an appropriate action plan to secure your agent identities.
2. Use your cloud providers’ native tools or Tenable One Cloud Exposure to locate and catalog every AI agent operating in your environment.
3. Do not assign human identities or over-privileged service accounts to the AI agents your vendors deploy in your environment. Instead, require that vendors adopt official models like Microsoft Entra Agent ID for their AI agents’ identities.

As AI agents move from experimental toys to tools that make autonomous decisions, interact with databases, and call external APIs, organizations need to be clear on who — or what — is executing these actions in their cloud environments.

Security teams categorize identities into two buckets: human identities and non-human identities (NHIs), such as service accounts, secrets, and automated scripts.

Treating AI agents as standard NHIs is a recipe for disaster. AI agents combine their non-deterministic nature with their ability to execute flexible, outcome-oriented actions, rather than following strict, prescribed instructions. 

Unlike classic, predictable scripts that follow rigid code paths, AI agents:

• Make creative, runtime decisions using LLMs.
• Interact with dynamic external tools, memory caches, and knowledge bases.
• Constantly adapt to solve problems, making it difficult for a security team to establish AI agents’ baseline behavior.

To address this challenge, major cloud providers have introduced dedicated, specialized agentic AI identity models. Let’s break down one major model: Microsoft Entra Agent ID.

Identity and cloud providers' native identity management tools present only basic information about agentic identities, without providing context about their security flaws and how they extend your attack surface. Because AI agents are becoming a new class of identity with real permissions, you must understand how an attacker could compromise and abuse them. At Tenable, we believe visibility is the foundation of security. You can’t secure assets that you do not know exist.

As organization-wide adoption of agentic AI accelerates, the immediate challenge for security teams is first and foremost finding them. Because these identities are brand new, conventional identity and access management (IAM) systems may not recognize or monitor them, which creates security blind spots.

To help our customers address this issue, Tenable One Cloud Exposure now brings Microsoft Entra agentic AI identities directly into your unified asset and identity inventory.

The Microsoft Entra Agent ID framework functions through a four-tiered structural model:

1. Agent identity blueprints serve as the master templates for shared attributes. Residing exclusively within the agent provider’s home tenant, they establish cross-tenant links that heighten exposure to potential supply-chain attacks.
2. Agent identity blueprint principals are the localized instantiation of a blueprint within every specific tenant where the AI agent is deployed and active.
3. Agent identities represent the functional identities utilized for routine tasks. To maintain oversight of agent behavior, these are the primary entities your security team must monitor.
4. Agent users offer an optional layer for each agent identity requiring human-centric features — like Microsoft Teams access or a personal mailbox — to function effectively as integrated “digital colleagues.”

Watch the quick walkthrough below to see how Tenable One Cloud Exposure discovers, inventories, and maps your Microsoft Entra agentic AI identities.

At the recent fwd:cloudsec North America 2026 conference in Bellevue, Wash., my fellow Tenable researcher Ron Popov and I took the stage to address this exact challenge in our talk, “Who Are the Robots? Uncovering AI Agents’ Identities.”

If you missed our live session or want to dive deep into the technical architecture of agentic identity, please watch our full presentation in the video below.

Don’t let autonomous agents become dangerous blind spots in your cloud environments. Discover Tenable One Cloud Exposure today to see how Tenable’s unified identity inventory can help you gain broader visibility over your Microsoft Entra AI agent footprint.

1. 69Critical
2. 1337Important
3. 0Moderate
4. 1Low

Microsoft addresses 1407 CVEs in the tenth Patch Tuesday of 2026, marking the second consecutive month to reset the bar as the largest Patch Tuesday release. This month’s updates include patches for two zero days, including one that was exploited in the wild.

Microsoft patched 1,407 CVEs in its October 2026 Patch Tuesday release, with 69 rated critical, 1,337 rated as important, and one rated as low.

This month’s update includes patches for 301 products and components. The following table lists the products with the most CVEs patched this month. A full list of patched products is available in the appendix.

Elevation of Privilege (EoP) vulnerabilities accounted for 47.9% of the vulnerabilities patched this month, followed by remote code execution (RCE) vulnerabilities at 22.3%.

CVE-2026-96951 is a security feature bypass vulnerability affecting Windows Shell. It received a CVSSv3 score of 8.8 and was rated as important. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

An attacker could exploit this vulnerability using social engineering tactics, via email or messages, to convince their target to open a malicious file. Successful exploitation would bypass the Mark of the Web (MOTW) security feature.

This is the third flaw in Windows Shell that was exploited in the wild in 2026: CVE-2026-21510 was patched in February 2026’s Patch Tuesday while CVE-2026-32202 was patched in April 2026’s Patch Tuesday.

CVE-2026-108398 is a security feature bypass vulnerability affecting.NET Framework. It received a CVSSv3 score of 8.8 and is rated as important. It was publicly disclosed prior to a patch being available.

An attacker could exploit this vulnerability by registering a malicious.NET assembly on a vulnerable system to be loaded by a protected process. Successful exploitation would allow the attacker to bypass Windows Defender Application Control (WDAC).

CVE-2026-70229 is an RCE vulnerability affecting Windows Active Directory Domain Services (AD DS). It received a CVSSv3 score of 8.1 and is rated as critical. Microsoft assesses this vulnerability as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

An attacker could exploit this vulnerability by sending a crafted packet to the vulnerable AD DS service. Successful exploitation could grant an attacker code execution on the vulnerable system.

CVE-2026-70279 is a spoofing vulnerability affecting Microsoft Exchange Server. It received a CVSSv3 score of 9.3 and is rated as important. It was assessed as “Exploitation More Likely.” An attacker could exploit this vulnerability by convincing a target through social engineering to click on a malicious link. Successful exploitation against a target with administrative privileges would allow an attacker to access or modify organizational data.

CVE-2026-70571 is a remote code execution vulnerability affecting Microsoft Exchange Server. It received a CVSSv3 score of 8.1 and is rated as critical. It was assessed as “Exploitation More Likely.”

An attacker could exploit this vulnerability by sending a malicious email to a vulnerable Microsoft Exchange server that would cause it to process the email using internal content-conversion. Successful exploitation would allow an attacker the ability to execute code on the Exchange server.

The following CVEs also merit attention based on severity, exploitability, or CVSSv3 score:

On October 13, the final year of Extended Security Updates (ESU) for Windows Server 2012 and Windows Server 2012 R2 ended. Microsoft will no longer release security updates for either version. To identify unsupported versions of Windows Server 2012, customers can use plugin ID 192813. To check the ESU status of Windows Server 2012 and 2012 R2 hosts, customers can use plugin ID 182965.

Extended support for Windows 10 Enterprise 2016 Long-Term Servicing Branch (LTSB) and Windows 10 IoT Enterprise LTSB 2016 also ended on October 13. To identify Windows 10 Enterprise 2016 LTSB, customers can use plugin ID 192817.

October 13, 2026 marks the end of mainstream support for Windows Server 2022. This month’s security update is the last one issued under mainstream support. The product now enters extended support, where it will continue receiving monthly security updates at no additional cost through October 14, 2031. Organizations still running Windows Server 2022 can begin evaluating an upgrade path to Windows Server 2025, the current LTSC release, which carries mainstream support through November 2029 and extended support through November 2034.

As of October 13, several Microsoft products have reached end of support. Since these products will no longer receive security updates, we recommend upgrading to supported versions as soon as possible.

• Office 2021
• Office LTSC 2021
• Office LTSC 2021 for Mac
• Skype for Business LTSC 2021
• Windows 11 Home and Pro Version 24H2

A list of all the plugins released for Microsoft’s October 2026 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

• .NET
• .NET Framework
• .NET and Visual Studio
• ASP.NET Core
• Active Directory Certificate Services (AD CS)
• Active Directory Domain Services
• Active Directory Federation Services (AD FS)
• Azure Active Directory
• Azure Arc
• Azure CycleCloud
• Azure DevOps
• Azure HDInsight
• Azure Key Vault
• Azure Storage Library
• Connected Devices Platform Service (Cdpsvc)
• Desktop Window Manager
• Dynamics Business Central
• Function Discovery Service (fdwsd.dll)
• Graphic Fonts
• HID Parser Library
• HID class driver
• Internet Explorer
• Linux Kernel
• Microsoft Account
• Microsoft Azure Attestation service and Device Health Attestation Service
• Microsoft Bluetooth Driver
• Microsoft COM for Windows
• Microsoft Configuration Manager
• Microsoft Defender
• Microsoft Defender for Endpoint
• Microsoft Digest Authentication
• Microsoft Exchange Server
• Microsoft Failover Cluster Virtual Driver
• Microsoft Graphics Component
• Microsoft Input Method Editor (IME)
• Microsoft Internet Messaging API
• Microsoft Local Security Authority Server (lsasrv)
• Microsoft MPEG-2 Video Extension
• Microsoft Office
• Microsoft Office Access
• Microsoft Office Click-To-Run
• Microsoft Office Excel
• Microsoft Office OneNote
• Microsoft Office Outlook
• Microsoft Office PowerPoint
• Microsoft Office SharePoint
• Microsoft Office Visio
• Microsoft Office Word
• Microsoft PostScript Printer Driver
• Microsoft Power Apps
• Microsoft PowerShell
• Microsoft PowerToys
• Microsoft QUIC
• Microsoft Scripting Engine
• Microsoft Streaming Service
• Microsoft Trace Data Helper
• Microsoft Windows Codecs Library
• Microsoft Windows Media Foundation
• Microsoft Windows PDF
• Microsoft Windows Search Component
• Microsoft XML
• Network Device Enrollment Service (NDES)
• Network Policy Server (NPS)
• OpenSSH for Windows
• Python
• Quality Windows Audio/Video Experience (QWAVE) service
• RPC Endpoint Mapper Service
• RPC Runtime
• Reliable Multicast Transport Driver (RMCAST)
• Remote Access Point-to-Point Protocol (PPP) EAP-TLS
• Remote Desktop Client
• Remote Desktop Display Driver
• Remote Desktop Gateway Service
• Role: DNS Server
• SQL Server
• SQLite
• Servicing Stack Updates
• Skype for Business and Microsoft Lync
• Software Protection Platform (SPP)
• SysInternals
• Virtual Hard Disk (VHD) Miniport Driver
• Visual Studio Code
• Visual Studio Tools for Applications and SQL Server Management Studio
• WebDAV
• Windows AI
• Windows ALPC
• Windows Advanced Rasterization Platform
• Windows Aggregated Data Platform Service
• Windows Ancillary Function Driver for WinSock
• Windows AppX Deployment Extensions
• Windows AppX Deployment Service
• Windows Application Compatibility Cache
• Windows Assigned Access
• Windows Audio Service
• Windows Autopilot
• Windows Background Intelligent Transfer Service (BITS)
• Windows Backup Engine
• Windows Bind Filter Driver
• Windows Biometric Service
• Windows BitLocker
• Windows Bluetooth A2DP driver
• Windows Bluetooth Port Driver
• Windows Bluetooth Service
• Windows Broadcast DVR User Service
• Windows CCFFilter Driver
• Windows CD-ROM Driver
• Windows COM+ Event System Service
• Windows Camera Frame Server Monitor
• Windows Cash Drawer Protocol Provider
• Windows Certificates
• Windows Client License Service
• Windows Client Side Caching driver (csc.sys)
• Windows Client for NFS
• Windows Client-Side Caching (CSC) Service
• Windows Clipboard Server
• Windows Clipboard User Service
• Windows Cloud Files Mini Filter Driver
• Windows Common Log File System Driver
• Windows Composite Image File System
• Windows Connected Devices Platform Service
• Windows Connected User Experiences and Telemetry
• Windows Console Driver
• Windows Container Isolation FS Filter Driver
• Windows Container Isolation FS Filter Driver (unionfs.sys)
• Windows Core Messaging
• Windows Credential Guard
• Windows Credential Manager
• Windows Credential Providers
• Windows Cryptographic Services
• Windows DCOM Server
• Windows DHCP Client
• Windows DHCP Server
• Windows DNS
• Windows DWM Core Library
• Windows Defender Firewall Service
• Windows Deployment Services
• Windows Device Association Service
• Windows Device Install Service
• Windows Diagnostic Policy Service
• Windows Direct Composition
• Windows Distributed File System (DFS)
• Windows EAPHost Service
• Windows Embedded Mode Service
• Windows Encrypting File System (EFS)
• Windows Enterprise App Management
• Windows Error Reporting
• Windows Event Logging Service
• Windows Event Tracing
• Windows Event Viewer
• Windows Failover Cluster
• Windows Fast FAT Driver
• Windows Fax and Scan Service
• Windows GDI
• Windows GDI+
• Windows Geotag Broker
• Windows Graphics Kernel
• Windows Group Policy
• Windows HTTP.sys
• Windows Health and Optimized Experiences Service
• Windows Hello
• Windows Host Guardian Service
• Windows Hyper-V
• Windows IKE Extension
• Windows IP Over USB Service
• Windows Image Acquisition
• Windows Imaging Component
• Windows Input System
• Windows Installer
• Windows Internal System User Profile
• Windows Internet (wininet.dll)
• Windows Internet Connection Sharing (ICS)
• Windows Internet Information Services
• Windows Internet Key Exchange (IKE) Protocol
• Windows Kerberos
• Windows Kernel
• Windows Kernel Mode Driver
• Windows Kernel-Mode Drivers
• Windows Key Distribution Center
• Windows Key Storage Provider
• Windows Libarchive
• Windows Local Security Authority (LSA)
• Windows Local Security Authority Subsystem Service (LSASS)
• Windows MIDI Service Module
• Windows Management Instrumentation
• Windows Management Services
• Windows Media
• Windows Media Player
• Windows Media Video Decoder
• Windows Message Queuing
• Windows Message Queuing Queue Manager
• Windows Mobile Broadband
• Windows Mobile Device Management
• Windows Modern Device Management (MDM)
• Windows NDIS
• Windows NTFS
• Windows NTLM
• Windows NetBIOS
• Windows Netlogon
• Windows Network File System
• Windows Network List Service
• Windows Network Load Balancing
• Windows Notification
• Windows Now Playing Session Manager
• Windows OLE
• Windows OLE DB
• Windows Overlay Filter
• Windows PCI Bus Driver
• Windows Paint
• Windows Partition Management Driver
• Windows Perception Simulation Service
• Windows Performance Monitor
• Windows Phone Service
• Windows Portable Device Enumerator Service
• Windows Portable Device File System Driver
• Windows Portable Device MTP Driver
• Windows PowerShell
• Windows Print Spooler Components
• Windows Program Compatibility Assistant Service
• Windows Projected File System
• Windows Push Notifications
• Windows Quality of Service (QoS) Packet Scheduler
• Windows RNDIS
• Windows Raw Image Extension
• Windows Registry
• Windows Remote Access Connection Manager
• Windows Remote Access Service Infrastructure
• Windows Remote Desktop
• Windows Remote Desktop Protocol
• Windows Remote Desktop Services
• Windows Remote POS Driver
• Windows Resilient File System (ReFS)
• Windows Resilient File System (ReFS) Deduplication Service
• Windows Resource Management (MRM)
• Windows Resume
• Windows Rich Text Edit Control
• Windows Routing and Remote Access Service (RRAS)
• Windows SMB Client
• Windows SMB Server
• Windows Schannel
• Windows Secure Boot
• Windows Secure Kernel Mode
• Windows Secure Socket Tunneling Protocol (SSTP)
• Windows Security Account Manager
• Windows Security App
• Windows Security Center
• Windows Security Support Provider Interface
• Windows Sensor Data Service
• Windows Server Update Service
• Windows Server for NFS
• Windows Setup Files Cleanup
• Windows Setup and Deployment
• Windows Shell
• Windows Smart Card
• Windows SmartScreen
• Windows Spaceport.sys
• Windows StateRepository API
• Windows Storage
• Windows Storage Port Driver
• Windows Storage Spaces Controller
• Windows Storage VSP Driver
• Windows Storport Miniport Driver
• Windows Subsystem for Linux
• Windows Sysmain Service
• Windows System Information Console
• Windows TCP/IP
• Windows Telephony Server
• Windows Text Services Framework
• Windows Text Shaping
• Windows UEFI
• Windows UI Immersive Server
• Windows USB Driver
• Windows USB Print Driver
• Windows USB Video Driver
• Windows Universal Disk Format File System Driver (UDFS)
• Windows Universal Plug and Play (UPnP) Device Host
• Windows Update
• Windows Update Delivery Optimization
• Windows Update Orchestrator Service
• Windows Update Service
• Windows Update Stack
• Windows User Profile Service
• Windows VHD miniport driver
• Windows VMSwitch
• Windows Virtual Input
• Windows Virtualization-Based Security (VBS) Enclave
• Windows Volume Manager Extension Driver
• Windows WLAN Service
• Windows WalletService
• Windows Web Account Manager
• Windows Wi-Fi Driver
• Windows Win32 Kernel Subsystem
• Windows Win32K
• Windows Win32K - GRFX
• Windows Win32K - ICOMP
• Windows Wired AutoConfig Service
• Windows Work Folders
• Windows Workstation Service
• Windows exFAT File System
• Windows iSCSI
• Windows kernel32.dll
• Winlogon

• Microsoft’s October 2026 Security Updates
• Tenable plugins for Microsoft October 2026 Patch Tuesday Security Updates

Critical infrastructure faces mounting threats from nation-state groups and AI-driven attacks. In the latest installment of our Cybersecurity Awareness Month blog series, learn how leading cybersecurity agencies, such as CISA, are advising critical infrastructure organizations on ways to protect themselves and the essential services they provide.

1. Critical infrastructure organizations often struggle with asset visibility gaps that create hidden attack vectors. Many older OT systems are difficult to inventory, leaving them unmonitored and unpatched.
2. Attackers are leveraging AI to map converged IT/OT networks at machine speed and exploit uninventoried legacy systems. Attackers are also using AI to attain the specialized know-how to breach complex industrial control systems.
3. Iran-affiliated APT groups have attacked U.S. water, energy, and government facilities since the U.S. launched Operation Epic Fury in February, according to the U.S. government.
4. As part of Cybersecurity Awareness Month, CISA is urging critical infrastructure operators to establish a solid cyber hygiene foundation, anchored on reducing vulnerabilities, replacing unsupported legacy devices, and preparing rapid recovery plans.

Cybersecurity Awareness Month 2026 finds critical infrastructure organizations facing a particularly daunting cyber risk landscape.

Always a prime target for cybercriminals, hacktivists, and nation-state hacking groups, critical infrastructure organizations this year have been grappling with a heightened threat from adversaries affiliated with Iran’s government, as documented by global cybersecurity agencies and researchers. Specifically, many of these nation-state groups have shifted their focus from stealthy cyber espionage activities to destructive cyber attacks designed to disrupt victims’ operations, experts have observed. 

In addition, critical infrastructure organizations, which often must secure complex environments where IT and operational technology (OT) converge, now also have to contend with AI-boosted cyber attacks.

Now in its 22nd year, Cybersecurity Awareness Month serves as a good reminder that critical infrastructure organizations can seek support and guidance from leading cybersecurity agencies, as well as from globally recognized cybersecurity organizations such as the Center for Internet Security (CIS) and the SANS Institute.

For example, this year, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) is focusing its Cybersecurity Awareness Month message on protecting U.S. critical infrastructure against cyber threats, riffing on the 250th anniversary of the country’s founding. By labeling this year’s campaign “Securing the Next 250,” CISA is signaling the importance of cybersecurity for the country’s future.

“From keeping America’s global competitive edge to ensuring vital services remain available to our citizens, U.S. critical infrastructure and those who own, operate, supply, or support it are the front line against successful cyber intrusions,” reads a CISA statement.

In this blog, we’ll outline key CISA advice aimed at helping critical infrastructure organizations mitigate the risk from cyber attackers, in particular nation-state hacking groups intent on disrupting essential services, such as water, electricity, transportation and healthcare.

Adversaries generally look for the easiest way to breach a targeted organization before resorting to more complex attacks. That’s why ensuring your organization has a solid cyber hygiene foundation is essential.

Along those lines, CISA this year is stressing recommendations and best practices that all critical infrastructure organizations can adopt to boost their core cybersecurity posture, regardless of their industry sector.

1. Educate your employees on how to recognize phishing attempts. Make it easy for them to report this and other suspicious activity to your security team.
2. Harden user account security by requiring the use of strong passwords and by adopting phishing-resistant multifactor authentication.
3. Update software promptly, fix misconfigurations, and patch the vulnerabilities that pose the highest risk to your organization.
4. Monitor and log your systems’ activity to spot attack attempts.
5. Back up and encrypt your data.
6. Draft an incident response plan, update it regularly, and conduct periodic practice drills.
7. Be ready to recover from system disruptions stemming from a breach, including by implementing workarounds that allow your organization to conduct essential functions while critical assets and resources are unavailable.

To make these foundational cybersecurity best practices easier for critical infrastructure operators to remember, CISA is emphasizing what it calls the three R’s:

1. Reduce vulnerabilities.
2. Replace devices that vendors no longer support.
3. Recover quickly to maintain operations.

To get more details about these three cybersecurity pillars for critical infrastructure organizations, CISA recommends security teams check out its: 

• Binding Operational Directive “Prioritizing Security Updates Based on Risk” (BOD 26-04), published in June
• BOD 26-02 “Mitigating Risk From End-of-Support Edge Devices,” published in February
• CI Fortify initiative

Meanwhile, CISA and the cybersecurity agencies of Australia, Canada, Germany, the Netherlands, New Zealand, and the U.K. published earlier this year joint guidance for protecting OT systems, especially in critical infrastructure.

“Exposed and insecure OT connectivity is known to be targeted by both opportunistic and highly capable actors. This activity includes state-sponsored actors actively targeting critical national infrastructure (CNI) networks,” reads the joint guide, titled “Secure connectivity principles for operational technology.”

“Strengthening the cyber security of CNI, including securing OT connections, can challenge attackers’ efforts and raise the threshold necessary to cause physical harm, environmental impact, and disruption,” the document adds.

That joint guide outlines eight core principles for securing OT environments:

1. Balance the risks and opportunities.
2. Limit the exposure of your connectivity.
3. Centralize and standardize network connections.
4. Use standardized and secure protocols.
5. Harden your OT boundary.
6. Limit the impact of compromise.
7. Ensure all connectivity is logged and monitored.
8. Establish an isolation plan.

A group of advanced persistent threat (APT) groups affiliated with Iran’s government has been carrying out ongoing attacks against U.S. water, energy, and government facilities since the U.S. launched Operation Epic Fury against the Middle East country in February, various U.S. government agencies warned in a joint advisory published in April and updated in July.

By targeting internet-connected OT devices, such as programmable logic controllers (PLCs), these APT groups have successfully disrupted the operations of multiple U.S. critical infrastructure organizations, causing them financial losses, according to the joint advisory. 

“As a result of this activity, organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files and the manipulation of data displayed on human-machine interface (HMI) and supervisory control and data acquisition (SCADA) displays. In a few cases, this activity caused operational disruption and financial loss,” reads the advisory.

The tactics, techniques, and procedures (TTPs) are consistent with those employed by the CyberAv3ngers, a nation-state group the U.S. government previously identified as operating under Iran's Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC).

The joint advisory urges security teams at U.S. critical infrastructure organizations to review the document’s TTPs and indicators of compromise (IOCs), and implement recommended mitigation measures, such as: 

• Install PLCs following manufacturers' guidelines and security best practices.
• Use secure gateways and firewalls to remove PLCs from direct internet exposure.
• Review your system logs to look for IOCs and for suspicious traffic on ports used by OT devices.

Tenable Research provides a deep dive on the CyberAv3ngers group in the blog “What to kow about CyberAv3ngers: The IRGC-linked group targeting critical infrastructure.”

Tenable Research has also documented how cyber adversaries linked to Iran’s Ministry of Intelligence and Security (MOIS) have intensified their attacks against the U.S. and other countries this year.

In the blog “Cyber retaliation: Analyzing Iranian cyber activity following Operation Epic Fury,” Tenable Research explains how Iranian-linked actors shifted their focus from stealthy espionage to coordinated, destructive campaigns targeting organizations in a variety of sectors, including critical infrastructure.

You can find more details about the threat from Iran-affiliated attackers in this Information Technology-Information Sharing and Analysis Center (IT-SAC) joint advisory.

Like all cyber defenders, the security teams in charge of protecting critical infrastructure organizations are grappling with adversaries’ use of AI to make their attacks stealthier, faster, smarter, and unpredictable.

However, critical infrastructure organizations’ security teams face unprecedented challenges when trying to prevent or respond to an AI-boosted attack, especially if their environment has both IT and OT systems.

These are some of the complicating factors for critical infrastructure security teams when addressing AI-aided attacks:

• After gaining initial entry via the IT environment, attackers using AI-driven automation can map the converged network, pivot and discover pathways into the organization’s OT infrastructure, all at machine speed.

• IT and security teams struggle to comprehensively inventory OT environments. For starters, many legacy OT systems lack standard discovery protocols like Simple Network Management Protocol (SNMP), meaning they can’t “announce” themselves to modern asset-inventory tools like IT systems do. 

  Legacy OT systems also often don’t respond well to active scanning, which can cause them to crash, potentially disrupting a community’s essential services. In addition, OT assets are rarely housed in data centers, but rather can be scattered across myriad physical locations, such as within electrical substations, throughout a city’s water system, or in offshore oil rigs.

  These asset visibility gaps create a massive risk, because uninventoried OT systems may not be getting monitored or patched regularly, making them low-hanging fruit for attackers who use AI to map OT environments and find vulnerable OT assets in a flash.

• Traditionally, compromising an industrial control system (ICS) required specialized engineering knowledge of these assets. But today, attackers can enlist an LLM to quickly provide detailed information about the design of a particular ICS, how it works, how it communicates with other systems, and plan how to breach it accordingly.

The White House’s Executive Order 14409, “Promoting Advanced Artificial Intelligence Innovation and Security,” drives home the importance of protecting critical infrastructure organizations against AI-driven attacks.

Specifically, the EO calls for the federal government to facilitate access to cybersecurity tools and services, including covered frontier AI models, for critical infrastructure operators, so these organizations can strengthen their cybersecurity. The Tenable blog, “The June 2026 AI Executive Order: What federal agencies need to know and how Tenable can help,” unpacks the EO in detail. 

For granular guidance on the intersection of AI and OT, we recommend you watch Tenable’s two-part webinar series “Frontier AI for OT,” which addresses topics including:

• Strategies to protect OT assets that you can’t patch, such as preemptively using tools that discover OT weaknesses at machine speed, and implementing strict OT network choke points and access controls
• Ways to prevent how attackers exploit the communications between your OT devices, including using machine learning systems to identify and analyze attack paths, and leveraging agentic AI to run continuous attack simulations
• Adopting an AI-driven exposure management platform like Tenable One, which helps you: 
  • Unify security data across all your OT and IT assets
  • Identify and prioritize the most critical threats
  • Automate workflows using agentic AI
  • Conduct guided remediation

Check back here next week, when we’ll continue our Cybersecurity Awareness Month series with a blog about how to mitigate the cyber risk from shadow AI. And if you missed it, read the first blog in this series: "How to mitigate the risk from AI-generated apps built by your 'citizen coder' employees."

Community-built AI agents, skills, and MCP servers are landing in SOC workflows fast. Here’s what the Exchange Inspector tests before a listing earns its vetted tag on the CyberAgents Exchange.  Three tools have already passed.

1. Every Inspector-vetted listing clears three gates: an automated check, a frontier model assessment, and human verification. Tenable uses Tenable One AI Exposure to screen for prompt injection and exposed secrets, and OpenAI GPT Cyber models to assess the code and threat model. Tenable security researchers then verify runtime behavior in a clean environment. 
2. The review tests 15 types of security issues across three layers of the stack. These issues range from conventional flaws like SSRF and path traversal vulnerabilities to agent-specific ones like excessive permissions and memory poisoning.
3. Vetted tools are driving efficiencies: SOC Hunter has cut hunt times by 75% for Tenable’s security team. The CyberAgents Exchange currently has three Exchange Inspector-vetted listings: two built by Tenable and the other one by Splunk. These agents’ contributors report that they accelerate threat hunting, remediation triage, and cloud posture investigation.

Security teams are increasingly deploying AI agents to triage alerts, correlate threat intelligence, investigate suspicious activity, and prioritize vulnerabilities across their environments. It’s critical to know what these AI agents will do before you deploy them to a production environment. An agent carries credentials, calls tools, and acts on what it reads, so its blast radius is bigger than the one from a typical open-source library.  Software supply chain attacks have taught us what happens when a registry trusts contributors by default.

The CyberAgents Exchange, powered by Tenable, is an open-source, vendor-agnostic directory for security practitioners to discover, share, and deploy agentic AI. Contributors keep their code in their own public GitHub repositories, so visitors to the CyberAgents Exchange can read it before they run it in their organizations. The directory covers a broad range of the SecOps stack:

• Agents take on the recurring, multistep work that would otherwise slow down security practitioners. AI agents autonomously plan the steps and call the security tools on their own, so analysts spend their time making decisions instead of gathering data. Current agent listings on the CyberAgents Exchange monitor scanner and platform health, assess cloud posture, map external attack paths, triage CVEs and indicators of compromise, generate remediation code, and quantify cyber risk in dollars.
• Model Context Protocol (MCP) servers connect AI agents to the tooling that security teams already use. Practitioners can analyze and act on live data in plain language instead of learning and writing API code. Current MCP server listings cover a wide gamut of vulnerability, identity, operational technology, firewall, and SecOps integrations, and expose capabilities such as mapping of MITRE ATT&CK findings and guardrailed configuration changes.
• Skills capture security experts’ methods as instructions and scripts that AI agents follow. Security practitioners get the same rigorous results on demand, without having to meticulously build their workflows from scratch. Current skill listings on the CyberAgents Exchange prioritize remediation, hunt threats, analyze malware and phishing samples, troubleshoot scans, build executive reports, and prepare compliance evidence.
• Playbooks chain agents, skills, and MCP servers into one workflow, so a whole process runs end-to-end rather than as a series of manual handoffs. Current playbook listings on the CyberAgents Exchange triage reported phishing emails, narrow thousands of findings to a few verified fixes, and coordinate entire fleets of specialized agents to facilitate multiple steps of the exposure management process.

Openness makes the CyberAgents Exchange useful, but it also makes a review process necessary. That’s why Tenable built the CyberAgents Exchange AI Inspector. We announced the Exchange Inspector in September and are now able to share some of our initial findings.

When Tenable created the CyberAgents Exchange, we knew each submission should receive a baseline review before being accepted into the directory, and that some submissions should receive deeper scrutiny. The baseline review has been in place since the initial release. We then created a process for performing deeper, vetted submission reviews. 

The baseline review started as a manual process that was quite resource-intensive and took days to complete, depending on submission type. As the process proved effective, we converted portions of it into skills to perform data collection and analysis, and to then create artifacts for the reviewer. 

The Exchange Inspector combines Tenable’s exposure detection, OpenAI’s frontier models, and human review into a single vetting process for select CyberAgents Exchange listings. We developed it through Tenable’s participation in the OpenAI Daybreak Defense Network, and it’s the first major release from that collaboration. Each stage catches a different class of problem, and a listing has to clear all three.

Every reviewed candidate listing first runs through the skills-inspection engine in Tenable One AI Exposure, using the same technology that discovers and assesses the AI agents already running across your environment. 

At the time of a contribution review, the Exchange Inspector parses the agent’s instructions, the tools it’s authorized to invoke, and the data it’s permitted to reach, then flags prompt injection and jailbreak attempts, hidden instructions, hardcoded secrets, personally identifiable information (PII) exposure, and sensitive data access.

This is the fast, repeatable pass. It clears what’s obviously safe, blocks what’s obviously unsafe, and hands everything else to a deeper review with its findings attached.

The submission then moves into a frontier AI-driven assessment leveraging OpenAI GPT Cyber models available through our Daybreak access. 

• Standard models handle baseline review. 
• Daybreak Blue supports source code review and dual-use components. 
• Daybreak Red is reserved for higher-risk submissions that need exploit validation and adversarial security testing.

Tenable uses the models to assess the full attack surface of an agent rather than relying only on known-signature matching by theorizing and testing:

• How untrusted content could reach the model
• What a hijacked or rogue agent could do with its tool permissions
• Where a chain of individually harmless actions becomes a harmful one 

This is the stage that is designed to help identify potential threats that a static scanner may not surface.

Tenable’s security research team makes the final call by:

• Validating the automated and frontier findings 
• Executing the component in a clean environment to verify its runtime behavior matches its description
• Producing a durable, auditable record for every review: provenance, threat model, source review, and runtime verification. That record is what separates a vetted tag from a one-time automated pass. It can be a strong indicator of confidence for a CISO when approving a community tool for production.

A listing that passes all three stages is promoted to Exchange Inspector vetted status and carries the tag on the CyberAgents Exchange. You can filter CyberAgents Exchange's search to see vetted listings only.
 

SOC-Hunter listing with the Exchange Inspector's vetted tag
 

Below you can see an excerpt of an Exchange Inspector sample report showing the provenance, threat model, source review, and runtime verification sections.
 

Agentic AI can have every conventional software flaw, plus an entire new class of issues of its own. Now, every model’s reasoning, memory, and tool access are part of the attack surface. Tenable identified 15 classes that every Exchange Inspector review covers at the model, application, and infrastructure layers. They’re the floor, not the ceiling. Using OpenAI GPT Cyber models, the Exchange Inspector applies frontier reasoning to assess how a threat actor could abuse a specific agent, MCP server, or skill rather than matching it against a predetermined list, surfacing flaws that don’t yet have a name.

Issues at the model layer affect the model’s reasoning, memory, and decision-making capabilities, as well as its direct interactions with users and other agents, including:

• Prompt injection and instruction hijacking: This is the manipulation of a system where the model treats untrusted content, hidden inputs, or multi-step attacks as authoritative instructions, effectively overriding system policies and blurring the boundary between data and commands.
• Excessive agency and unsafe autonomy: Granting an agent access to overly broad tools or unbounded autonomy allows it to execute potentially destructive, out-of-scope, or long-running actions without proper limits or user confirmation.
• Skill and playbook integrity: When operational playbooks or skills are manipulated, ambiguous steps, missing preconditions, or embedded commands expand the agent’s authority beyond its intended scope or act as a stealthy persistence mechanism.
• State, memory, and context integrity: The corruption or improper retention of an agent’s memory occurs when an agent saves information it shouldn’t trust, holds onto sensitive details longer than necessary, or lets one user’s data leak into someone else’s session.
• Human approval and user-intent failures: Effective user oversight breaks down when confirmation prompts hide crucial consequences, agents reuse approvals to authorize broader actions than intended, or high-impact operations are disguised within routing workflows. Some examples include approving a file edit once and silently extending that to deleting files later, or a list-alerts skill that also silently acknowledges or closes the alert.

Issues at the application layer reside in the software wrapping the model, including how it handles data, interfaces with tools, manages permissions, and formats outputs.

• Tool and MCP server security: Weaknesses in tool implementation are characterized by inaccurate capability descriptions, missing input validation, unsafe defaults, unverified outputs, and susceptibility to various injection or protocol-spoofing attacks.
• Secrets and credential handling: The exposure or mishandling of sensitive keys, tokens, or credentials includes leaking secrets in prompts, logs, or tool outputs, granting tokens overly broad scopes, or failing to redact sensitive data from the model’s context.
• Data exfiltration and privacy: The unauthorized extraction or leakage of sensitive workspace data happens through arbitrary outbound network requests, boundary-crossing retrievals, or the improper combination of individually harmless data into sensitive conclusions.
• Output handling and downstream injection: These risks arise when unverified model outputs are directly inserted into downstream systems, leading to formula injection, terminal escapes, cross-site scripting (XSS), or the execution of unsafe generated files and links.
• Conventional application vulnerabilities: Standard software security flaws affect the surrounding application infrastructure, including injection, cross-site scripting, cross-site request forgery (CSRF), broken access control, cryptographic misuse, and business-logic flaws.

Issues at the infrastructure layer exploit the underlying physical or virtual environments, network configurations, external dependencies, and system resources.

• Filesystem and workspace safety: Flaws allow unauthorized reading, writing, or destructive operations on a filesystem include path traversal, unsafe temporary-file handling, archive extraction vulnerabilities, and following malicious repository configurations.
• Code and command execution: Unauthorized or unsafe execution of code and commands stem from shell injections, the dynamic evaluation of model-generated code without strict sandboxing, environment manipulation, or vulnerable build scripts.
• Network and web security: Traditional and agent-specific network flaws include server-side request forgery (SSRF), open redirects, DNS rebinding, unrestricted egress, and insecure webhooks lacking proper authentication or TLS verification.
• Supply-chain and dependency risks: Vulnerabilities introduced through third-party components include unpinned packages, typosquatting, unverified artifact execution, and compromised update channels that grant excessive permissions to outside code.
• Denial of service and resource abuse: These attacks are designed to exhaust system resources or incur excessive financial costs through unbounded prompts, infinite tool loops, parser and archive bombs, queue starvation, or rate-limit bypasses.

The first Exchange Inspector vetted listings are running in production today with tested, repeatable, and quantifiable results for threat hunting, cloud posture triage, and remediation prioritization.

Built and used daily by Tenable’s enterprise security team, the SOC-Hunter skill brings structured, hypothesis-driven threat hunting to an incident responder’s terminal. It runs as a skill in Claude Code, follows the LOCK pattern (Learn, Observe, Check, Keep). It uses MCP to query: 

• Security information and event management (SIEM) systems
• Endpoint detection and response (EDR) systems
• Vulnerability management systems
• Cloud security posture management (CSPM) systems
• Cloud security access brokers (CASB)
• Code search from one session 

Every finding maps to MITRE ATT&CK with live Structured Threat Information eXpression (STIX) coverage analysis.

The payoff is clear and measured. A hunt that took four to six hours across eight or more browser tabs now takes 45 to 90 minutes in a single terminal, a 75% time reduction. SOC-Hunter keeps a persistent memory of past hunts, false positives, and detection gaps, so it gets sharper with every run.

The Splunk Tenable Cloud Security Skill lets SOC analysts and cloud security engineers investigate Tenable One Cloud Exposure findings already ingested in Splunk through an AI assistant and the official Splunk MCP Server. It ships three production-ready workflows: finding inventory, cluster and workload triage, and Tenable policy and account exposure.

What used to take more than an hour of Search Processing Language (SPL) now takes a couple of minutes using the skill, according to the Splunk contributor. Operational safety is the design center. It enforces count-first SPL guardrails, explicit time boundaries, and read-only defaults so a query can’t overwhelm the index or alter data, and it falls back to the CLI when a resource can’t be validated. 

The Remediation Priority & Impact Agent is an automated security tool designed to streamline vulnerability management and combat alert fatigue. By pulling data directly from a Tenable environment, the agent analyzes raw security alerts and transforms them into a highly actionable, prioritized list of necessary fixes. This tool serves as an intelligent filter that identifies exactly what to patch first.

This agent uses a multidimensional approach to risk ranking. Rather than relying solely on basic vulnerability scores, it contextualizes the Tenable data against the MITRE ATT&CK framework, specific business criticality metrics, and the overall impact of the proposed remediation. This ensures that IT and security professionals are strategically focusing their efforts on the vulnerabilities that pose the most immediate and critical threats to their business operations.

Community-driven security only works if the community can trust what it shares. The Exchange Inspector gives practitioners insight into which AI components have been through an enterprise-grade security review and gives CISOs reliable evidence when deciding whether or not to approve them. The CyberAgents Exchange itself stays free and open-source, with no fees to list or use anything in it.

Tenable has currently reserved vetting for a handful of listings, and we’ll add more to the vetted list at our discretion as the CyberAgents Exchange grows. The same skills inspection provided as part of the Exchange Inspector review is also available for agents in your own environment through Tenable One AI Exposure. Request a demo of Tenable One AI Exposure to see the skills inspection functionality in action.

• Browse the Exchange Inspector vetted listings
• Read the press release "Tenable Uses OpenAI GPT Cyber Models to Advance Agentic Security Review in the CyberAgents Exchange"
• Learn more about the Exchange Inspector and the CyberAgents Exchange Security Review Process
• See Tenable AI Exposure in action, request a demo today

AI tools let non-technical employees build workplace apps in minutes with natural language prompts. While these AI-generated apps boost productivity, they can create severe security and data risks. As Cybersecurity Awareness Month kicks off, we’re sharing how Tenable adopted a structured governance framework that allows our “citizen coders” to build secure and compliant apps with AI.

1. Unsanctioned applications that non-technical staff build using AI tools often bypass quality assurance and testing, creating shadow AI risks. Without IT and security oversight, these applications can go into use with critical vulnerabilities and misconfigurations, as well as weak data protection.
2. Even when “citizen coders” comply with their organizations’ policies and processes, the number of applications they build using AI tools can become overwhelming and disruptive for the IT and security teams.
3. Governance works better than blanket bans, because prohibiting AI-aided development usually causes employees to keep their app development activities hidden. Tenable has found that implementing a structured, multi-tiered governance framework gives employee citizen coders the security and compliance guardrails they need.
4. An effective governance framework should combine peer leadership and training. While AI leaders in each department are tasked with overseeing tool approvals, managing app dev request queues, and tracking applications’ ROI, “citizen coders” should receive mandatory security and compliance awareness training.

AI tools are making it easier than ever for non-technical employees to spin up workplace applications in minutes. Even staffers who have never written a single line of code, let alone set up a database, are jumping on the AI vibe-coding bandwagon, often encouraged by their team leaders

First, the good news: These AI-generated applications can help boost employees’ productivity by automating workflows and streamlining processes. And if employees can build their own applications, the workload on your perennially busy professional developers shrinks.

Now the bad news: If employees whip up and deploy them without the oversight of the IT and security teams, these applications become shadow AI assets with security and compliance issues that put your systems and data at risk.

Even in scenarios where employee citizen coders adhere to company guidelines, the sheer number of AI-built applications they produce can easily swamp IT and security teams, a trend that’s intensifying as business leaders urge non-technical staffers to use AI to develop their own software tools.

So how can an organization address this threat from employee citizen coders? Spoiler alert: A draconian, across-the-board prohibition won’t work, and in fact will likely backfire, as employees may then deliberately try to hide their AI-aided application development activities. 

In this blog, the first in Tenable’s weekly Cybersecurity Awareness Month series, we’ll share lessons learned and concrete best practices from Tenable’s internal cybersecurity team aimed at establishing policies and controls designed to curb this shadow AI risk from your employee citizen coders.

The cyber risks of unsanctioned applications that employee citizen coders build aren’t new. The issue rose to prominence years ago when low-code / no-code development platforms gained widespread popularity. 

Of course, generative AI tools that can create fully-functioning applications from a natural-language prompt have exacerbated the issue by turning practically anyone into a developer. And unlike low-code / no-code platforms hosted as software-as-a-service (SaaS) and monitored by the organization, generative AI products tend to be consumer-grade tools that employees can access and use individually.

These citizen coder applications can create a wide variety of security and compliance risks, as organizations, including the Open Worldwide Application Security Project (OWASP) in its OWASP Citizen Development Top 10 list, have documented.

Below, we highlight common security and compliance issues in AI-generated citizen-coder applications that employees create without permission and oversight from the IT and security departments:

• Due to lack of testing, scanning, and quality assurance checks, their code can have critical vulnerabilities and dangerous misconfigurations, as well as contain risky open-source components.
• They may insecurely access company critical systems and store sensitive data.
• They will not be updated, patched, monitored, logged, nor be included in backup and disaster recovery plans.
• They may have excessive permissions and privileges, and the organization’s identity and access management (IAM) systems won’t protect them.

Even when employee “citizen coders” alert and involve the IT and security teams, organizations are finding that the number of these applications has spiked to such a degree that it’s become burdensome to review, approve, and onboard them. 

In other words, in an average large organization there may be hundreds of employees building applications that they feel are worth seeing the light of day. IT and security suddenly face the daunting task of assessing each one, and deciding which are truly worth the cost and effort of securely deploying and maintaining them throughout their lifecycle.

If these applications consume AI tokens to function, costs can add up quickly. For example, it’s not uncommon for citizen coders to leverage their legitimate access to business applications and create their own local data lakes to help power their vibe-coded application. In addition to the cost issue, the creation of these siloed data lakes creates dangerous data sprawl. 

At Tenable, we allow non-technical citizen coder employees to develop workplace applications, and as such, we’re not immune to the risks outlined above. However, we have found that establishing a strong governance foundation goes a long way towards preventing problems, not just the ones associated with citizen coders but with overall employee AI usage.

Specifically, Tenable has implemented a comprehensive five-tier AI governance framework, where at one end the executive leadership sets the direction, while at the other end lies daily community use guided by clear policies and peer oversight.

In the case of citizen coders specifically, this means, for example, that the do’s and don’ts of AI-aided citizen coding aren’t determined by individual business units independently, but are rather established uniformly company-wide.

These are the five tiers of Tenable’s AI Governance Model.

• Tier 1: Strategy 

The Executive Staff charts the course by providing strategic alignment, investment guidance, and prioritization for AI initiatives.

• Tier 2: Governance

An AI Governance Board and AI Technical Council create AI policies and guidance documentation, such as lists of approved AI tools. They explicitly own compliance, data privacy, and model risk, while also overseeing AI tool enablement, architecture, and design.

• Tier 3: Execution

AI Functional Leads and R&D Champions drive specific use cases, manage departmental adoption, and measure productivity results.

• Tier 4: Enablement

The Enablement Working Group, led by IT, Learning & Development (L&D) and Corporate Communications, handles hands-on training, resource distribution, and enterprise demonstrations.

• Tier 5: Community

Dedicated Slack channels for AI usage questions, AI engineering, and other topics offer employees support and a forum for crowdsourcing solutions.
 

With respect to citizen coders specifically, this AI governance model helps Tenable ensure that our IT and security experts establish foundational protections, guardrails, and controls for AI-generated applications. That’s because groups within the governance framework own the requirements for issues such as data privacy, compliance, and model risk, as well as for AI tool enablement, design, and architecture.

A key element for mitigating citizen coder risks are Tenable’s AI Functional Leaders, which sit on the governance framework’s third tier — execution. 

Originally conceived as simple project coordinators, this group now operates within a strict governance role with direct authority and accountability over AI skill approvals, operational queues, and organization-wide AI adoption.

These leaders are accountable for all AI use, development, and deployment across their respective departments. For example, there are AI Functional Leaders in sales, tech support, marketing, human resources, legal, infosec, finance, engineering, product management, and several other departments.

AI Functional Leads are heavily involved in their department’s use cases. By overseeing all requests for new skills, connectors, and data access, the AI Functional Leads can flag, for example, the use of unvetted external AI components in citizen coder applications before they reach production.

Security and compliance issues related to AI usage, including applications citizen coders build, usually stem from a lack of knowledge about how to prevent these problems. That’s why Tenable has tied AI tool access directly to mandatory security training and responsible usage training, and in turn complements it with live webinars, pre-built courses, tool-specific deep dives, and weekly show-and-tell sessions. This way, employees in general, and citizen coders in particular, know they have access to vetted resources and expert peer support.

The citizen coder revolution is here to stay. Non-technical employees equipped with generative AI tools will continue to build applications, especially as their team leaders nudge them to experiment with vibe coding.

At Tenable, we have found that implementing a solid governance framework provides a critical foundation for mitigating the risks associated with employees’ AI use, and specifically offers citizen coders guardrails to securely build AI-generated applications that help boost their productivity and efficiency. 

Have we completely solved the security and compliance challenges from citizen coder-built applications? Not by a long shot. The risks from employee vibe coding, along with those from AI use in general, are constantly morphing. But we feel that our governance framework gives us a solid foundation for tackling these and other AI usage challenges, as they emerge and evolve. 

Our Cybersecurity Awareness Month blog series continues next week, when we’ll tackle the challenges that critical infrastructure organizations face today.

CVE-2026-88771 and CVE-2026-88772, two zero-day vulnerabilities in Citrix NetScaler, have been confirmed as exploited in the wild. Citrix released patches on September 27, 2026. On October 3, Citrix disclosed CVE-2026-88779, an exploited denial of service flaw affecting SAML deployments. Fixing it requires newer builds.

Update October 4: On October 3, Citrix published security bulletin CTX697174 with fixed versions for CVE-2026-88779, an exploited denial of service vulnerability affecting NetScaler deployments configured for SAML. Post updated with details on CVE-2026-88779, findings from Mandiant and Google Threat Intelligence Group (GTIG) on the exploitation of CVE-2026-88772, CISA KEV additions, public proof-of-concept tooling, and expanded mitigation and hunting guidance.

Update October 4: On October 3, Citrix published security bulletin CTX697174 with fixed versions for CVE-2026-88779, an exploited denial of service vulnerability affecting NetScaler deployments configured for SAML. Post updated with details on CVE-2026-88779, findings from Mandiant and Google Threat Intelligence Group (GTIG) on the exploitation of CVE-2026-88772, CISA KEV additions, public proof-of-concept tooling, and expanded mitigation and hunting guidance.

Update September 27: Citrix published security bulletin CTX697096, confirming CVE-2026-88771 and CVE-2026-88772 as the two zero-day RCE vulnerabilities and releasing patches. Post updated with CVE IDs, CVSS scores, patch versions, and IoC guidance.

September 27: Original publication based on limited public information ahead of Citrix's official advisory.

1. Citrix has confirmed two critical zero-day vulnerabilities in NetScaler ADC and NetScaler Gateway, both capable of remote code execution and actively exploited in the wild. A third vulnerability, CVE-2026-88779, can cause denial of service on SAML-enabled deployments and has also been exploited.
2. Citrix released patches on September 27, 2026, and newer builds on October 3, 2026. Organizations that use SAML and already upgraded to the September 27 builds need to upgrade again. Citrix recommends that every customer move to the newest builds.
3. According to Mandiant and Google Threat Intelligence Group (GTIG), exploitation of CVE-2026-88772 began no later than early September. Organizations should check for signs of compromise and preserve evidence before patching.

Tenable's Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding zero-day vulnerabilities in Citrix NetScaler that have been exploited in the wild. The following FAQ was originally based on limited public information and has been updated as Citrix and security researchers published details. This post was last updated on October 4, 2026 following publication of the Citrix security bulletin for CVE-2026-88779.

Security researcher Kevin Beaumont dubbed this incident “PitScaler” on September 28, and the name has since appeared in press coverage of CVE-2026-88771 and CVE-2026-88772. An independent website, PitScaler, tracks the incident and collects government advisories and published research in one place.

What is the source of the NetScaler vulnerabilities?

On September 25, 2026, reports surfaced through a reddit post on r/Citrix regarding advice to shut down “Netscalers.” This included a report from a user that said this information came from the “Dutch national cyber security center” and further details included a note about two zero-day vulnerabilities.

On September 26, 2026, additional reports confirming the existence of these flaws became public, including social posts from researchers at watchTowr on X, as well as Kevin Beaumont on Mastodon.

What is the context surrounding the Dutch National Cyber Security Centre (NCSC-NL) alert?

The Reddit post on r/Citrix cited details from an NCSC-NL pre-notification that had not yet been made public. Community members in that thread said the pre-notification was distributed under Traffic Light Protocol (TLP):AMBER+STRICT restrictions. Tenable's RSO has not independently obtained or reviewed the contents of this notification.

Has Citrix confirmed the presence of zero-day vulnerabilities?

Yes. Citrix published a security bulletin (CTX697096) on September 27, 2026, confirming two zero-day vulnerabilities and noting that both CVEs have been observed being exploited against customer deployments.

What are these zero-day vulnerabilities?

Citrix has confirmed two zero-day vulnerabilities in NetScaler ADC and NetScaler Gateway. CVE-2026-88771 affects all deployments, including default configurations. CVE-2026-88772 only affects appliances with Datagram Transport Layer Security (DTLS) turned on, which VPN virtual servers have out of the box.

Analysis by Mandiant and GTIG suggests attackers exploit CVE-2026-88772 by sending malformed DTLS traffic to the appliance, which gives them root-level access.

Citrix also addressed six additional vulnerabilities affecting various configurations:

watchTowr originally confirmed details for the zero-days on September 26, 2026:

We have been made aware of further info, which we are sharing. We had no idea Citrix sysadmins were like GTA6 fans - so friendly 🤗

Please, direct further questions to Citrix. We are not Citrix PSIRT (despite it occasionally looking that way).

Citrix comms & patches are… https://t.co/OemTXwG8PB

— watchTowr (@watchtowrcyber) September 26, 2026

What is CVE-2026-88779?

CVE-2026-88779 is a memory overflow vulnerability in NetScaler ADC and NetScaler Gateway. Exploiting it can cause a denial of service. It received a CVSSv4 score of 8.7. Citrix disclosed it on October 3 in security bulletin CTX697174 and credited Bishop Fox and watchTowr in the bulletin.

Citrix says it has “observed targeted attacks on unmitigated NetScaler deployments.” CISA added CVE-2026-88779 to its KEV catalog on October 4.

Only appliances configured as a SAML service provider (SP) or SAML identity provider (IdP) are affected. Administrators can check their NetScaler configuration for either of the following entries:

• add authentication samlAction (SAML SP)
• add authentication samlIdPProfile (SAML IdP)

According to Citrix, the flaw affects service availability, and so far it has found no impact on customer data integrity. In its October 3 update on the SAML issue, the Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC) says an attacker targeting this flaw “may induce system crashes, denial of service and potential exploitation,” and that Australian organizations have been affected.

Are these zero-day vulnerabilities related to CVE-2026-19490 and CVE-2026-19489?

No. Neither CVE-2026-19490 nor CVE-2026-19489 appears to be related. Both are previously disclosed NetScaler ADC and NetScaler Gateway flaws that already have patches. CVE-2026-19490 was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on September 9, 2026.

Reports say these vulnerabilities were exploited. How widespread are the attacks?

Mandiant and GTIG published findings on September 29 showing that CVE-2026-88772 has been exploited since at least early September. They observed evidence that organizations across government, education, technology, financial services, and legal and professional services in North America and Europe were likely affected. On September 30, ASD’s ACSC said it had received reports from Australian organizations confirming exploitation, and it recommends that organizations look for evidence of compromise dating back to at least September 4.

On September 26, before patches were available, Kevin Beaumont stated: “The Netscaler zero day thing is real, being used in active attacks. No patch yet, if sensitive to Netscaler vulns switch it off.”

How many Citrix NetScaler vulnerabilities have been exploited in the wild in the past?

Citrix NetScaler devices have historically been a popular target for attackers. As of October 4, 2026, CISA’s KEV catalog had 18 entries for NetScaler ADC and NetScaler Gateway (including those listed under the former Citrix ADC name) and 27 entries for Citrix products overall, including CVE-2026-88771, CVE-2026-88772 and CVE-2026-88779. The RSO team has covered several notable incidents:

Which threat actors are exploiting these vulnerabilities?

No threat actor has been publicly named. In attacks exploiting CVE-2026-88772, Mandiant and GTIG identified two new malware families, WHIPSHOT and SLAPSHOT.

For context, based on our research, roughly two-thirds of threat actor activity targeting Citrix NetScaler over the last seven years involved advanced persistent threat (APT) groups, while one-third involved ransomware groups and their affiliates.

Is there a proof-of-concept (PoC) available for these vulnerabilities?

Yes. watchTowr published technical analyses of CVE-2026-88771 and CVE-2026-88772, along with tools that demonstrate code execution for each. watchTowr released them to help defenders, but they also work as public PoCs, with some limitations. As of October 4, 2026, we are not aware of a public PoC for CVE-2026-88779.

Are patches or mitigations available?

Yes. Citrix urges customers running affected versions to install one of the updated versions. Organizations whose NetScaler appliances are configured for SAML need the newer builds released on October 3 to address CVE-2026-88779.

Citrix says deployments affected by CVE-2026-88778 also need to turn on Enhanced ISN Generation in their TCP settings.

Until organizations can install the newer builds, Citrix has released Global Deny List signatures that can help mitigate CVE-2026-88779 on standard (non-FIPS) 14.1 and 13.1 appliances that are already running the September 27 builds and managed through NetScaler Console. Citrix’s blog lists the requirements.

For CVE-2026-88772, Mandiant suggests blocking inbound UDP port 443 at an upstream firewall and turning off DTLS on gateways that don’t use it. These steps do not address CVE-2026-88771, so installing a fixed build is still required.

Citrix’s bulletins list fixes only for the 14.1 and 13.1 branches. NetScaler ADC and NetScaler Gateway versions 12.1 and 13.0 have reached end-of-life (EOL) and no longer receive security updates, and Citrix has not said whether they are affected by these vulnerabilities. Organizations still running these versions should move to a supported, fixed build.

Are there any indicators of compromise for these vulnerabilities?

Citrix has made generic indicators of compromise (IoCs) available through NetScaler Console, which requires product usage telemetry to be enabled. Customers who do not use NetScaler Console, or cannot access the feature, can contact Citrix Support to request the IoCs. Citrix notes that the IoC information may not cover all threat actor tactics, techniques and procedures (TTPs) and recommends engaging forensic investigators for a comprehensive assessment.

Mandiant and GTIG also published hunting guidance, along with IoCs and YARA rules. Because patching does not remove an attacker who already has access, organizations should check their appliances for signs of compromise. Mandiant also recommends revoking active sessions and rotating credentials used by the appliance after patching.

Has Tenable Research classified these vulnerabilities as part of Vulnerability Watch?

Yes. CVE-2026-88771, CVE-2026-88772 and CVE-2026-88779 have been classified as “Vulnerability of Interest” as part of Vulnerability Watch.

Has Tenable released any product coverage for these vulnerabilities?

A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages for CVE-2026-88771, CVE-2026-88772 and CVE-2026-88779 as they’re released. These links display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify public-facing NetScaler assets by using the following query: Server Contains Netscaler OR Document Title contains Citrix Gateway

• Citrix Security Bulletin CTX697096: NetScaler ADC and NetScaler Gateway Security Bulletin
• Citrix Community: NetScaler ADC and NetScaler Gateway Security Bulletin (CVE-2026-88771 through CVE-2026-88778)
• Reddit r/Citrix thread: “Netscaler leak?”
• watchTowr post on X: Citrix NetScaler RCE confirmation
• Kevin Beaumont on Mastodon: Zero-day confirmation
• Citrix Security Bulletin CTX697174: NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2026-88779
• Citrix Community: Understanding and Addressing CVE-2026-88779 in Citrix NetScaler ADC and Citrix NetScaler Gateway
• Mandiant and Google Threat Intelligence Group: Defending Against Active Exploitation of Citrix NetScaler ADC and Gateway Appliances
• ASD’s ACSC: Critical vulnerabilities in Citrix NetScaler ADC and Citrix NetScaler Gateway products
• watchTowr Labs: CVE-2026-88771 analysis
• watchTowr Labs: CVE-2026-88772 analysis
• Kevin Beaumont on Mastodon: PitScaler
• PitScaler: Citrix NetScaler Zero-Day Crisis tracker

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Oracle addresses 672 CVEs in its September 2026 Critical Security Patch Update with 673 patches, including 104 critical updates.

1. The September 2026 Critical Security Patch Update (CSPU) contains fixes for 672 unique CVEs in 673 security updates
2. 104 issues (15.5% of all patches) were assigned a critical severity rating
3. Oracle E-Business Suite received the highest number of patches at 159, accounting for 23.6% of all patches

On September 15, Oracle released its Critical Security Patch Update (CSPU) for September 2026. Beginning in May 2026, Oracle introduced CSPUs as a monthly release cycle that sits between the larger quarterly Critical Patch Updates (CPUs), addressing a focused set of high-severity issues on a faster cadence. This CSPU contains fixes for 672 unique CVEs in 673 security updates across 17 Oracle product families. Out of the 673 security updates published, 15.5% of patches were assigned a critical severity. High severity patches accounted for the bulk of security patches at 74.7%, followed by critical severity patches at 15.5%.

This month's update includes 104 critical patches across 104 CVEs.

This month's update saw the Oracle E-Business Suite product family contain the highest number of patches at 159, accounting for 23.6% of the total patches, followed by Oracle Fusion Middleware at 153 patches, which accounted for 22.7% of the total patches.

A full breakdown of the patches for this CSPU can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Patches are available in the September 2026 advisory for full details.

A list of Tenable plugins to identify these vulnerabilities will appear here as they're released. This link uses a search filter to ensure that all matching plugin coverage will appear as it is released.

• Oracle Critical Security Patch Update Advisory - September 2026
• Oracle September 2026 Critical Security Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Australia’s move from the Essential Eight to an outcomes-based cybersecurity model will push organizations from conducting periodic point-in-time, checklist compliance assessments to having continuous evidence of a solid security posture.

1. The Australian Signals Directorate (ASD) is moving from the Essential Eight cybersecurity framework to a new outcomes-focused Essentials series covering enterprise IT, cloud, operational technology (OT), and potentially agentic AI.
2. The Essential Eight itself only ever covered on-premises enterprise IT, built around eight named technical controls, such as application control and patching. It never extended to the security of cloud, identity, or OT.
3. The shift challenges the traditional checklist approach to cybersecurity, where organizations demonstrate compliance through periodic assessments and point-in-time reports.
4. In dynamic environments spanning IT, cloud, identity, and OT, security posture can change quickly and repeatedly between assessments.
5. Exposure management can help organizations continuously understand where they are exposed, prioritize the most critical weaknesses, and provide evidence of their current security posture.

Can you prove your security posture is solid, right now, on demand?

That’s the question the Australian Signals Directorate (ASD) has effectively put in front of every Australian organization’s board, CISO, and C-suite.

ASD’s decision to retire the Essential Eight signals a fundamental move away from point-in-time, checklist-based security toward an outcomes-focused model where organizations will need to demonstrate continuous compliance.

It’s no longer enough to show that your organization had a control in place at the time of the last assessment. In a technology environment that changes continuously across IT, cloud, identity, and operational technology (OT), organizations must be able to answer a much more immediate question:

How are we currently exposed? 

ASD announced it was replacing the Essential Eight in June 2026. The agency expects deprecation to begin around mid-2027, roughly 12 months later. This is the point at which ASD starts actively steering organizations toward the new framework, not a deadline by which compliance must switch over. 

Full retirement of the Essential Eight follows about a year after that, around mid-2028. ASD has described these timelines as targets rather than fixed dates, and both the Essential Eight and the new Essentials series will remain live throughout the transition.

Compliance isn’t universally mandatory. The Protective Security Policy Framework requires the Essential Eight for roughly 98 non-corporate Commonwealth entities. For private-sector organizations, it’s voluntary guidance, not law, though many of these organizations’ insurers, customers, and contracting government agencies expect them to comply with the framework. Whether that same government mandate will carry over to the Essentials series hasn’t yet been confirmed. 

But if you focus only on the timetable, you risk missing the bigger story: What’s different between a checklist and a continuous state of proof?

ASD is moving toward a cybersecurity model built around outcomes and intent that goes well beyond simply swapping eight controls for a new checklist. The new Essentials series is structured as chapters, beginning with one on enterprise IT, which folds in identity and access along with SaaS tools such as Microsoft 365 and Google Workspace, then expanding into cloud and OT with an agentic AI chapter flagged as likely to follow. Each of those environments now needs its own outcomes-based guidance rather than the same fixed set of controls for all of them.

That structure reflects how differently those environments behave. Organizations can now provision cloud services in minutes. Identities and privileges constantly change. SaaS applications crop up across the business. OT and IT environments are increasingly interconnected. AI is creating another fast-moving layer of technology to understand and secure.

In that environment, organizations now need to demonstrate that they’re continuously achieving their security outcomes.

It’s worth being specific about what’s changing, because the two models measure success in fundamentally different ways.

The Essential Eight scored organizations against eight named technical controls, such as application control, patching, and macro settings, at fixed maturity levels, assessed periodically. An assessor checked whether a control was implemented and rated it Maturity Level 1, 2, or 3. That assessment was a snapshot: accurate for the day it was taken.

The new Essentials series doesn’t ask the same question. According to ASD's public consultation announcement, the new model focuses on outcomes and intent rather than prescriptive, named controls. Instead of asking whether an organization implemented a specific control, it will ask whether it is achieving the security outcome that control was meant to produce, and whether it can demonstrate that on an ongoing basis, not just at audit time.

That’s a deliberate response to how much has changed since 2017, when ASD introduced the Essential Eight. As the Australian Cyber Security Centre’s Head of Cyber Security Resilience Chris Horlyck told iTnews, the original framework assumed on-premises infrastructure as the default. But cloud, SaaS, and hybrid environments have become the norm rather than the exception.

Both the Essential Eight and the Essentials series remain live throughout the transition, so there’s no single day when the switch flips, which is itself part of the point. A framework built around continuous proof doesn’t arrive with a checklist moment either.

Currently, the Essentials series is still being built. Only the first chapter, covering enterprise IT, has reached public consultation, which closed in July 2026, with final guidance expected later this year. ASD hasn’t yet set a timeline for the remaining chapters covering cloud, OT, and potentially agentic AI.

This shift to demonstrating continuous compliance should sound familiar to anyone who has watched vulnerability management evolve. 

The traditional approach relied heavily on periodic scans. Organizations would run a scan, generate a report, remediate what they could, and retain the report as evidence.

That approach made sense when infrastructure changed relatively slowly and cybersecurity frameworks were largely built around fixed controls.

However, modern attack surfaces are much more dynamic and change quickly and frequently.

Most large organizations have too many security tools.

The vulnerability management team has its own set of tools. The cloud security team has a separate tool stack. Then there are security tools for identity, OT, AI, and more.

Each tool can provide valuable information, but security teams are then left trying to understand how thousands of individual findings connect across the broader attack surface.

This is where exposure management becomes critical. Rather than treating vulnerabilities, cloud misconfigurations, identity weaknesses, and unknown assets as separate problems, exposure management unifies them into a single view of the organization’s cyber risk.

The objective is to understand which exposures create the greatest risk to the business and what security teams should fix first. Each exposure needs context, such as whether it’s actually exploitable and what asset it sits on. It also means looking for toxic combinations: a vulnerability, an excessive privilege, and a misconfiguration that each looks manageable on its own but together create a direct path to a critical system.

For Australian CISOs, the next 24 months offer an opportunity to rethink how they assess their organizations’ cybersecurity risk.

The CISOs I’ve spoken with since the announcement keep coming back to the same fear: being asked, mid-audit, to prove something is true right now, not just when the last scan ran, and not having a confident answer.

Imagine being asked, whether by a formal assessor during a compliance review or by your own board during a risk briefing:

• Where is the organization exposed today?
• Which exposures present the greatest risk to critical systems?
• Can an attacker find an attack path from this vulnerability to a high-value asset?
• Which attack paths opened in your environment this week, and what are you doing about it?
• Can you visualize your global security posture, track its changes and trends over time, and understand how it relates to your business context?

You can’t answer those questions by manually reconciling reports from multiple tools or relying on a scan performed weeks earlier.

Instead, organizations need a continuously updated understanding of their attack surface and the context required to distinguish an urgent exposure from background noise.

That is the shift from point-in-time vulnerability management toward continuous exposure management.

ASD has signaled that the Essentials series will ask Australian organizations to prove security outcomes on an ongoing basis, not just complete a periodic checklist. 

The Tenable One Exposure Management Platform is built exactly for that scenario: It unifies security visibility, insight, and action across the modern attack surface, helping organizations detect and fix the most critical cybersecurity gaps that drive up business risk.

Instead of forcing security teams to piece together separate views of IT, cloud, identity, OT, web applications, and external attack surfaces, Tenable One brings exposure data together so organizations can understand how weaknesses connect and where attackers are most likely to find a path to critical assets.

This gives security teams the ability to:

• See the attack surface more clearly by bringing together exposure data across IT infrastructure, cloud environments, identities, OT, AI systems, web applications, and internet-facing assets.
• Pinpoint the most critical threats by adding context to vulnerabilities and other exposures so teams can prioritize remediation based on the risk they pose to the organization.
• Identify attack paths by understanding how toxic combinations of vulnerabilities, misconfigurations, privileges, and assets can create pathways to critical systems.
• Track security posture continuously by moving beyond periodic snapshots toward an always up-to-date understanding of how exposure changes as the environment changes.
• Turn technical data into actionable insight by giving security leaders clearer evidence to communicate cyber risk and remediation priorities to executives, boards, and assessors.

That’s the shift Tenable One is built for: helping security teams move past proving they ran an exercise and toward demonstrating they understand and are actively managing their exposure.

The Essential Eight played an important role in improving Australia’s cybersecurity maturity. Its principles still matter. What’s changing is the environment they now have to protect.

A static checklist can no longer adequately represent security when the attack surface itself is continuously changing.

So, there is a simple question boards and executives can ask their security teams: Can we show where we’re exposed today, what matters most, and what we’re doing about it?

If answering that question requires assembling last month’s scans, spreadsheets, and reports from half a dozen security tools, the organization has already identified the problem.

The next era of Australian cybersecurity comes down to being able to answer one core question: Where are you exposed right now?

Learn more about the Tenable One Exposure Management Platform

Learn why Tenable treats agentic LLMs as untrusted insiders, and how we’ve made sure you can control and monitor the AI agents making changes in your production security environment

1. AI models can quickly understand data, but not your business. While modern AI models are great at reasoning, they don’t automatically understand your unique environment or who is allowed to do what. The “harness” is the custom-built layer that translates AI intelligence into safe, controlled actions specific to your organization.
2. AI requires a supervisor. Tenable treats our AI agents like untrusted insiders. Instead of relying on the AI to police itself, the harness strictly limits what the AI can see and do, and ensures a human reviews and approves any changes before they happen in your environment.
3. Trust requires proof. The harness ensures that every action AI proposes or takes is fully recorded, giving you an audit trail to confidently hand off real work to AI without losing control.

Every security vendor has an AI agent. The demos are good. They are supposed to be good, because a demo runs against data that nobody minds breaking.

The questions worth asking a vendor about their AI agents are the ones that come after the demo: 

• What happens when the agent is wrong? 
• What happens when someone feeds the agent a prompt designed to manipulate it? 
• If the agent changes something in our environment, what evidence exists afterward about what it did and who authorized its action?

When developing Tenable Hexa AI, the agentic AI engine of the Tenable One Exposure Management Platform, we tackled a difficult and critical problem that often gets overlooked: building the underlying infrastructure, the governance layer that safely turns the AI's decisions into actual changes without putting your production data at risk.

We call this layer the harness: the runtime control environment in which the model operates. The harness decides: 

• What context the model can see
• Which tools it can call
• What has to be validated before an action executes
• When a human has to approve an action
• What gets recorded afterward

The model reasons. The harness holds the boundary.

The model is the part you can subscribe to. The harness is the part that has to be built, and it represents most of the work of building an agentic AI capability. 

This blog presents what we learned building an agentic harness for Tenable Hexa AI.

Abstract warnings about AI risk are easy to write and easy to ignore. Here is what actually went wrong during our own development phase. The failures were more mundane, and more instructive, than the ones people theorize about.

1. The AI agent acted past its authority. Asking an agent to “clean up my criticals” is too ambiguous. Critical severity findings and critically rated assets are different objects, and “clean up” could mean remediate, accept the risk, or delete outright. A capable model will pick one and plan bulk changes across assets the requester cannot see, let alone modify. The model has no concept of who is asking. It does not know your entitlement model, and it will not infer one.
2. The model was confidently wrong about the customer’s own environment. The model told users that tags did not exist when, in fact, they did. It missed asset searches by IP address. It used the wrong tag format, using underscore where the platform expects a colon, and then it reported the failure as an absence of data. A model that has read the entire internet still has not read your tenant, and it will fill that knowledge gap with plausible invention unless you stop it.
3. It fell over on the boring queries. Relative time ranges crashed sessions. A query spanning more than 5,000 assets exhausted the context window and failed outright rather than degrading. An unbounded filter like “all assets where source contains servicenow” would run until something gave out.
4. It failed abstraction. Decomposed requests worked. A request like “give me a weekly security posture summary” failed because the model would not reliably break a broad objective into the sequence of scoped queries that answers it. The response was an ambiguous refusal, which is worse than a wrong answer because the user cannot tell whether the product is incapable or they phrased the request poorly.
5. The model refused work it was capable of. Before routing and scope logic existed, the model declined tasks it could clearly perform. Over-refusal is a real failure mode, and it is easy to cause while trying to fix the others.
6. Over-tuning the fix created a new failure. This was the least obvious lesson, and it came from our own work rather than the model’s. Early safety filtering was calibrated conservatively, and conservative filtering produces false positives. A false positive could also carry forward into the rest of a session rather than staying scoped to the request that caused it. Governance tuned too tightly fails as surely as governance that is absent, and it fails in the more confusing direction because a user experiences an over-cautious limit as a malfunction rather than as a control. Calibration is continuous work, not a setting you choose once.

There is a category above all of these, and it is specific to security. Much of the data in a security platform — such as hostnames, certificate fields, service banners, and finding descriptions — is written, in part, by people you do not trust. 

An attacker who can compromise a hostname can put a sentence in it, and a model reading that field as context can read the sentence as an instruction. Text arriving from your own environment is not a neutral input. In our world, security data is an attack surface, and it is one that does not exist in most other places agents get deployed.

We settled on a set of core design principles that security teams already run for humans and service accounts: Assume no standing trust. Grant least privilege. Verify every consequential action. Record everything.

Applied to an autonomous AI agent, that means the controls sit outside the model, not inside it. A model instructed to behave is not a control, because instructions are input and input can be overridden or manipulated. So the harness holds the boundary. It decides what context the agent receives, which tools it may call, whether a proposed action is valid, when a human signs off, and what gets recorded when the action executes.

The useful property of the “no standing trust” design stance is that it does not depend on model quality, which means it survives model upgrades. Whatever ships next year will still be an actor whose intent cannot be verified at the moment it acts.

The clearest way to explain a harness is to follow a single request through it. Let’s take the example of an actively exploited Chrome vulnerability, a fleet of Macs still running the vulnerable Chrome version, and a security professional who types “patch it” into an agentic LLM’s prompt.

Grounding before anything else. The agent is instructed not to state a platform fact from memory. Every assertion about your environment has to come from a tool response, and if the tool did not return it, the agent does not claim it. On its own, an instruction is a weak control for the reason described above, so it is paired with tool-grounded response construction rather than relied on by itself. Together, they remove most of the confident-invention problem.

Routing and decomposition. Not every step needs the same model. Cheap classification and lookup can go to a fast model, while multi-step planning can go to a reasoning model, and the objective is decomposed into scoped sub-agents that each own a narrow job: 

• Enumerate affected assets.
• Resolve them to managed devices.
• Map the CVE to the version that fixes it.
• Find the patch definition that delivers that version.

Decomposition is what makes the abstract request work, and it is orchestration logic, not model behavior.

Recursion and step budgets. Sub-agents that spawn work need boundaries. Otherwise, a reasoning loop will consume time and money until something external stops it. We cap maximum tokens, enforce layered recursion limits, and run a step budget that degrades to a partial answer rather than failing. Returning less is a better outcome than returning nothing after a long wait.

Authorization at the tool boundary, not the prompt. Every tool call passes through permission middleware that denies unauthorized access before execution. The AI agent acts with the entitlements of the person who invoked it and does not escalate beyond them, which means the answer to “what can the agent do?” is exactly “what can this user do?” 

Scale then changes the treatment. A single-asset change and an operation spanning thousands of assets do not create the same risk, so the wider the blast radius, the higher the bar: Larger operations require their full scope to be enumerated and explicitly approved. Some are unavailable unless an administrator has enabled them for that tenant, so the capability has to be granted rather than simply not blocked.

Guardrails on both directions of every call. Content checks run twice on every call, once before the model sees its input and once after it produces output. Screening only the user's prompt on the way in would miss most of what matters, because the risky content usually arrives from the environment rather than from the person typing. 

There is a case that sounds absurd until you hit it: A legitimate summary of a finding can itself contain the language that trips the injection filter, so the agent has to rephrase its own output to avoid being blocked by its own controls. Uploads are validated, and macro-enabled spreadsheets are rejected.

The approval gate. Before any state change, the agent stops and produces a written proposal with the number and IDs of impacted devices, the specific change policy, the deployment window, and the potential blast radius, as well as a statement that the action will not roll itself back. The user can narrow or widen the scope of changes, or decline all changes altogether. A refusal to apply all changes is sticky rather than something the agent relitigates on the next turn. Only after approval does it create a group containing exactly the approved devices; trigger the policy; and schedule the confirming rescan.

The approval gate is the capability Tenable customers have praised the most. Early access customers told us they were hesitant to try Tenable Hexa AI because they did not want to put their production data at risk. The approval gate is the feature that gave customers confidence they could trust the product.

Provenance and audit throughout. Every call emits token and decision events to our streaming and monitoring pipeline. Every run is traced. Everything correlates by request identifier. Conversation history is durable, and actions taken by the agent are stamped with their source so they are distinguishable from human actions in the record. For example, if six weeks later someone asks who approved a change and why, that question has an answer.

Here is the problem that consumes more engineering attention than any single control: models change constantly. Every prompt revision, tool change, or model swap can quietly regress quality or safety, and you cannot detect that by using the product. It feels fine right up until a customer finds the edge case you broke.

To address the challenge that evolving AI models create, Tenable runs two independent evaluation suites — one functional and one for safety — against every change. More than a hundred curated cases in Tenable Hexa AI score across roughly a dozen evaluators – single, automated checks – using distinct measurement methods, from deterministic rule checks to model-as-judge scoring to pairwise comparison.

Every case is a multi-turn conversation driven by a simulated user against the real agent in an isolated, reproducible environment, so results are comparable across runs, and drift shows up as a measurable drop against a pinned baseline rather than as an anecdote. One rule is absolute: Any run that makes an unexpected destructive call fails, regardless of how well it scored elsewhere. Results run in continuous integration, get triaged automatically, and get posted to the team channel.

Two things make the suite stronger over time. Real conversations that users rate poorly get promoted into the suite as new cases, so coverage hardens with each release. And because the suite is model-independent, we can evaluate a new frontier AI model against a fixed bar and adopt it on evidence rather than faith.

A harness may sound like a tax on capability. In practice, it is the thing that makes delegation possible at all.

Without a harness, an autonomous AI agent is a read-only tool. You can ask it questions and verify its work, which is useful and roughly the value of a good dashboard. The moment you want it to change something, the conversation becomes entirely about risk, and most organizations correctly stop there.

With an agentic harness, three things become available:

1. You can hand over consequential work, not just triage and summary but scoping, execution, and verification, because there is a defined point where a human approves actions and a boundary is enforced outside the model rather than requested of it.
2. You get evidence instead of assurances:  a record of what was proposed, what was approved, by whom, and what resulted is something you can give an auditor, a regulator, or a board. Trust in an agentic system is a documentation problem as much as an engineering one.
3. You can widen autonomy at your own pace. Scope is set per task rather than globally, so there is no all-or-nothing decision about the whole platform. You can start with something reversible, watch it run, then expand when you are ready.

Here’s an additional benefit of an agentic harness that is easy to miss: Because the harness holds the boundary outside the model, and the evaluation suite is independent of it, better models become an upgrade rather than a renegotiation. Tenable Hexa AI can adopt them without asking customers to re-extend trust from scratch.

If you are evaluating agentic capabilities from any vendor, including Tenable, ask the following questions: 

• What stops an action the requester was not entitled to take? 
• What happens to instructions hidden in attacker-influenced data? 
• What does the agent do when a query is too large or the objective too vague? 
• What evidence exists after agents perform an action?
• How do you know quality did not regress the last time security vendors changed models? For example, does the agent still refuse what it should, ground its answers in real data, and stop for approval before making any changes? (Hint: If the answer is not a score against a pinned baseline, it is a hope.)

Access to a frontier AI model is not what makes agentic security work. Everything around the model does. That is the harness, and it is the difference between an agent you can watch and an agent you can hand work to. Everything above is what we built to make Tenable Hexa AI the second kind.

• 30 days with Claude Mythos Preview: How Tenable adapted our security program, and why yours is next
• Tenable Hexa AI
• Meet Tenable Hexa AI: Agentic AI for exposure management
• Implement agentic AI in cybersecurity with Tenable Hexa AI: Reduce cyber risk at machine speed

Open-source registries for AI agents are only effective when they include a rigorous, transparent security review process for community submissions. That’s why for its new CyberAgents Exchange registry, Tenable paired its exposure management expertise with OpenAI GPT Cyber models to create the CyberAgents Exchange AI Inspector.

1. The Exchange Inspector combines Tenable’s exposure detection with OpenAI’s GPT Cyber models and with human oversight to rigorously vet submissions made to the CyberAgents Exchange.
2. Securing AI agents requires analyzing a broad attack surface that includes LLM instructions, tool-chaining permissions, and prompt injection risks, going far beyond traditional software security.
3. The CyberAgents Exchange inspection process dynamically matches the appropriate AI model tier to each submission’s risk level, ensuring comprehensive vetting without excessive computational overhead.

Recently at OpenAI's “Intelligence at Work: Cyber Summit,” Tenable and OpenAI announced a groundbreaking review process to vet the security of open-source AI agents, skills, MCP servers, and multi-agent playbooks, building on our June partnership. The new CyberAgents Exchange AI Inspector, which is built into our CyberAgents Exchange registry, will help security teams adopt agentic AI quickly and confidently.

Powered by Tenable, the CyberAgents Exchange is a purpose-built, cybersecurity-native registry for AI agents, skills, MCP servers, and multi-agent playbooks. Launched in August as an open source and vendor-agnostic registry, the CyberAgents Exchange has already grown to host more than 100 AI listings, including a wave of contributions created at Tenable’s SWARM build event at Black Hat USA.

From the CyberAgents Exchange’s inception, we understood the importance of a rigorous, comprehensive review process for agents submitted by contributors. Every submission to the CyberAgents Exchange gets a baseline review prior to being listed. 

Now, we are further strengthening the CyberAgents Exchange review capabilities by giving select high-risk submissions deeper scrutiny with the CyberAgents Exchange AI Inspector, which pairs OpenAI GPT Cyber models with Tenable's own security expertise. The CyberAgents Exchange AI Inspector, or Exchange Inspector for short, is expected to be available in September.

Read on for a detailed overview of how we designed the Exchange Inspector and how it works.

CyberAgents Exchange submissions come in many shapes and sizes. A submission may contain a single skill markdown file with instructions for an LLM. A more complex submission may contain full agents, MCP servers, external libraries, and may interact with remote services and APIs. This range of complexity is part of what makes reviewing AI agent submissions different from reviewing conventional software.

In traditional software security, the attack surface is largely the code itself. In an AI agent, the attack surface extends to the instructions given to the model, the tools it is authorized to invoke, and the data it is permitted to access or transmit. Prompt injection is also a concern, and tool chaining can amplify risk across trust boundaries that no single component would cross on its own. We account for this in our approach to each review.

Each submission points to a code repository containing source code files and commits (saved snapshots) that form the project's full history. Since a Git repository is a living codebase, Exchange Inspector reviews are anchored to a specific commit, ensuring findings are traceable back to a known state. Vetting is not automatically carried forward, and any material change to the submission requires a new review. Alongside scope integrity, the contributing guidelines are met.

Trustworthiness of the repository owner, any backing organization, and author(s) is assessed. We collect a range of signals and produce a confidence rating that informs whether we should proceed with the review.

We combine Tenable One AI Exposure scanning, frontier model assessment with OpenAI GPT Cyber models, and human review to examine the full surface area of each submission. Following source review, the CyberAgents Exchange installs and exercises submissions in a clean, isolated environment using only documented setup steps. It then compares observed behavior against what the documentation claims, and notes any discrepancies as findings.

Findings that represent hard security failures must be resolved before promotion. Others can be accepted with a documented rationale and a follow-up commitment. Throughout the review, we work directly with submitters. Our goal is to promote strong submissions, not to operate an opaque rejection gate.

Tenable One AI Exposure helps organizations secure and govern their use of AI. It provides comprehensive visibility into how employees interact with AI tools like ChatGPT Enterprise and Microsoft Copilot. Tenable One AI Exposure monitors the flow of sensitive data to prevent data leakage, identifies misconfigurations, and detects AI-specific threats such as prompt injection and jailbreak attempts in real time.

Before a submission reaches OpenAI's frontier model assessment, it passes through Tenable One AI Exposure’s screening. This automated first pass scans for PII exposure, sensitive data access, and prompt injection or jailbreak risks, surfacing the most critical issues before a human ever looks at the submission. Anything flagged gets resolved before moving forward in the review pipeline.

Here is a sample SKILL.md with invisible characters that Exchange Inspector detected. Notice how line 17 is wrapped onto three lines, with no visible text.
 

While the skill file may appear harmless to a user, the line contains the following text encoded as invisible Unicode tag characters that are also passed to the LLM:

OpenAI Daybreak gives approved defenders access to capabilities calibrated for authorized cyber defense. Because Daybreak Blue and Daybreak Red are designed for different workflows, our model-selection process routes each submission based on authorization, risk, and technical complexity. We start with the model and access level suited to the task, then escalate when the content requires more specialized cyber capability or a more permissive safeguard posture.

A refusal or safe completion from a standard model should not be treated as a clean bill of health. It may indicate that the submission contains cyber content constrained by the model’s safeguards. We therefore benchmark representative submissions across model/access configurations before escalating to Daybreak Red for authorized, higher-risk, or technically demanding workflows.

Here, we perform a structured comparison: Does the submission’s metadata match the linked repository? Is the declared license present in the file tree? Is the README complete? Do the install instructions work? Trustworthiness assessment runs alongside this. We collect signals on the repository owner, any backing organization, and the contributing author(s), including public reputation, prior open-source activity, and any indicators of sockpuppet or throwaway accounts.

A standard GA model, such as Luna, handles this entire section. The listing integrity pass confirms frontmatter matches the linked repo, the license file is present and accurately declared, the README covers all required fields, and the README is binary and low-ambiguity. Trustworthiness assessment does not require escalating to a more capable model either: It runs through a dedicated skill that collects signals and produces a structured score.

Prose-only submissions are SKILL.md files, playbooks, and prompt templates containing no executable code. These are a common type of submission on the CyberAgents Exchange. Their attack surface is entirely in the instructions themselves. The risks are prompt injection via embedded directives, exfiltration of instructions hidden in otherwise reasonable text, scope creep in what the skill authorizes an agent to do, and obfuscation techniques such as zero-width characters, Unicode homoglyphs, HTML comments, or base64 blobs embedded in markdown.

No Daybreak access is required for this class. A standard model handles it well, with one essential constraint: The submission must be passed as delimited data, not as instructions, so the reviewer model does not execute embedded directives as its own. A second dedicated pass for hidden content is standard practice: Check for unicode anomalies and encoded blobs first, then give the model the full text with an explicit prompt to surface anything that would be invisible in a rendered view.

This class covers submissions such as MCP servers and agents that wrap documented, read-only APIs: fetching from a SIEM, querying Tenable read paths, creating tickets, and running searches. The risk surface here is supply chain (unpinned dependencies, install hooks, git references without a pinned SHA), secret handling, over-broad tool permissions, and undisclosed egress.

OpenAI’s Daybreak Blue is the starting point for this class. Even a read-mostly MCP server typically contains auth flows, credential storage, and scan-configuration access, components that a standard model may hedge on rather than explain plainly. That hedging makes the review output unreliable, as a qualified answer about how a token is stored is not the same as a clear finding, and an evasive summary of an auth flow is not a clean pass. Daybreak Blue’s defensive safeguards remove that friction for the bulk of the work, such as dependency auditing, SAST-style code reading, permission scoping, and egress mapping, all of which get direct answers.

This is the class where model selection matters most. It covers anything that scans or enumerates systems, brute-forces, parses or stores credentials, decodes malware, manipulates scan configurations, or drives a security tool with write or attack capability. A prose-only skill that instructs an agent to perform any of these inherits this class, as the risk travels through the instruction, not just the code.

Daybreak Blue is the starting point for many authorized defensive reviews in this class, especially secure code review, vulnerability triage, malware analysis, detection engineering, and patch validation. The practical difference from a standard model is direct: You need the model to state plainly that a function performs Server Message Block (SMB) null-session enumeration and that the error handling would let it hammer a host without backoff, or that a credential handler writes tokens to an unprotected temp path. A standard model may hedge or refuse that characterization even in an explicitly defensive context, which is precisely where it is less reliable for complete review of dual-use components. Daybreak Blue’s safeguards are tuned for defensive analysis of code that straddles the line between legitimate and malicious use.

If Daybreak Blue refuses on a specific component, we treat that refusal as a review signal requiring escalation or reclassification. It signals either that the component was misclassified and belongs in the next class up, or that the submission is obfuscating intent in a way that tripped the model’s filters. In either case, we escalate to Daybreak Red, log the refusal verbatim in the review record, and reclassify before proceeding.

PoC exploits, C2 clients, payload generators, evasion and AV-bypass tooling, credential dumpers, and agents whose stated purpose is exploitation are the only class that requires Daybreak Red by default, and a policy gate before any technical review begins.

The policy decision is whether the CyberAgents Exchange accepts this submission at all. Most items in this class should fail there. The CyberAgents Exchange is built on transparency and open contribution, and we work directly with submitters to promote strong work. Still, weaponized artifacts sit outside of what the registry is designed to host.

When a submission passes the policy gate, such as a legitimate penetration-testing framework with proper authorization, scoping, and controls, Daybreak Red may be appropriate for the technical review. OpenAI describes Daybreak Red as providing purpose-trained cybersecurity models for authorized vulnerability research, exploit validation, and security testing. This matters when the review requires validating exploitability in a controlled environment or distinguishing a genuine proof-of-concept from a malicious artifact disguised as one. A refusal, safe completion, or limited analysis from Daybreak Blue on this kind of higher-risk artifact should not be treated as a clean bill of health; it should trigger reassessment of classification, authorization, and whether Daybreak Red is the appropriate review tier.

The Exchange Inspector adds a rigorous layer of security vetting, giving security teams a clearer signal on which AI agents, skills, MCP servers, and multi-agent playbooks are safe to bring into their environment. By pairing OpenAI's frontier model assessment with Tenable's security expertise, this collaboration is designed to give security teams the confidence to adopt agentic AI at the pace their organizations require, without sacrificing control or visibility. Expect the Exchange Inspector to roll out in September, and the Exchange itself to keep growing as community contributions increase.

Explore the CyberAgents Exchange today, and stay tuned for the release of Exchange Inspector. 

Stay in the loop

Follow the CyberAgents Exchange for builder spotlights, launch updates, and community news. Subscribe on YouTube at CyberAgents Exchange and follow us on X at CyberAgents Exchange (@CyberAgentEx).

1. 104Critical
2. 860Important
3. 0Moderate
4. 0Low

Microsoft addresses 964 CVEs, smashing July’s release as the largest Patch Tuesday release. This month’s updates include patches for two zero-days that were exploited in the wild.

Microsoft patched a record 964 CVEs in its September 2026 Patch Tuesday release, with 104 rated critical and 860 rated as important.

This month’s update includes patches for:

• .NET
• .NET and Visual Studio
• ASP.NET Core
• Active Directory Certificate Services (AD CS)
• Active Directory Domain Services
• Active Directory Federation Services (AD FS)
• Audio Video Control Transport Protocol
• Azure Arc
• Azure CycleCloud
• Azure HDInsights
• BranchCache
• Connected Devices Platform Service (Cdpsvc)
• Data Sharing Service Client
• GitHub Copilot and Visual Studio Code
• Graphic Fonts
• HID class driver
• IP Helper
• Internet Storage Name Service
• Kernel Streaming WOW Thunk Service Driver
• Microsoft Account
• Microsoft Authenticator
• Microsoft Azure Attestation service and Device Health Attestation Service
• Microsoft Azure CLI
• Microsoft COM for Windows
• Microsoft Dynamics 365
• Microsoft Exchange Server
• Microsoft Graphics Component
• Microsoft Install Service
• Microsoft JScript
• Microsoft Local Security Authority Server (lsasrv)
• Microsoft Office
• Microsoft Office Access
• Microsoft Office Excel
• Microsoft Office Outlook
• Microsoft Office PowerPoint
• Microsoft Office Publisher
• Microsoft Office SharePoint
• Microsoft Office Word
• Microsoft Standard XPS
• Microsoft Teams for Android
• Microsoft Trace Data Helper
• Microsoft UxTheme Library (uxtheme.dll)
• Microsoft WDAC OLE DB provider for SQL
• Microsoft WebP Image Extension
• Microsoft Windows Codecs Library
• Microsoft Windows Media Foundation
• Microsoft Windows PDF
• Microsoft Windows SCSI Class System File
• Microsoft Windows Search Component
• Microsoft Windows Speech
• OpenSSH for Windows
• Power Automate
• Push Message Routing Service
• RPC Runtime
• Reliable Multicast Transport Driver (RMCAST)
• Remote Desktop Client
• Remote Desktop Gateway Service
• Role: DNS Server
• Role: Windows Fax Service
• SQL Server
• Skype for Business
• Spring Cloud Azure
• Storage Port Driver
• Telnet Client
• Virtual Hard Disk (VHD) Miniport Driver
• Visual Studio
• Visual Studio Code
• Volume Manager Driver
• Windows AF_UNIX Socket Provider
• Windows ALPC
• Windows Accounts Control
• Windows Ancillary Function Driver for WinSock
• Windows Audio Service
• Windows Authentication Methods
• Windows Autopilot
• Windows Bind Filter Driver
• Windows Biometric Service
• Windows BitLocker
• Windows Bluetooth Port Driver
• Windows Bluetooth Service
• Windows Boot Manager
• Windows Broadcast DVR User Service
• Windows Broker Infrastructure Service
• Windows CD-ROM Driver
• Windows Camera Frame Server Monitor
• Windows Cloud Files Mini Filter Driver
• Windows Compressed Folder
• Windows Connected User Experiences and Telemetry
• Windows Container Manager Service
• Windows Core Messaging
• Windows Credential Guard
• Windows Credential Providers
• Windows DCOM Server
• Windows DHCP Client
• Windows DHCP Server
• Windows DNS
• Windows DWM Core Library
• Windows Defender Firewall Service
• Windows Deployment Services
• Windows Device Association Broker service
• Windows Device Association Service
• Windows Devices Human Interface
• Windows Direct Show
• Windows Display Enhancement Service
• Windows Distributed File System (DFS)
• Windows Embedded Mode Service
• Windows Encrypting File System (EFS)
• Windows Enterprise App Management
• Windows Error Reporting
• Windows Event Logging Service
• Windows Failover Cluster
• Windows Fast FAT Driver
• Windows File History Service
• Windows GDI
• Windows GDI+
• Windows Graphics Kernel
• Windows Group Policy
• Windows HTTP Print Provider
• Windows HTTP.sys
• Windows Hello
• Windows Host Guardian Service
• Windows Hyper-V
• Windows IKE Extension
• Windows IP Address Management (IPAM) Service
• Windows Image Acquisition
• Windows Imaging Component
• Windows Installer
• Windows Internet Connection Sharing (ICS)
• Windows Kerberos
• Windows Kernel
• Windows Kernel Mode Driver
• Windows Key Distribution Center
• Windows LDAP - Lightweight Directory Access Protocol
• Windows License Manager
• Windows Link Layer Topology Discovery Protocol
• Windows MIDI Service Module
• Windows Management Instrumentation
• Windows Management Services
• Windows Media
• Windows Media Player
• Windows Message Queuing
• Windows Message Queuing Queue Manager
• Windows Microsoft DirectMusic
• Windows Mobile Broadband
• Windows Modern Device Management (MDM)
• Windows Modern Execution Server
• Windows NDIS
• Windows NFS Portmapper
• Windows NTFS
• Windows Netlogon
• Windows Network Connection Broker
• Windows Network File System
• Windows Notification
• Windows OLE DB
• Windows Online Certificate Status Protocol (OCSP)
• Windows Overlay Filter
• Windows Paint
• Windows Partition Management Driver
• Windows Performance Monitor
• Windows Power Dependency Coordinator
• Windows PowerShell
• Windows Print Spooler Components
• Windows PrintWorkflowUserSvc
• Windows Program Compatibility Assistant Service
• Windows Push Notifications
• Windows RDP Client
• Windows RNDIS
• Windows Raw Image Extension
• Windows Registry
• Windows Remote Access Connection Manager
• Windows Remote Desktop
• Windows Remote Desktop Licensing Service
• Windows Remote Desktop Protocol
• Windows Remote Desktop Services
• Windows Resilient File System (ReFS)
• Windows Resilient File System (ReFS) Deduplication Service
• Windows Routing and Remote Access Service (RRAS)
• Windows SMB Client
• Windows SMB Server
• Windows SMB Server Network Transport Driver (srvnet.sys)
• Windows Schannel
• Windows Secure Boot
• Windows Secure Kernel Mode
• Windows Secure Socket Tunneling Protocol (SSTP)
• Windows Security Center
• Windows Security Health Service
• Windows Server
• Windows Services for NFS ONCRPC XDR Driver
• Windows Setup Files Cleanup
• Windows Shell
• Windows Smart Card
• Windows Spaceport.sys
• Windows Storage
• Windows Storage Management Provider
• Windows Storage Port Driver
• Windows Storage Spaces Controller
• Windows TCP/IP
• Windows Task Scheduler
• Windows Text Shaping
• Windows URL Moniker
• Windows USB Audio Class driver (usbaudio.sys)
• Windows USB Driver
• Windows USB Hub Driver
• Windows USB Mass Storage Class Driver
• Windows USB Video Driver
• Windows Universal Disk Format File System Driver (UDFS)
• Windows Universal Plug and Play (UPnP) Device Host
• Windows Update Stack
• Windows VHD miniport driver
• Windows VOLSNAP.SYS
• Windows Virtual Trusted Platform Module
• Windows Volume Manager Extension Driver
• Windows Volume Shadow Copy
• Windows Web Platform Storage
• Windows WebClient Service
• Windows Win32 Kernel Subsystem
• Windows Win32K
• Windows Wireless Networking
• Windows Wireless Wide Area Network Service
• Windows Work Folder Service
• Windows Work Folders
• Windows exFAT File System
• Windows iSCSI
• Windows iSCSI Target Service
• Winsock
• XBox Gaming Services
• Xbox

Elevation of privilege (EoP) vulnerabilities accounted for 44.7% of the vulnerabilities patched this month, followed by remote code execution (RCE) vulnerabilities at 26.8%.

CVE-2026-81963 is an EoP vulnerability affecting Windows Update Stack elevation of privilege vulnerability. It received a CVSSv3 score of 7.8 and was rated as important. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

Windows Update Stack contains a link following vulnerability. An attacker could exploit this vulnerability to elevate to SYSTEM privileges.

Since 2022, seven Windows Update Stack EoP vulnerabilities have been patched across Patch Tuesday releases, but CVE-2026-81963 is the first to have been exploited in the wild as a zero-day.

CVE-2026-85880 is a EoP vulnerability affecting Windows Advanced Local Procedure Call (ALPC). It received a CVSSv3 score of 7.8 and is rated as important. According to Microsoft, this vulnerability was exploited in the wild, making it one of two zero-days addressed in the September Patch Tuesday release. Successful exploitation would allow an attacker to gain SYSTEM level privileges.

There have been 16 vulnerabilities patched in ALPC since 2022, but this is the first to be included in Patch Tuesday in more than three years (April 2023) and the second to be exploited as a zero-day since CVE-2023-21674 as part of the January 2023 Patch Tuesday.

CVE-2026-69380 is an EoP in Microsoft Exchange Server. It received a CVSSv3 score of 8.1 and is rated as important. This is a missing authorization vulnerability. An authenticated attacker with access to a mailbox through a low-user privilege user account could exploit this vulnerability to gain access to other mailboxes. Successful exploitation would allow the attacker to send and receive emails as other Exchange users as well as access attachments. Despite the high CVSS score, this vulnerability is rated as “Exploitation Less Likely” according to the Microsoft Exploitability Index.

CVE-2026-69525 is an RCE vulnerability affecting Remote Desktop Services. It received a CVSSv3 score of 9.8 and is rated as important. Successful exploitation of this flaw would allow an attacker to execute arbitrary code by exploiting a use-after-free flaw. Microsoft assesses this vulnerability as “Exploitation More Likely.”

In addition to CVE-2026-69525, three RCEs in Remote Desktop Services were also patched this month. While each were rated as important, they differed in their CVSS scoring and exploitability rating as noted in the table below:

CVE-2026-69730 is an RCE vulnerability affecting Windows DNS Server. It received a CVSSv3 score of 9.8 and is rated Critical. According to the advisory, an unauthenticated, remote attacker could send a crafted packet to exploit a use-after-free flaw in Windows DNS in order to achieve remote code execution. Microsoft assesses this flaw as “Exploitation More Likely.”

Eight additional RCEs in Windows DNS Server were patched this month, however they did not achieve the same exploitability assessment as CVE-2026-69730. These eight are outlined in the table below:

CVE-2026-69676 is an RCE vulnerability affecting Windows Kerberos. It received a CVSSv3 score of 8.8 and is rated critical. An attacker with low-level access could exploit this authentication bypass flaw using capture-replay against Windows Kerberos in order to execute arbitrary code. Microsoft assesses this flaw as “Exploitation More Likely.”

A list of all the plugins released for Microsoft’s September 2026 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

For more specific guidance on best practices for vulnerability assessments, please refer to our blog post on How to Perform Efficient Vulnerability Assessments with Tenable.

• Microsoft's September 2026 Security Updates
• Tenable plugins for Microsoft September 2026 Patch Tuesday Security Updates

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Tenable is bringing Anthropic’s Claude Mythos 5 into our enterprise security offerings. Adding frontier adversarial reasoning to the Tenable One Exposure Management Platform will help customers better anticipate how attackers could breach their environments and stay ahead of AI-fueled risk. Tenable One Adversary View, the first innovation planned from this work, will debut in the coming weeks.

1. Claude Mythos 5 is coming to Tenable One. In addition to using Claude Mythos 5 for research and evaluation, Tenable will now incorporate it within Tenable One, giving defenders access to frontier cyber reasoning to tackle complex exposure management challenges. 
2. Tenable One Adversary View is the first innovation we’ll deliver to our customers. Adversary View will use Claude Mythos 5 to help security teams uncover hidden vulnerability chains, see their environments from an attacker’s perspective, and identify the actions that can disrupt attacker progression.
3. Adversary View is just the beginning. Combining Claude Mythos 5’s advanced cyber reasoning with the breadth and depth of Tenable One sets up a new generation of AI-powered capabilities across exposure management.

Security teams face more findings than they can possibly triage using conventional methods. Add cloud, operational technology (OT), shadow AI, and identity data to the attack surface, and the volume of signals keeps growing while the time to act keeps shrinking.

Finding exposures is no longer the hardest part. The challenge is understanding which combinations of exposures create the greatest risk, how an attacker could exploit them, and what to fix first.

While leveraging frontier models for improving security defenses is still relatively new, bringing those models into customer-facing products is at the leading edge. Today, we are sharing how Tenable is combining Claude Mythos 5 with the exposure intelligence in Tenable One. Mythos 5 provides frontier-scale adversarial reasoning, while Tenable’s agentic harness provides the context and controls to turn that reasoning into secure, controlled action.

This expands on our work with Anthropic through Project Glasswing, which has focused on using Claude Mythos Preview for internal defensive research and evaluation. Claude Mythos 5 is now moving into the Tenable One Exposure Management Platform. The first innovation we’re planning to deliver to our customers will be Tenable One Adversary View, with additional capabilities planned.

A netstat entry. A cached account. A line buried in plugin output that no product has ever read. Individually, each may look unremarkable, and none of them are findings. No rule was written for them. No severity was assigned. Nothing flagged them, because nothing was looking.

Claude Mythos 5 reasons across exactly that kind of evidence: the scattered, low-signal detail that no single rule was ever written to catch. Rather than checking findings one at a time, it considers the broader environment as a whole.

Attackers don’t work from a findings list. They read the environment and reason about what's possible. Adversary View does the same thing. It reads the raw detail Tenable scanners already collect but that no rules engine could ever consume — active connections, service enumeration, installed software, configuration output — and reasons its way to the vulnerability chains that are actually viable in your environment. Not the patterns we anticipated and encoded, but the ones nobody thought to look for.

Adversary View applies Claude Mythos 5 reasoning to your Tenable scan data to surface the defensive actions that disrupt those vulnerability chains fastest. We’ll share more on availability in the coming weeks.

You won’t need to work directly with Claude Mythos 5 to get a result. It starts with a conversation in Tenable One. 

Step 1: Confirm your scope. You identify the assets you want examined, and Adversary View walks you through confirming that scope so the results are worth acting on. 

Step 2: The harness delivers and validates the context. The Tenable harness pulls together the evidence, plugin output, critical and high severity vulnerabilities, recently discovered findings, live connections between hosts, and lower-confidence signals that never rose to a finding on their own, and validates them before Claude Mythos 5 reasons across them. This is all data that Tenable already collects. Nothing new to deploy.

Set 3: Act on a ranked list of actions. What comes back isn't more findings. It's a ranked set of the vulnerability chains that actually matter, each with the evidence behind it and the fix that breaks it. You can act on those recommendations in Tenable Hexa AI. 

Bringing Claude Mythos 5 into Tenable One is more than providing access to another model. It combines frontier-scale adversarial reasoning with the exposure intelligence Tenable has built over decades.

The result is your ability to find connections that were previously difficult to see, understand which vulnerability chains matter most, and take action faster.

Tenable One Adversary View is the first capability built from this work. More will follow.

Forward-Looking Statements

This blog post contains forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995, including, without limitation, statements regarding: Tenable’s work with Anthropic; the anticipated capabilities, performance, and commercial availability of Claude Mythos 5 within the Tenable One Exposure Management Platform; the planned launch and timing of Tenable One Adversary View; the integration of frontier AI models with the Tenable Exposure Data Fabric; and Tenable’s overall AI product strategy and roadmap. These statements involve risks and uncertainties that could cause actual results to differ materially, including, among others: risks related to the development, deployment, accuracy, and customer adoption of emerging and unproven artificial intelligence technologies; technical and operational challenges in integrating third-party AI models into commercial software; the risk of delays in product development or commercial rollout schedules; intense competition in the cybersecurity market; and other factors detailed under the caption 'Risk Factors' in Tenable's most recent Annual Report on Form 10-K and subsequent filings with the Securities and Exchange Commission. Tenable undertakes no obligation, and expressly disclaims any duty, to update or revise these forward-looking statements to reflect events or circumstances arising after the date hereof, except as required by law.

A critical unauthenticated remote code execution (RCE) zero-day in Adobe Commerce and Magento Open Source, dubbed StyleSmuggler, has been actively exploited since September 4 with attacks observed three days before a vendor patch became available.

1. CVE-2026-75650 is a critical remote code execution vulnerability in Adobe Commerce, Adobe Commerce B2B and Magento Open Source that can be triggered without authentication.
2. Active exploitation of CVE-2026-75650 began on September 4, 2026, three days before Adobe released a hotfix, with multiple victim stores confirmed across different attack campaigns.
3. Adobe released Hotfix VULN-39341 on September 7, 2026, and Tenable detection plugins will be published as they become available.

Tenable's Research Special Operations Team (RSO) has compiled this blog to answer Frequently Asked Questions (FAQ) regarding CVE-2026-75650, a zero-day remote code execution vulnerability in Adobe Commerce, Adobe Commerce B2B and Magento Open Source that has been actively exploited in the wild.

When was CVE-2026-75650 first disclosed?

On September 5, 2026, the Sansec Forensics Team published research detailing an actively exploited zero-day vulnerability in Magento and Adobe Commerce that it named StyleSmuggler.

What is CVE-2026-75650?

CVE-2026-75650 is a remote code execution vulnerability in Adobe Commerce, Adobe Commerce B2B and Magento Open Source. Successful exploitation grants an unauthenticated attacker the ability to execute arbitrary code on a vulnerable server. CVE-2026-75650 carries a CVSSv3 score of 10.0, the highest possible rating. Additionally, its scope is changed, meaning exploitation can impact resources beyond the vulnerable component itself.

The following products and versions are affected:

How does StyleSmuggler work?

StyleSmuggler exploits a flaw in how Magento's template engine processes style-related properties. An attacker crafts a malicious payload containing PHP code and injects it through the styles properties within the template system. Magento writes this attacker-controlled content to disk as part of its normal operations. The injected code is then executed when the platform renders a transactional email template, specifically the “Payment Transaction Failed Reminder” notification. Because this injection path does not sit behind any authentication gate, a remote attacker can trigger it without credentials, and the technique works regardless of which session storage backend is configured.

Once a server is compromised, the attacker deploys a persistent implant. The malware binary is installed at ~/.local/share/.gvfsd/gvfsd-user and masquerades as a Linux kernel thread using the process name [kworker/u:8:0]. It also disguises itself using the process names fc-cache and chronyd, both legitimate system utilities. A cron job restarts the implant every five minutes. Later variants updated the cron interval to twice an hour, and the malware supports both x86-64 and arm64 architectures.

Is CVE-2026-75650 being exploited in the wild?

Yes. Active exploitation of CVE-2026-75650 began on September 4, 2026 according to Sansec. Multiple victim stores have been confirmed across different attack campaigns. Disrex, an incident response firm, had first-hand experience with at least two compromised stores.

Historical exploitation of Adobe Commerce and Magento

Adobe Commerce and its open-source counterpart, Magento, have been recurring targets for attackers. Three prior Adobe Commerce and Magento vulnerabilities have been added to the Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities (KEV) catalog.

CVE-2026-75650 has not yet been added to CISA KEV as of September 8, 2026. There is no CISA Emergency Directive or Alert associated with this vulnerability at this time.

Which threat actors are exploiting CVE-2026-75650?

As of September 8, 2026, there is no public attribution linking the exploitation of CVE-2026-75650 to a specific threat actor or group. Sansec documented activity from at least two distinct operators on the same victim stores: the original group deploying the persistent implant, and a second unrelated attacker dropping a PHP web shell into the product image cache. The techniques and tooling differ significantly between the two, and Sansec treats them as separate campaigns.

Is there a proof-of-concept (PoC) available for CVE-2026-75650?

At the time this blog post was published on September 8, there is no standalone public proof-of-concept for CVE-2026-75650.

Are there indicators of compromise (IoCs) for CVE-2026-75650?

Yes. Sansec published indicators of compromise alongside its StyleSmuggler research. The full IoC list can be found in Sansec's blog.

Has Tenable Research classified CVE-2026-75650 as part of Vulnerability Watch?

Yes. Tenable Research has classified CVE-2026-75650 as a Vulnerability of Interest (VOI) as part of Vulnerability Watch.

Are patches available for CVE-2026-75650?

On September 7, 2026, Adobe released Hotfix VULN-39341 to address CVE-2026-75650. Additional details can be found in Adobe's security bulletin APSB26-146.

Adobe also recommends rotating the encryption key and all credentials it protects following a compromise, including admin passwords, REST, SOAP, and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, SSH and deploy keys, and extension API keys.

At the time exploitation was first observed on September 4, no vendor patch existed. Patching alone does not remediate an existing compromise. Stores that were active during the three-day window before the hotfix require incident response in addition to applying the fix.

Has Tenable released detection coverage for CVE-2026-75650?

A list of Tenable detection plugins for CVE-2026-75650 will be available on the CVE page as they are released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

• Sansec: StyleSmuggler 0day Research
• Adobe Security Bulletin APSB26-146
• Disrex: StyleSmuggler incident response and mitigations

Join Tenable's Research Special Operations (RSO) Team on the Tenable Community.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

When quantum computers become generally available, they’ll be able to crack current public-key cryptographic algorithms, putting digitally stored and transmitted data at risk. But the threat already exists, as attackers use the "harvest now, decrypt later" tactic. Discover why building a comprehensive cryptographic inventory and executing a phased operational strategy are critical for protecting your data against quantum computing attacks.

1. Quantum computing risks are an operational threat today due to "harvest now, decrypt later" (HNDL) tactics, in which adversaries actively harvest and store encrypted data to decrypt it retroactively once quantum capabilities mature.
2. When run on a quantum computer that’s powerful enough, Shor’s Algorithm will break foundational asymmetric infrastructure like the RSA, ECC, and Diffie-Hellman algorithms, although symmetric encryption standards like AES-256 are expected to remain secure against quantum attacks.
3. Globally, more regulatory bodies are starting to mandate a comprehensive cryptographic inventory, making absolute visibility across the digital environment a prerequisite for an orderly post-quantum migration.
4. Transitioning to quantum-resistant cryptography requires a phased operational strategy spanning discovery, prioritization, remediation, and verification.

Future quantum computers will represent a threat to the foundational security architecture that protects digital data. 

For decades, the global economy, national security apparatus, and critical infrastructure have relied on asymmetric cryptography, specifically RSA and elliptic curve cryptography (ECC), to secure data in transit, authenticate identities, and protect digital signatures. The mathematical difficulty of factoring large integers or solving discrete logarithm problems has long provided a robust shield against cyber attacks launched using conventional computing capabilities.

However, the rapid maturation of quantum computing represents an existential threat to these algorithms. A fully fault-tolerant, cryptographically relevant quantum computer (CRQC) capable of instantly shattering current encryption standards is still several years away. However, organizations need to migrate to quantum-resistant algorithms now. The reason? Adversaries are using "harvest now, decrypt later" (HNDL) tactics. They steal data encrypted with algorithms vulnerable to quantum computing attacks, and save it, hoping to decrypt it in the future once quantum capabilities mature.

Recognizing the immediacy of this threat, regulatory agencies have responded accordingly. The White House recently issued Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” which mandates that executive-branch federal agencies pay immediate operational and engineering attention to post-quantum cryptography (PQC) readiness.

This directive introduces critical pillars that redefine enterprise security strategies:

• Accelerated migration timelines: Moving aggressively ahead of prior federal benchmarks, the EO sets a deadline of Dec. 31, 2030, for transitioning high-value assets to PQC for key establishment, and Dec. 31, 2031, for digital signatures. 
• Supply chain and contractor mandates: The EO directs the Federal Acquisition Regulatory (FAR) Council to require covered federal contractors to meet strict post-quantum Federal Information Processing Standards (FIPS) from the National Institute of Standards and Technology (NIST) by the end of 2030.
• Cryptographic weakness as an active vulnerability: In a significant shift for vulnerability management, contractors’ vulnerability disclosure programs (VDPs) must explicitly treat the absence of encryption or the use of non-FIPS-approved algorithms as reportable cryptographic vulnerabilities, effectively redefining crypto-hygiene from a passive audit finding to an active risk-mitigation item.
• The mandate for cryptographic bills of materials (CBOMs): To achieve the complete visibility required for this transition, current and forthcoming frameworks, like CycloneDX, emphasize automated discovery of cryptographic assets across all software, firmware, and hardware dependencies.

In this high-stakes regulatory environment, visibility has emerged as the primary currency of defense. Organizations cannot migrate what they cannot see. Consequently, governments and regulatory bodies worldwide, from the White House and the U.S. National Security Agency (NSA) to the European Union and the Monetary Authority of Singapore, have synchronized their directives around a single, non-negotiable requirement: the establishment of a comprehensive cryptographic inventory. Organizations must identify, catalog, and assess every cryptographic asset within their environment to facilitate an orderly transition to PQC.

Current public-key infrastructure (PKI) relies on the computational intractability of specific mathematical problems. RSA encryption relies on the difficulty of integer factorization, while Diffie-Hellman and ECC rely on the discrete logarithm problem. It would take billions of years for a classical supercomputer to crack a 2048-bit RSA key. 

Quantum computers utilize qubits, which can exist in a state of superposition, representing both 0 and 1 simultaneously. This property, combined with quantum entanglement, allows for massive parallelism in calculation. 

In 1994, mathematician Peter Shor developed Shor’s Algorithm, which theoretically demonstrated that a quantum computer with sufficiently stable qubits could solve both integer factorization and discrete logarithm problems in polynomial time versus problems in exponential time on a classical computer. In other words, a problem that would take an impossibly long time for any real-world computer problem to solve can now be solved in a usefully short amount of time.

The implications are catastrophic for current standards:

• RSA-2048 and RSA-4096: Completely broken.
• Elliptic-curve Diffie–Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA): Completely broken.
• Diffie-Hellman: Completely broken.

Symmetric encryption, like AES-256, is more resilient; Grover’s Algorithm effectively halves the key strength, meaning AES-128 provides only 64 bits of security, but AES-256 remains secure against quantum attacks. Therefore, the immediate crisis is concentrated in asymmetric cryptography used for key exchange, such as TLS/SSL handshakes and SSH session negotiation, as well as for digital signatures (authentication, code signing).

The most pervasive misconception regarding PQC is that organizations have until Q-Day, the day a CRQC comes online, to upgrade their systems. This view ignores the “harvest now, decrypt later” attack vector, which has fundamentally shifted the risk timeline from the future to the present.

In an HNDL attack, sophisticated adversaries, primarily nation-states and well-funded criminal syndicates, intercept encrypted traffic today. At scale, this harvesting is primarily executed by nation-states utilizing Border Gateway Protocol (BGP) route manipulations to hijack large volumes of data in transit, alongside the exfiltration and theft of whole encrypted databases during network intrusions. While attackers cannot currently read this data, they store it in massive data centers, effectively time-capsuling the information. The moment a quantum computer capable of running Shor’s Algorithm becomes available, they will then decrypt this harvested data.

Implementing the right tools is only the first step. Organizations need a coherent operational strategy to navigate the migration. Based on NIST SP 1800-38 and CISA guidance, the following phased approach is recommended.

Phase 1: Automated discovery: Establish the baseline. You cannot fix what you do not know exists. Within environments, discovery goes a step further than reading configurations: Organizations should inventory resources from the connected accounts and actively scan their internet-facing services to capture the key exchanges and ciphers these services negotiate. Because HDNL targets data in transit, this outside-in view pinpoints the exposed cloud services most at risk and folds them directly into your exposure management workflow.

Phase 2: Prioritization and risk assessment: Not every server needs PQC today. Identify systems with the highest risk and the most critical data.

Phase 3: Remediation and crypto-agility: Upgrade systems to hybrid — meaning, running in parallel both conventional cryptography and PQC — and, finally, fully PQC compliant. Governmental mandates generally have set the year 2035 for complete quantum resistance for all systems. Avoid hard-coding the new algorithms. Use configurations that allow you to swap algorithms easily. The PQC standards are new; if a vulnerability is found next year in one of the new PQC standards, you must be able to switch to an alternative without recompiling code.

Phase 4: Continuous verification: Prevent regression by making regular compliance assessments. A system might be compliant today, but a DevOps push next week might overwrite the config file and revert it to RSA-only. Continuous scanning ensures you maintain the quantum safe state over time.

Closing the gap on HNDL starts with treating cryptographic risk as just another exposure to manage, not a separate audit exercise.

Bring SSL/TLS and SSH protocol visibility across your cloud and IT infrastructure into the Tenable One Exposure Management Platform's workflow you use to track vulnerabilities, misconfigurations, and identity risk. That way, cryptographic weaknesses surface alongside everything else competing for your team’s attention, instead of living in a separate report.

That visibility comes together in Tenable One’s Cryptographic Inventory view, which shows where cryptographic risk lives across your environment: Which services still rely on classical, quantum-vulnerable ciphers, and which have already moved to post-quantum protection. Widgets summarize your overall cryptographic posture at a glance, so quantum readiness becomes one more metric in your exposure picture.

What the cryptographic inventory view surfaces:

• Services using PQC: 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 PQC: Reports on services that support no post-quantum ciphers.
• Cipher inventory: View an asset JSON-based inventory by service and cipher.
• TLS and SSH weaknesses: View plugins that have detected weaknesses in conventional-computing algorithms.
• Certificate expiry and configuration concerns: See certificates that have expired or are soon to expire, as well as configuration concerns such as self-signed certificates.

Users can drill down into specific assets to see the JSON-based Cryptographic Inventory and use the Tenable Asset Criticality Rating (ACR) to help with prioritization of systems for remediation. ACR assesses factors like device function, connectivity, and third-party data. Assets with higher ACR (e.g., 6–10) are more critical to your business.
 

Post-quantum cipher analysis dashboard in the Tenable One Exposure Management Platform

The transition to PQC is an immediate engineering and compliance challenge for today's leadership. The HNDL threat makes the risks a current reality, while the strict enforcement mechanisms of Executive Order 14412, alongside international regulatory frameworks like the EU’s Digital Operational Resilience Act (DORA), ensure that the compliance and contractual consequences are imminent. 

The days of treating cryptography as a set-and-forget utility are over. Cryptography is now a dynamic asset class that requires active management, continuous inventory, and strategic agility. 

Tenable’s introduction of the set of Cryptographic Inventory dashboards and plugins represents a critical evolution in vulnerability management. It provides the data foundation necessary for the PQC transition. It empowers organizations to answer the regulator’s question, “Are you quantum ready?”, with data, precision, and confidence. The quantum era is arriving. With the right visibility, organizations can ensure their security arrives with it.

Discover how Tenable’s shift to an AI-driven exposure management program helped Tenable’s CSO, Robert Huber, overcome tool sprawl, unify data silos, mitigate the risk of rapid AI adoption, and shift from presenting granular, technical metrics to communicating business risk that the C-suite and the board can understand.

1. Security tool sprawl and data silos make it difficult for CISOs to holistically and accurately assess their organizations’ cyber risk.
2. An exposure management program consolidates fragmented security data into a single unified view of cyber risk across the entire attack surface. 
3. Aided by exposure management, CISOs can align security metrics with business priorities and quantify risk for key revenue-generating business units, answering the board’s main question: “Are we secure?”

What is trust in cybersecurity? And more importantly, how do you earn it? Here’s a hint: It’s not easy, especially in this AI era. 

As the Chief Security Officer at Tenable, my mandate is to ensure our organization operates securely, but with the speed required to succeed in a very competitive business environment. In recent years, achieving this delicate balance — an agile yet cyber secure business — had become progressively more difficult, as we grappled with increasingly fragmented data, siloed teams, and security tool sprawl.

In this blog, I’ll explain how exposure management helped my team: 

• Tackle security tool sprawl
• Bridge operational and data silos 
• Take a more proactive approach to security
• Attain visibility and control over Tenable’s attack surface
• Continuously and precisely assess our cyber risk posture

For years, the cybersecurity industry’s answer to every new threat or policy mandate was simple: Buy another tool, which in many — maybe most — organizations resulted in a bad case of tool sprawl. A typical large enterprise might juggle 70 or more security technology vendors, each promising to solve a specific problem. At Tenable, my team manages around 50 different security tools.

We found ourselves in a situation where siloed teams were running siloed tools, with separate views, prioritization criteria, key performance indicators, remediation workflows, and reporting. 

To illustrate this internally, I used to present a visualization of our architecture that I called the “spaghetti chart.” It was a tangled web of inputs from endpoint detection and response (EDR) vendors, bug bounty programs, vulnerability scans, security operation center (SOC) findings, penetration tests, and more. Each tool demanded its own unique workflow. As you can see, the spaghetti chart presented a picture of chaos. It reminded me of Gen. Stanley McChrystal’s quip regarding a spaghetti chart he was presented with during the war in Afghanistan: “When we understand that slide, we’ll have won the war.” Similarly, we could have said: “When we understand that chart, we’ll have eradicated cyber risk.”
 

The consequences of this fragmented approach to security became glaringly apparent during my board presentations. At one board meeting, I arrived with a deck consisting of 45 slides. An exhausting 30 of those slides were packed with metrics, KPIs, and raw data.

My team worked incredibly hard to pull that information together to build a narrative. Yet, I faced a hard truth: many of the business leaders and board members did not understand those metrics. When you present purely operational metrics, like the raw number of vulnerabilities or the number of scanned assets, you lose the C-suite’s attention. Those numbers don’t translate to business impact.

At the executive leadership and board level, I generally get asked two simple questions.

First: “Are we secure?” I may also get asked a variation, such as: “What’s our exposure?” From my 30 metric-heavy slides, generated from 50-plus tools with their own disparate reporting functions, I had to somehow boil the ocean of data and make a judgment call as to how secure we actually were.

The second question I get asked is: “How do we compare to peers?” As a publicly traded cybersecurity company, we have a strict fiduciary responsibility. The board wants to ensure we are maintaining a reasonable cybersecurity standard of care. Are we doing the things we’re supposed to be doing, that are expected of us by our shareholders, customers, and partners?

My job is to take those 50-plus tools, aggregate all the KPIs, and turn them into a meaningful assessment of Tenable’s cyber exposure that leadership can easily understand. We have multiple lines of business aligned by different products, regions, and services. True cyber risk management means being able to answer questions like: What is the associated revenue tied to each individual line of business, what level of cyber risk does each one face, and how can this risk be most effectively mitigated?

Without business context, you simply cannot prioritize effectively.
 

Tenable One dashboard showing line-of-business cyber risk levels at a hypothetical enterprise 

Unfortunately, the siloed nature of our security architecture created friction not just at the top, but across the entire business. When my team reached out to engineering and IT leaders, we frequently handed them numerous fragmented reports and manual spreadsheets for each security domain, including cloud security, vulnerability management, app security, pen testing, compliance auditing, and more. 

The problem arose when these engineering leaders, who have critical day jobs building and maintaining our products, looked at me and asked: “Bob, what the heck do you want me to do? What do I start with? How do I prioritize that?”

Coordinating reporting, mitigations, and remediations became a massive challenge. It didn’t scale well for my security teams, and it certainly didn’t scale for the receiving engineering teams, whom we hit up every week for their time. 

And then, our friend AI moved the goalposts again. Every day feels like Groundhog Day: You wake up, and the newest AI capability drops out of the sky. As we ramped our AI adoption internally, our attack surface continued to expand. We knew we needed to manage AI security risks alongside traditional cyber risks. We also knew we needed visibility and context to make informed decisions about which AI security risks we were going to accept so that we could continue to move at the speed of trust. But I knew our old, siloed approach was untenable at the speed we needed to operate.

To truly unify our risk posture, we fundamentally changed our organizational structure. We evolved our vulnerability management team into an exposure management team. We unified all our security areas into a single foundational exposure management policy. Instead of just managing traditional CVEs, the exposure management policy needed to encompass a wider range of security issues, including misconfigurations and identity weaknesses, across the massive, modern attack surface: identity systems, cloud workloads, AI tools, on-prem assets, the application development pipeline, and more.

Broadening the mandate of the vulnerability management team to encompass all forms of exposure represented a massive operational shift, but notably, it didn’t increase our headcount. Instead, by centralizing our data, other specialized teams, like cloud security and application security, got time back to focus on securely deploying infrastructure rather than chasing down colleagues for patch management. The exposure management team became the centralized “go-get-’em” team across the board. They don’t operate all 50 tools, but they are the ones who triage everything.

I then tasked my exposure management team with solving the fragmentation problem. We wrestled with the issue of “build vs. buy.” Should we dump all of the data from all of our different tools into a giant data store, and try to add analysis, workflow and reporting to that, or should we look for alternative, out-of-the-box solutions that might already exist. 

In the end, we decided not to build it ourselves, largely because building and maintaining a data warehouse is not our core competency, and it can get very expensive, very quickly with infrastructure, data costs, and specialized staff. Instead, we evaluated a bunch of vendors that could help us centralize our risk data with existing SaaS solutions. We chose one specific solution that best fit our integration and workflow requirements. In the end, we ended up acquiring the entire company, Vulcan Cyber, for these same reasons. And today, it is a foundational part of our Tenable One Exposure Management Platform.

As a result of shifting to an exposure management approach and consolidating security data within a single platform, the “spaghetti” chart got transformed into this:
 

The manifestation of this journey within our own Tenable One platform is what my team lovingly calls, “Bob’s simple metrics.” We instituted a direct visualization using the traffic-light protocol: the colors red, yellow, and green to categorize the level of cyber exposure for each of our lines of business. Red signifies critical risk. Yellow means it needs attention. Green indicates a healthy security posture. We aggressively tagged assets to contextualize them, tying specific infrastructure directly to business units and revenue streams.

We also automated the identification of what I call the “big rocks.” For example, if we can’t patch an asset because of system instability, our platform flags this as a systemic root-cause issue rather than just blindly listing individual vulnerabilities. We now have customized service level agreements (SLAs) tailored by region and business impact, enabling teams to track their performance against these targets effortlessly.

The aim of exposure management is to permanently change the conversation security leaders and their teams have with stakeholders. For instance, instead of overwhelming engineering teams with fragmented reports and drowning the board in 30 slides of operational metrics, we now provide a clear, data-driven workflow. We give the business a concise, prioritized list of actions that genuinely reduce risk.

Now is the time for exposure management. It is the only way to operate at machine speed. If you still have to manually schedule a patch window or pivot between 50 different dashboards to figure out your risk posture, you’ve already lost. Legacy vulnerability management is simply not going to work going forward. 

By breaking down security silos and unifying our risk data, we’ve built an exposure management program that the C-suite, the board, and the business can finally trust.

Learn more about the Tenable One Exposure Management Platform

A joint Tenable-SentinelOne analysis of 93 CVE-actor attribution pairs reveals that both state-sponsored actors and cybercriminals independently converge on the same edge infrastructure. Special thanks to SentinelOne® Incident Readiness & Response for their contributions to this publication.

It is the shared attack surface where state-sponsored threat actors and financially motivated criminal groups independently converge — not the province of a single adversary category, and not exclusively a nation-state problem, despite two years of headlines about China-nexus actors targeting Ivanti, Fortinet, and Palo Alto Networks. The data here tells a different and much broader story. One focused on vendors vs CVEs.

1. Two independent observation systems, Tenable exposure telemetry across thousands of customer containers and SentinelOne DFIR casework across 66 CVEs, converge 79% on the same vendor attack surfaces despite minimal CVE-level overlap.
2. Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories (China, Russia, DPRK, Iran, ransomware).
3. The exposure picture is flatter than the headlines suggest: Fortinet, the vendor most associated with edge-device attacks in the press, sits mid-pack on container-grain exposure (25%) — well behind F5 (54%) and in a tight 10-point band with Check Point, Ivanti, and Citrix.
4. 54% of customer environments running F5 products have at least one exposed, actively-exploited CVE; Citrix customers show the slowest remediation patterns at 461 days median time to patch.
5. Remediation complexity, particularly of high priority CVEs, leads to a statistically significant 24-day remediation gap, leaving large windows of opportunity for attackers.
6. The same product lines get hit again and again: Ivanti EPMM and Ivanti Connect Secure each show a newly exploited CVE roughly every 8.5 to 13 months.
7. Leverage multiple defense-in-depth strategies: patch as quickly as possible, but also minimize the attack surface (feature-set minimization) and run endpoints in protect mode to better stop lateral movement from attacks that gain initial access.

Twelve CVEs in the combined dataset have confirmed multi-nexus attribution: state-sponsored and criminal actors independently exploiting the same vulnerability, across five nexus categories. Four examples illustrate the pattern:

The remaining eight confirmed multi-nexus CVEs span Fortinet, Citrix, Cisco, and Ivanti product lines. State-sponsored actors and ransomware operators are not operating in separate vulnerability ecosystems. They share the same entry points into the same products. The breadth of the convergence, not any single actor's activity, is the finding.

That pattern holds across the full combined analysis. Three conclusions emerge:

Vendor attack surfaces are the persistent exploitation target. The same eleven vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta's React framework) appear in both observation systems at 79% convergence, and all seven edge-product vendors converge. Serial exploitation timing on Ivanti products shows the vulnerability-to-exploitation pipeline refreshing at 8.5 to 13-month intervals on the same product lines. This is structural, not episodic. Patching the current CVE does not remove the vendor attack surface from the threat landscape.

State-sponsored and ransomware actors converge structurally. Twelve CVEs with confirmed multi-nexus attribution span all five nexus categories and cross the state-criminal divide. Defending against one actor category on edge devices necessarily requires defending against all of them, because the attack surface is shared. An organization that patches only for nation-state TTPs leaves itself exposed to ransomware operators exploiting the same vulnerability, and vice versa.

High-priority CVEs take more time to remediate, not less. Across Tenable's 238-CVE high-priority list, high-priority CVEs carry a median remediation time of 146 days, compared to 122 days for all other CVEs — a 24-day gap that is statistically significant. The edge-appliance-specific subset (52 CVEs) shows a consistent 8-day gap in the same direction, which was not statistically significant, but suggests the direction may hold for edge appliances too. External data corroborates the pattern: the 2026 Verizon Data Breach Investigations Report (DBIR) found that median patch time increased from 32 to 43 days year over year, even as exploitation overtook credential theft as the number one initial access vector, and the 2025 DBIR, which incorporated Tenable RSO's remediation trend analysis across 17 edge-related CVEs, found that only 54% of edge device KEVs were fully remediated. The explanation is structural: edge devices are the network boundary, so patching a VPN gateway or firewall means downtime for every user behind it, and change management gates multiply. These devices also resist standard patching workflows because they do not run endpoint agents, often require firmware-level updates with manual validation, and frequently lack active support contracts. The result is that the devices most worth patching are operationally the hardest to patch — and as the high-priority queue grows (the 2026 DBIR reports 50% more critical vulnerabilities to patch than the prior year), everything on it waits longer.

Edge and perimeter devices occupy a uniquely consequential position in enterprise architecture. VPN gateways, firewalls, remote access appliances, and application delivery controllers sit at the boundary between trusted and untrusted networks. They are very often the first component an attacker touches and, for many organizations, the last component that gets patched. When one of these devices is compromised, the attacker inherits its network position: inside the perimeter, with access to internal resources, often without triggering endpoint detection.

This analysis combines two independent datasets to demonstrate that convergence. Tenable contributes exposure telemetry from the Tenable One Exposure Management Platform, covering thousands of customer containers and measuring what edge infrastructure is deployed, what is vulnerable, and how long it remains unpatched. This dataset extends Tenable Research's ongoing analysis of edge device exposure trends, including the remediation telemetry Tenable contributed to the 2025 and 2026 Verizon DBIR reports. SentinelOne contributes findings from its digital forensics and incident response (DFIR) practice, documenting which threat actors actually exploit which vulnerabilities, observed firsthand inside compromised environments. Neither dataset was built for this analysis; each was constructed independently for different operational purposes.

The finding that makes this analysis compelling is not about any single CVE or any single actor. It is the structural convergence: two independent observation systems, looking at the problem from opposite sides, arrive at the same conclusion about which vendor surfaces are under persistent, broad exploitation, and by whom. (For how each dataset was built and scored, see the Methodology appendix below.)

Tenable's exposure telemetry provides the vulnerability-side view. All exposure metrics reported here use container-grain measurement: the percentage of customer environments (organizational containers) with at least one asset vulnerable to a given CVE as of Aug. 15, 2026, relative to total exposed containers over the preceding 14-month period. This measures breadth of organizational exposure to edge-product vendor vulnerabilities, not raw asset counts, across the sampling window.

This section covers 15 vendors in three groups: seven confirmed in both independently compiled corpora, two confirmed in SentinelOne's casework but absent from Tenable's attributed corpus, and six "candidate" vendors surfaced by a broader screen of Tenable telemetry. The candidates are not part of the convergence finding, but two, F5 and Zimbra, show broader customer exposure than most of the confirmed seven, so omitting them would understate the breadth of at-risk edge infrastructure.

[FIGURE: Current vendor-level exposure heat map (container-grain, 15 vendors). Proportion of historically-exposed containers with at least one asset actively exposed to one or more relevant CVEs. Source: Tenable exposure telemetry.]

F5 and Citrix lead for different reasons. Among vendors with statistically robust sample sizes, F5 customers are the most broadly exposed: 53.8% of 2,784 monitored customer environments running F5 products have at least one actively exploited CVE present. Citrix customers show the slowest remediation patterns: a median of 461 days to patch, with 71% of affected environments still carrying unpatched Citrix CVEs after a full year. F5 leads on scale of exposure; Citrix leads on persistent exposure.

The mid-pack is flatter than expected. Check Point (18.6%), Ivanti (24.1%), Fortinet (24.9%), and Citrix (28.8%) cluster within a 10-point band at container-grain. Fortinet, which dominates headlines, is mid-pack by this measure.

Thin-sample vendors show extreme rates but require caution. Juniper (91.7%), VMware (75.0%), Palo Alto Networks (69.2%), and Cisco (56.2%) all show container-exposure proportions above 50%, but each has fewer than 50 in-sample containers. These statistics are real directional signals, but should be considered within the context of the relatively low sample size.

Serial exploitation is structural. Two clean serial-exploitation sequences appear in the dataset: Ivanti EPMM (approximately 8.5 months between successive exploited CVEs) and Ivanti Connect Secure (approximately 13 months). Same product line, new vulnerability, repeat exploitation. Tenable Research has published advisories on both Ivanti exploitation sequences, tracking each CVE from initial disclosure through active exploitation, and the exposure data here extends that analysis with organizational remediation timelines not available at the time of the original advisories. The next one is coming.

This is not a targeted effort by a specific group. Edge infrastructure is a core focal point of attack across a broad range of threat actors and nexus categories. The combined Tenable-SentinelOne corpus documents exploitation by actors spanning five nexus categories: China, Russia, DPRK, Iran, and criminal (financially motivated). All five categories independently target the same vendor surfaces. Every attribution in the corpus is bucketed into one of three confidence tiers derived from a five-dimensional rubric evaluating attribution directness, evidence provenance, recency, exploitation role, and source corroboration. Confidence tiers, from high to low, are: DIRECT, TECHNIQUE-ALIGNED, or INFERRED.

Actor density scales with vendor exposure. Fortinet products face the broadest actor surface: 29 distinct threat actors across five nexus categories. Citrix follows with 22 actors across five categories, Ivanti with 19 across four, Palo Alto Networks with nine across three, and Check Point with six across two. Every focal vendor has confirmed exploitation from multiple nexus categories. No single vendor's exposure is attributable to a single adversary group.

China-nexus actors are the highest-confidence case study, appearing across nine vendors in the corpus, with four DIRECT-tier attributions from the scored dataset alone. But the analytical value here is not that China targets edge devices. That is well established. The value is that China, Russia, DPRK, Iran, and ransomware operators all target the same edge devices, as the examples above illustrate. The governed attribution methodology is what allows this claim to be made with precision: we can distinguish confirmed multi-nexus convergence (DIRECT-tier evidence on both sides) from assessed convergence (INFERRED, requiring corroboration).

Exposure data shows which appliances are reachable, vulnerable, and unpatched. Incident response looks at what happened when attackers got in: what they accessed, what they took, and where they went next. In SentinelOne DFIR cases involving edge infrastructure, attackers used credentials stored on the appliances and the access those appliances already had to reach internal systems.

Credential theft from edge appliances

Across three engagements, threat actors reached the management plane of FortiGate appliances and created rogue administrative accounts. In two, they also exported device configurations and extracted credentials that could be used to move further into the network. Two of these three are documented in detail in FortiGate Edge Intrusions.

In one of those two, the exported configuration contained LDAP bind credentials for a directory service account. The account was later used in the environment. A few hours later, the threat actor added two computers to the domain. Neither had a Service Principal Name, which is unusual for a legitimate domain join. The mS-DS-CreatorSID attribute on both accounts pointed back to the stolen service account.

We saw similar activity on an Ivanti Cloud Services Appliance in late 2024. A China-nexus actor chained CVE-2024-8963 with CVE-2024-8190 before the first public disclosure in the chain. After gaining access, the actor collected SSH keys and other stored credentials. That engagement is documented as Activity F in Follow the Smoke.

These appliances did not provide conventional endpoint telemetry. We had to follow the activity into authentication records, newly created Active Directory objects, and the later use of credentials taken from the appliances.

When the initial access vector cannot be confirmed

In December 2025, Fortinet disclosed CVE-2025-59718, an authentication bypass in its FortiCloud SSO integration affecting FortiOS and other products. Several weeks later, Fortinet disclosed CVE-2026-24858. This second flaw allowed an attacker with a FortiCloud account and a registered device to log into devices belonging to other customers when FortiCloud SSO was enabled.

That overlap mattered in one of the three engagements above. The appliance was running a version affected by both CVEs, but the available logs did not show when or how the attacker first gained access. The earliest retained malicious activity showed a rogue local administrator account. A few minutes later, a domain administrator authenticated from the appliance's VPN address pool. Exposure data showed that the appliance had been vulnerable to both CVEs, but that alone did not establish how it was compromised. We treated both as possible, not confirmed, initial-access vectors.

Abuse of trusted management access

In one SentinelOne DFIR engagement involving a FortiManager appliance, CVE-2024-47575 allowed an unauthorized device to register with the appliance through the management protocol. Two log entries, seconds apart, recorded the rogue registration and the settings change that followed. The threat actor then staged an archive of managed-device configurations that could expose credentials, addresses, and details about the network. The actor had been present for about a month before the customer detected the activity.

In a separate engagement, a threat actor chained SQL injection, pass-the-hash authentication, and authentication bypass against an internet-facing SonicWall GMS console (CVE-2023-34133, CVE-2023-34132, and CVE-2023-34124). The actor created administrative accounts on a platform operated by a managed service provider, then used existing shared access to enter multiple customer environments. Most of the resulting traffic was advertising-related, leading us to assess that the infrastructure was being used for click fraud.

The actors were after different things. One collected configuration data and information about the network. The other used the access to turn systems across several environments into proxies. In both cases, the actor inherited the access that the organization had already granted to the management platform. These cases show the difference between the two views: exposure telemetry finds the vulnerable device, while incident response shows what was taken from it and where the attacker went next.

Patch F5 and Citrix edge devices immediately. These two vendors combine the highest exposure rates with the slowest remediation timelines across statistically robust samples. Look for strategies to reduce the remediation time, particularly for weaponized CVEs. Additionally, reduce the attack surface by minimizing the enabled feature set on these devices and aim for defense in depth by running endpoints in protect mode to limit lateral movement opportunities.

Audit Ivanti Connect Secure and EPMM deployments. Serial exploitation on observed 8.5 to 13-month cycles means the next exploitable CVE in these product lines is a question of timing, not probability. Organizations running Ivanti edge products should assume they will face a new actively exploited vulnerability within the next year and plan patching capacity accordingly.

Implement edge-device-specific patch SLAs. The delayed remediation paradox demonstrates that general priority frameworks do not translate into faster patching on the devices that sit at the network boundary. Edge devices and network infrastructure warrant dedicated remediation timelines that are shorter than the organizational default and commensurate with the elevated risk.

Treat edge device exposure as a cross-signal priority. Attribution, severity, and exposure volume identify different CVEs as "top priority." Organizations need all three signals for complete coverage. A vulnerability management program that prioritizes exclusively by CVSS will systematically underweight CVEs with strong exploitation evidence but modest severity scores, and vice versa. The Tenable One Exposure Management Platform enables this cross-signal approach by combining vulnerability severity, exposure intelligence, asset context, and exposure data into a unified prioritization view.

Tenable customers can use the Tenable Vulnerability Watch dashboard to monitor classifications for all CVEs discussed in this analysis. A list of Tenable plugins for the vulnerabilities discussed in this analysis can be found on the individual CVE pages at tenable.com/cve as they are released. This link displays all available plugins for each vulnerability, including upcoming plugins in our Plugins Pipeline.

• Tenable Vulnerability Watch
• SentinelOne – What two independent datasets reveal about who's exploiting your perimeter
• SentinelOne Threat Research (PurpleHaze, SonicWall SMA1000)
• FortiGate Edge Intrusions – SentinelOne
• Follow the Smoke – SentinelOne
• CISA Known Exploited Vulnerabilities Catalog

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

How the corpus was built. Tenable's 33-CVE corpus was derived by combining and deduplicating vulnerabilities with the highest exploitation volume and broadest actor adoption; SentinelOne validated CVEs across 14 vendors, and their 66-CVE landscape view reflects 12 months of DFIR casework with false positives removed. Combined, the two datasets identify 82 distinct CVEs, 17 of which appear in both. Layered on top of these sources is a governed attribution corpus of 93 CVE-actor pairs spanning approximately 39 named threat actors and five nexus categories.

Why Tenable tracks these CVEs. Tenable's set comes out of exposure management. A CVE enters it through the Vulnerability Watch program, which classifies vulnerabilities under active or likely to be exploited, and is additionally scored with a Vulnerability Priority Rating (VPR). The question being answered is prescriptive: of everything actually deployed across customer environments, what should be prioritized and patched first? Threat-actor attribution is layered on afterward from definitive and confidence-scored sources (e.g., Federal cybersecurity advisories).

Why SentinelOne tracks these CVEs. SentinelOne's set comes from the opposite direction: incident response. A CVE earns its place in their 12-month DFIR landscape because responders found it used in a real intrusion — the initial access vector in a case someone called them about. The question being answered is forensic: what happened here, and who did it? Coverage is shaped by who engaged them, not by install base.

What "overlap" means here. Overlap was measured at two levels, and the answer changes sharply depending on which level you use.

At the level of the individual vulnerability, the two sets barely intersect. Only 17 of 82, or 21%, of CVEs are common to both. Tenable and SentinelOne are, for the most part, not looking at the same vulnerabilities. However, the datasets converge at the product level. Eleven of the 14 vendors in Tenable's focal CVE set appear in SentinelOne's 12-month DFIR landscape – a 79% convergence: Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, VMware, Microsoft, Oracle, CrushFTP, and Meta's React framework. That's 79% convergence at the vendor level against 21% at the CVE level. Three vendors did not conform: Apache and SAP were absent from SentinelOne's casework, and the one Progress case they worked on was closed as a false positive. Narrow the comparison to edge and remote-access infrastructure specifically, and the convergence is a perfect 100%. Tenable's corpus independently identified seven edge vendors (i.e., Fortinet, Citrix, Ivanti, Palo Alto Networks, Cisco, Juniper, and VMware). All seven appear in SentinelOne's casework. Two teams, working from unrelated evidence for unrelated purposes, arrived at the same seven vendors while sharing roughly one CVE in five.

Why the distinction matters. "Different vulnerabilities, same vendors" is not a weaker version of "same vulnerabilities." It is a different and more actionable claim. Had both datasets converged on the same individual CVEs, the story would be that a specific handful of vulnerabilities is being widely exploited: patch those and the problem shrinks. What the data actually shows is that state-sponsored and criminal operators are independently arriving at the same small set of edge and remote-access product vendors, then finding their own separate ways in. The durable target is the vendor attack surface. Patching this quarter's Ivanti CVE does not remove Ivanti from anyone's target list.

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third party.

A joint cybersecurity advisory released by multiple U.S. government agencies warns that threat actors are using AI-generated exploitation scripts to target exposed Siemens S7 Series PLCs across critical infrastructure sectors.

1. Unattributed threat actors are exploiting known weaknesses and unnecessary internet exposure to conduct reconnaissance and possible pre-positioning for future disruptive attacks against Siemens S7 Series PLCs.
2. The attackers are leveraging AI to build and refine exploit scripts faster than manual development would allow. AI use lowers the technical bar for ICS attacks in a way defenders haven't had to plan for before.
3. There is no single patch, because there is no single flaw. Mitigation depends on removing Siemens S7 Series PLCs from direct internet exposure, segmenting OT from IT networks and hardening access controls.

On August 19, 2026, the National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), the Department of Energy (DOE) and the Environmental Protection Agency (EPA) released a joint Cybersecurity Advisory (AA26-231A) warning that threat actors are actively targeting Siemens S7 Series programmable logic controllers (PLCs) that are exposed to the internet or insufficiently segmented from it. The activity spans the S7-200, S7-300, S7-400, S7-1200 and S7-1500 series and most heavily affects the Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture and Commercial Facilities sectors, with potential exposure in the Defense Industrial Base as well.

According to the authoring agencies, threat actors are using AI-generated exploitation scripts, disguised as legitimate operational technology (OT) monitoring tools, to conduct reconnaissance and build capability against exposed PLCs. The Tenable Research Special Operations Team (RSO) has put together this frequently asked questions (FAQ) blog to help security and OT teams understand the threats, the techniques involved and the mitigations offered by the authoring agencies. The advisory itself notes that ongoing PLC targeting is broader than Siemens alone and that all PLC owners and operators, regardless of vendor, should apply all relevant mitigations.

What is the active threat to Siemens S7 Series PLCs?

The advisory describes coordinated reconnaissance and capability-development activity against Siemens S7 Series PLCs that are internet-exposed or poorly segmented. According to the authoring agencies, the threat actors combine internet scanning services with AI-assisted scripting to build custom tools that can read and write PLC memory, configuration data, and ladder logic programs over the S7comm protocol, while masquerading as legitimate monitoring software.The agencies assess the activity as persistent reconnaissance intended to develop capabilities and pre-position for future disruptive attacks against critical infrastructure

Which Siemens PLC models are being targeted?

The advisory identifies five Siemens S7 Series product lines as targets:

How is this different from the Iranian-linked PLC campaign covered in AA26-097A?

In April 2026, CISA and its partners, including NSA, the FBI, EPA, DOE, U.S. Cyber Command, and the Treasury Department, issued and later expanded cybersecurity advisory AA26-097A, which detailed a campaign publicly linked to Iran-affiliated actors tracked as CyberAv3ngers. That campaign exploited internet-exposed PLCs from Rockwell Automation, Schneider Electric and Siemens using the vendors' own engineering software to manipulate readings and exfiltrate project files. The updates to that advisory were made just days before the news of attacks involving several water districts, including those in Minnesota. For more information on these attacks, please refer to the RSO blog; Coordinated "cyberattack" on U.S. water utilities: What you need to know.

This new advisory covers a distinct activity pattern specifically centered on the Siemens S7 Series devices. The authoring agencies do not attribute these attacks to any named threat actor or group. The techniques described in this advisory describe threat actors leveraging AI to design scripts built on open-source industrial automation libraries, including snap7.dll, disguising these scripts as monitoring tools. Organizations should treat the two advisories as related but separate threats to the same class of equipment, and should apply the mitigations in both if they operate Siemens S7 Series PLCs. However, as the advisory points out, regardless of which PLCs your organization may operate, the recommendations are to apply the proper mitigations to help secure these devices, including mitigations from this guide.

Which threat actors are behind this activity?

The authoring agencies have not attributed this activity to a specific named threat actor or group. The advisory refers to the activity generically as being conducted by "threat actors" and describes confirmed reconnaissance, tool development and read/write operations against target PLCs without confirmed attribution to a tracked group. Tenable's RSO team will update this post if attribution information becomes available.

What is new about the AI-assisted exploitation described in the advisory?

According to the advisory, attackers are using AI to generate exploitation scripts, demonstrating a new capability dimension in the PLC targeting. The advisory describes threat actors combining publicly available open source industrial automation libraries (specifically snap7.dll and python-snap7) with AI-assisted scripting to create custom tools. These tools could be leveraged to provide read/write access to Siemens S7 Series PLC memory, configuration data and ladder logic programs via the S7comm protocol.

This represents an evolution in OT threat actor capabilities. AI dramatically reduces the technical expertise required to develop working ICS exploitation tools. Building functional S7comm exploitation scripts previously required specialized protocol knowledge and threat actor use of AI collapses that barrier. Coupling these capabilities with internet accessible devices provides attackers with abundant resources to test, iterate and rapidly improve their exploits.

Are specific CVEs associated with this advisory?

No individual CVE identifiers are named in the advisory. Instead, the authoring agencies state that if these PLCs are exposed to the internet or insufficiently segmented, threat actors "can exploit various critical and high severity known vulnerabilities." The advisory directs owners and operators to consult Siemens ProductCERT advisories for model and firmware-specific vulnerability details or mitigation options if patches are not available or cannot be immediately applied.

Does this involve zero-day exploitation?

No. The advisory describes exploitation of known vulnerabilities, weak or default credentials and unnecessary internet exposure, not a previously unknown or undisclosed flaw. The novel element the authoring agencies highlight is the use of AI to generate and rapidly iterate exploitation scripts and evasive tooling, not zero-day exploitation of an undisclosed vulnerability.

What techniques are the threat actors using?

The advisory maps the observed activity to the MITRE ATT&CK Matrix for ICS and MITRE ATT&CK Matrix for Enterprise frameworks:

Is there a proof-of-concept or working exploit code available?

The threat actors described in the advisory have functional, custom-built exploitation tooling in active use; this is not an unconfirmed or theoretical capability. However, the authoring agencies have not published this tooling and Tenable is not aware of a publicly available proof-of-concept (PoC) tied to this specific campaign as of the date this blog was published. Because the actors are using AI to generate and rapidly iterate their own scripts, organizations should not treat the absence of a public PoC as a reason to deprioritize mitigation.

What are the potential operational impacts?

The advisory outlines several potential consequences of unauthorized PLC access:

• Disruption of critical industrial processes. This can impact production throughput, product quality and public services
• Safety incidents from manipulation. This could lead to emergency shutdowns, manipulation of safety interlocks or manipulation of process parameters
• Equipment damage and extended operational downtime
• Compromise of sensitive operational data
• Cascading impacts across interconnected systems, supply chains and dependent facilities
• Regulatory compliance violations tied to process safety management failures

Are patches or mitigations available?

Because this activity exploits internet exposure, improper configurations and a range of known vulnerabilities, rather than a single flaw, there is no single patch that resolves all risks related to this advisory. Instead, owners and operators are recommended to contact Siemens ProductCERT for firmware updates addressing known vulnerabilities in each affected CPU family, with priority given to internet-facing or DMZ-resident controllers. Additionally, the advisory outlines seven categories of hardening action:

• Inventory all Siemens S7 Series PLCs and engineering workstations
• Applying current firmware and TIA Portal/STEP 7 updates
• Verifying segmentation and blocking TCP port 102 at the network perimeter
• Strengthen access controls including restricting engineering software access and enabling PLC password protection and multi-factor authentication for remote OT access
• Deploying ICS-aware monitoring and logging
• Security hardening including disabling unused protocols, web servers and default SNMP strings
• Engaging Siemens Technical Support for model-specific guidance

What preventative actions should organizations take?

1. Treat internet accessibility as the primary risk factor. Any Siemens S7 Series PLC reachable from the internet, directly or through a third-party integrator's remote access path, should be treated as under active threat. Block TCP port 102 at the network perimeter and verify there is no unauthorized routing between corporate and OT networks.
2. Apply firmware updates for your specific device models, prioritizing internet-facing and DMZ-resident controllers and test updates in a non-production environment before deployment.
3. Restrict engineering software access. Limit TIA Portal and STEP 7 access to authorized engineering workstations through MAC/IP allowlisting, enable PLC password protection and available protection levels and require multi-factor authentication for remote access into OT networks. Ensure engineering workstations are up to date with the latest software and security updates.
4. Monitor for the specific indicators the advisory calls out: snap7.dll or python-snap7 library usage outside approved engineering workstations, S7comm connections from non-engineering hosts, IP scanning on TCP port 102 and PUT/GET write operations to data blocks outside scheduled change windows.

Tenable customers can use the Tenable One Exposure Management Platform, including Tenable One OT Exposure, to inventory Siemens S7 Series PLCs and other OT assets and prioritize remediation. Tenable One OT Exposure also provides continuous monitoring of your OT assets to provide deep visibility into your industrial control system networks and associated devices. If any individual Siemens S7 CVEs are confirmed relevant to this campaign, we will update this blog with relevant plugin coverage.

Tenable customers with Tenable Security Center or Tenable One Vulnerability Management can utilize the OT Recon scan policy to identify Siemens and other OT assets.

• CISA Advisory AA26-231A: Defending Against an Active Threat to Siemens S7 Series PLCs
• CISA Advisory AA26-097A: Iranian-Affiliated Cyber Actors Exploit Programmable Logic Controllers Across US Critical Infrastructure
• Tenable Blog: Coordinated "cyberattack" on U.S. water utilities: What you need to know
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• CISA: Secure Connectivity Principles for Operational Technology
• CISA AA22-265A: Control System Defense: Know the Opponent
• Siemens ProductCERT

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Oracle addresses 925 CVEs in its August 2026 Critical Security Patch Update with 943 patches, including 154 critical updates.

1. The August 2026 Critical Security Patch Update (CSPU) contains fixes for 925 unique CVEs in 943 security updates
2. 154 issues (16.3% of all patches) were assigned a critical severity rating
3. Oracle Fusion Middleware received the highest number of patches at 262, accounting for 27.8% of all patches

On August 18, Oracle released its Critical Security Patch Update (CSPU) for August 2026. Beginning in May 2026, Oracle introduced CSPUs as a monthly release cycle that sits between the larger quarterly Critical Patch Updates (CPUs), addressing a focused set of high-severity issues on a faster cadence. This CSPU contains fixes for 925 unique CVEs in 943 security updates across 23 Oracle product families, a nearly fourfold increase in patch volume compared to the June 2026 CSPU, which addressed 243 CVEs in 245 patches across 11 product families.

To put that in context against the quarterly CPUs: the April 2026 CPU contained 481 patches across 241 CVEs, and the July 2026 CPU, the largest CPU release of 2026, contained 1,449 patches across 1,235 CVEs. August's CSPU at 943 patches sits well above the April CPU and represents roughly 65% of July's quarterly volume, a striking figure for what is nominally a targeted between-cycle release. The expansion to 23 product families (up from 11 in June) further blurs the line between CSPU and CPU in terms of scope.

Out of the 943 security updates published, 16.3% of patches were assigned a critical severity. High severity patches accounted for the bulk of security patches at 59%, followed by medium severity patches at 21%.

This month's update includes 154 critical patches across 151 CVEs.

This month's update saw the Oracle Fusion Middleware product family contain the highest number of patches at 262, accounting for 27.8% of the total patches, followed by Oracle Hyperion at 262 patches, which accounted for 27.8% of the total patches.

A full breakdown of the patches for this CSPU can be seen in the following table, which also includes a count of vulnerabilities that can be exploited over a network without authentication.

Patches for all affected products are available in the August 2026 advisory.

A list of Tenable plugins to identify these vulnerabilities will appear here as they're released. This link uses a search filter so that all matching plugin coverage appears as it is released.

• Oracle Critical Security Patch Update Advisory - August 2026
• Oracle August 2026 Critical Security Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect for further discussions on the latest cyber threats.

Learn more about Tenable One, the Exposure Management Platform for the modern attack surface.

Learn how Tenable One Cloud Exposure helps you unmask the sophisticated tactics of cybercrime group Storm-0501, which carries out Azure-based cloud ransomware campaigns. Tenable One Cloud Exposure uses AI-powered threat stories to expose Storm-0501 TTPs, backed by precision-engineered threat detection alerts.

1. Storm-0501 demonstrates that cloud-first ransomware groups have shifted from simple endpoint encryption to the total hijacking of cloud tenants.
2. Storm-0501 systematically neutralizes resource locks, immutability policies, and backups, making the detection of these configuration changes critical for early intervention.
3. Detecting modern campaigns requires moving beyond static rules to a unified threat story that contextually connects the dots across the attack chain.

Historically, ransomware functioned as a localized threat: malicious software infected a workstation or server to encrypt local drives and hold specific host systems hostage. 

Today, sophisticated ransomware actors like Storm-0501 have fundamentally changed the battleground. Instead of relying on local malware execution, they target the cloud control plane itself. They hijack high-privilege administrative identities, weaponize native cloud tools, systematically dismantle defensive barriers, and compromise entire cloud tenants from the inside out. 

Storm-0501, a financially motivated cybercrime group, exemplifies this tactical shift and has repeatedly demonstrated its proficiency in bridging on-premises Active Directory systems with cloud-native Microsoft Entra ID and Azure environments. 

In 2024, Microsoft observed how Storm-0501 began expanding its on-premises ransomware tactics to the cloud, using cloud-native capabilities to evade detection, exfiltrate data, destroy data backups, and demand ransom payments.

This new reality of cloud ransomware demands more than endpoint monitoring; it requires cloud detection and response (CDR). CDR provides full visibility into the attack chain and identifies the surgical techniques employed by adversaries like Storm-0501. 

Driven by deep threat intelligence on Storm-0501's evolving tactics, techniques, and procedures (TTPs), Tenable One Cloud Exposure maps these sophisticated maneuvers to ensure robust protection across the entire attack chain and to extend preemptive exposure management into post-compromise incident response.

Even in scenarios where initial breach access slips past existing security controls, Tenable One's contextual detections empower your defenders to maintain control, trace lateral movement, and neutralize fast-moving attacks before threat actors can seize, encrypt, exfiltrate, and destroy your organization’s critical data. 

In the following video, we demonstrate the CDR capabilities of Tenable One and how it aggregates Azure activity logs into a cohesive threat story, mapping Storm-0501 capabilities directly to the MITRE ATT&CK framework. You will also see the specific detections required to expose and intercept these tactics.

Defenders can immediately use Tenable One’s CDR capabilities, with AI-powered threat stories, to guide surgical containment of a Storm-0501 cloud ransomware campaign. By consolidating fragmented Azure activity logs into a clear chronological timeline, Tenable One eliminates hours of manual log parsing and enables security teams to execute the following containment actions immediately:

• Scope and revoke identities: Use the timeline to identify the initial breach point of an Entra ID Global Administrator role. Immediately terminate all active sessions, revoke refresh tokens, and rotate credentials for the compromised accounts.
• Revert rogue access: Trace role-assignment events in the events explorer dashboard in Tenable One to strip attacker-assigned owner privileges across affected subscriptions and delete any unauthorized persistence accounts or guest users.
• Analyze the blast radius: Investigate additional resources associated with the attacker using the events explorer page.
• Restore defenses: If the alert trail indicates deleted Azure Resource Locks, immutability policies, or Azure Recovery Services vaults, immediately re-apply these defensive barriers to all surviving cloud infrastructure.
• Recover adversary-created keys: If the adversary created an unauthorized Azure Key Vault or encryption scope to lock your storage accounts, revoke adversary access first, then restore the soft-deleted keys, take ownership of the vault, and re-encrypt data under your own keys before the soft-delete window expires.

The campaign orchestrated by Storm-0501 underscores that modern defenders can no longer rely on disparate alerts. They need a unified view that connects the dots. Tenable One’s CDR capabilities provide that clarity, context, and insight, turning attackers’ complex cloud maneuvers into a clear, actionable threat story that empowers organizations to intercept ransomware at the earliest stage possible.

Note: Tenable continuously monitors attacker campaigns and the threat landscape; therefore, additional detection rules will be released to provide an even more comprehensive coverage against this threat actor and others.

Learn more about Tenable One’s CDR capabilities.