Tenable Blog

Why a cryptographic inventory is key for addressing the quantum computing threat

Christopher Day — Fri, 28 Aug 2026 10:01:00 -0400

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.

Key takeaways

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.
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.
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.
Transitioning to quantum-resistant cryptography requires a phased operational strategy spanning discovery, prioritization, remediation, and verification.

The quantum threat to modern security architecture

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.

The impact of Executive Order 14412

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.

The collapse of asymmetric cryptography

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 "harvest now, decrypt later" strategy

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.

Operationalizing the migration: A phased strategy

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.

How can Tenable help?

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 time for action is now

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.

How to build an exposure management program the business trusts: Lessons from Tenable’s CSO

Robert Huber — Thu, 27 Aug 2026 10:30:00 -0400

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.

Key takeaways

Security tool sprawl and data silos make it difficult for CISOs to holistically and accurately assess their organizations’ cyber risk.
An exposure management program consolidates fragmented security data into a single unified view of cyber risk across the entire attack surface.
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

The operational impact of security data silos and tool sprawl

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.

The board’s two core questions about cybersecurity

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}

How siloed security tools create business friction

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.

How AI complicates cyber risk management

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.

The turning point: An acquisition and exposure management

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:

Bob’s simple metrics

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.

Build business trust with exposure management

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

Edge infrastructure under siege: what two independent datasets reveal about who's exploiting your perimeter

Research Special Operations — Wed, 26 Aug 2026 09:00:00 -0400

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.

Key Takeaways

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.
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).
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.
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.
Remediation complexity, particularly of high priority CVEs, leads to a statistically significant 24-day remediation gap, leaving large windows of opportunity for attackers.
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.
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.

The convergence is the story

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:

CVE	Product	Actors (Nexus)	Significance
CVE-2026-15409	SonicWall SMA1000	UTA0533 (unattributed) + INC Ransomware	Espionage-to-ransomware succession on an active zero-day
CVE-2023-42793	JetBrains TeamCity	APT29 (Russia) + Lazarus (DPRK)	Two state-sponsored actors from different nations on the same CVE
CVE-2024-3400	PAN-OS GlobalProtect	UTA0218 (China) + INC Ransomware	China-nexus zero-day reused by ransomware operators
CVE-2024-24919	Check Point Quantum	PurpleHaze (China) + Fox Kitten (Iran)	China and Iran independently exploiting the same gateway vulnerability

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.

Background

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.)

What's exposed: the vulnerability surface

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.

Who exploits what: the threat actor landscape

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).

What incident response sees that telemetry can't

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.

What to do about it

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.

Identifying affected systems

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.

Get more information

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.

Appendix: Methodology and corpus construction

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.

Frequently asked questions about the active threat to Siemens S7 Series PLCs

Research Special Operations — Thu, 20 Aug 2026 10:01:58 -0400

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.

Key Takeaways

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.
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.
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.

Background

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.

FAQ

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:

Series	Variants targeted
S7-200	All CPU variants
S7-300	All CPU variants, including the 314, 315 and 317 models
S7-400	All CPU variants
S7-1200	CPU 1211C, 1212C, 1214C, 1215C and 1217C variants
S7-1500	All CPU variants including F-series safety controllers

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:

Tactic	Technique	ID
Reconnaissance	Scanning services to find exposed PLCs	T1596.005
Resource Development	Developing exploits to target known Siemens S7 Series vulnerabilities	T1587.004
Resource Development	AI-assisted development of exploit code	T1588.007
Lateral Movement	Accessing devices with default or improperly configured credentials	T1694
Execution	Abuse AI-generated Python scripts developed using the snap7.dll library	T0834
Execution	Write operations on data blocks	T0821
Evasion	Masquerading malicious scripts as legitimate monitoring tools	T0849
Collection	Perform reconnaissance by reading controller data	T0893

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?

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.
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.
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.
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.

Identifying affected systems

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.

Get more information

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 August 2026 Critical Security Patch Update Addresses 925 CVEs

Research Special Operations — Tue, 18 Aug 2026 20:41:38 -0400

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

Key Takeaways

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

Background

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.

Severity	Issues Patched	CVEs
Critical	154	151
High	556	541
Medium	198	198
Low	35	35
Total	943	925

Analysis

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.

Oracle Product Family	Number of Patches	Remote Exploit without Auth
Oracle Fusion Middleware	262	182
Oracle Hyperion	262	107
Oracle E-Business Suite	120	27
Oracle Commerce	66	47
Oracle Siebel CRM	50	21
Oracle Supply Chain	46	18
Oracle Virtualization	21	2
Oracle Analytics	16	3
Oracle PeopleSoft	15	7
Oracle Communications	13	9
Oracle Enterprise Manager	11	6
Oracle MySQL	9	5
Oracle Financial Services Applications	8	6
Oracle Autonomous Health Framework	7	2
Oracle Application Testing Suite	7	3
Oracle Database Server	6	4
Oracle JD Edwards	6	2
Oracle Java SE	5	4
Oracle Retail Applications	5	5
Oracle Essbase	4	3
Oracle Food and Beverage Applications	2	2
Oracle Construction and Engineering	1	1
Oracle Hospitality Applications	1	1

Solution

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

Identifying affected systems

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.

Get more information

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.

Detecting cloud ransomware in Azure with Tenable One’s cloud detection and response capabilities

Clément Notin — Mon, 17 Aug 2026 11:15:00 -0400

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.

Key takeaways

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

From ransomware to cloud ransomware

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.

Unmasking Storm-0501 TTPs: A guided walkthrough

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.

From detection to action: Rapid triage and containment

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.

Azure cloud security: How to protect infrastructure against cloud ransomware

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.

The Agentic AI threat cluster: Seven incidents, three actors, and what they mean for your exposure

Research Special Operations — Fri, 14 Aug 2026 21:36:57 -0400

Tenable’s Research Special Operations (RSO) team has been tracking a cluster of agentic AI threat activity since late July 2026. The Taiwan autonomous AI cyber attack confirmed what the cluster data already showed: near-autonomous offensive AI has crossed from theoretical risk to operational reality.

Key Takeaways

Taiwan's Ministry of Digital Affairs confirmed a near-autonomous AI cyber attack in July 2026 in which autonomous agents mapped 21 connected government systems, compromised 85 accounts, and exfiltrated more than 2,564 personnel records in approximately four days.
The Taiwan campaign is part of a broader seven-incident agentic AI threat cluster that also includes JADEPUFFER, which exploited CVE-2025-3248 in the Langflow AI workflow platform for automated database extortion, and knaithe/KnYuan, a Chinese-speaking operator assessed by Unit 42 with moderate confidence, using the same AI agent framework for autonomous vulnerability scanning.
The common entry point across all cluster activity is identity and authentication exposure: discoverable federation endpoints, weak credentials, and misconfigured SSO are the conditions autonomous agents exploit at machine speed, and Tenable One can identify this class of risk in customer environments.

Background

The Taiwan autonomous AI cyber attack, confirmed by Taiwan’s Ministry of Digital Affairs on Aug. 13, 2026, is the highest-profile event in a broader pattern Tenable’s RSO team has been tracking as an intelligence cluster since July 21, 2026. That cluster now encompasses seven confirmed incidents of autonomous or semi-autonomous AI systems deployed for offensive cyber operations or escaping containment boundaries, spanning November 2025 through August 2026.

The Taiwan campaign is the anchor finding, but it is not the whole story. In late July, Palo Alto Networks’ Unit 42 independently documented a separate Chinese-speaking individual operator using the same underlying AI agent framework for autonomous vulnerability scanning. Before either of those events became public, the RSO team was already tracking JADEPUFFER, the first documented agentic threat actor, which exploited an AI workflow platform for initial access and pivoted to database extortion. Three additional agentic AI exploitation incidents emerged during Q1 and Q2 of 2026. And on the defensive side, a confirmed AI sandbox escape incident involving a frontier model demonstrated that autonomous systems can break containment from the inside, not just be weaponized from the outside.

Tenable’s RSO team assesses that these events are not coincidental. They represent two sides of the same exposure condition: autonomous AI systems operating beyond the boundaries their developers intended. This FAQ explains what the cluster contains, what the Taiwan anchor event revealed, and what the cluster reveals about the broader exposure condition.

FAQ

What happened in the Taiwan AI cyber attack?

Between July 1 and July 4, 2026, a suspected China-linked operator ran a four-day intrusion campaign against Taiwanese government infrastructure across 12 distinct attack waves. Starting from a single government portal, autonomous AI agents mapped 21 connected systems, compromised 85 accounts, and exfiltrated more than 2,564 personnel records. The operation then expanded beyond its initial foothold to reach Taiwan’s national nuclear safety agency, seven energy companies, government IT supply chain vendors, and a government email system.

Dream Security's chief strategy officer, Amir Becker, a former member of Israel's Unit 8200, characterized the level of autonomy demonstrated as unprecedented against a government target, according to SecurityAffairs reporting. Taiwan’s Ministry of Digital Affairs confirmed the attack on Aug. 13, 2026, but did not publicly attribute it to a specific state.

How did the AI agents conduct the attack autonomously?

The operator assembled a multi-agent framework from two open-source AI agent projects, Hermes Agent and OpenClaw, and added Bayesian decision engines capable of coordinating up to eight parallel sub-agents per attack wave. Rather than following a fixed script, the agents scraped the government portal's publicly accessible authentication metadata: the federated sign-on endpoints, service identifiers, and identity-provider configuration that interconnected web applications routinely expose, then used what they found to independently discover and map the 21 connected systems behind it. In what Dream Security described as a fully autonomous decision, the agents followed a URL from the portal's JavaScript bundles to a GitBook documentation site hosting the national SSO integration guide, scraped the documentation using GitBook's built-in content features, and downloaded two SDK integration projects. Dream's analysis notes that while the agents ran automated code review on the SDK samples, none of those findings produced confirmed exploits. The actual breaches came from server-side flaws discoverable through standard black-box testing.

To acquire credentials, the agents generated password variations based on employee identifiers and automatically solved CAPTCHA challenges through optical character recognition, compromising 85 accounts without a human operator manually testing each one. The agents also bypassed their own AI safety guardrails by reframing the offensive operation as “authorized penetration testing,” a novel prompt-based technique with no current mapping in the MITRE ATT&CK framework. Throughout the operation, the agents pulled exploitation techniques from public vulnerability databases and GitHub in real time rather than relying on a pre-loaded set of exploits, a pattern Tenable’s RSO team assesses as genuine adaptive behavior rather than simple scripted branching.

Did the attackers exploit a specific vulnerability or zero-day?

No single classifiable Common Vulnerabilities and Exposures (CVE) entry drove this campaign. Instead, the AI agents dynamically identified and abused misconfigurations, exposed administrative interfaces, and weak credentials already present in the target environment, sourcing exploitation techniques from public databases as they went. Tenable’s RSO team regards this absence as analytically significant: it demonstrates an attack category that a purely CVE-centric defensive model cannot fully address, because the exposure is the target’s entire discoverable attack surface rather than one known vulnerability.

Who was behind the attack?

Dream Security's linguistic analysis of the recovered 160MB archive found that internal operator communications were in Simplified Chinese while the exfiltrated government data was in Traditional Chinese. The targeting sequence (government portal, then nuclear safety agency, then energy sector) also aligns with previously documented Chinese strategic intelligence collection priorities against Taiwan.

Attribution currently rests on a single primary source. Dream Security is the sole entity that has published technical and linguistic analysis of the archive, and no second vendor has yet corroborated a link to a specific Chinese state entity. Tenable’s RSO team evaluated three competing attribution hypotheses (state-sponsored, state-adjacent contractor, and false flag) and assesses a state-adjacent contractor or patriotic hacker origin as the leading explanation, with state sponsorship as a close runner-up that cannot be excluded.

What is the connection to the Unit 42 findings on knaithe/KnYuan?

On July 30, 2026, roughly two weeks before the Taiwan campaign became public, Unit 42 published research on a separate Chinese-speaking individual operator tracked as knaithe (also known as KnYuan), assessed with moderate confidence as operating out of Zhuhai, China. Unit 42 discovered the actor after a misconfigured Hermes Agent instance accidentally exposed the actor's full operational workspace. Unit 42's report details the exposed contents: tool configurations, API credentials, exploit scripts, target lists, and session logs from autonomous exploitation runs.

Knaithe/KnYuan used Hermes Agent paired with the DeepSeek reasoning model to run autonomous vulnerability-scanning campaigns against Langflow and n8n instances, and separately achieved confirmed data exfiltration from three Citrix NetScaler targets and command execution on 11 Marimo Notebook endpoints through manual exploitation. The actor has no known connection to the Taiwan operator, but the two cases share the same underlying framework and demonstrate that autonomous AI offensive capability is not confined to a single well-resourced group.

An individual operator, working alone, independently built comparable tooling, evidence the RSO team views as confirmation that the barrier to entry for this class of attack is collapsing.

What is the broader agentic AI threat cluster?

The Taiwan campaign is the most visible event, but Tenable’s RSO team is tracking it as one node in a cluster of seven confirmed incidents. The cluster includes three categories of activity.

First, offensive weaponization: the Taiwan campaign operator, the knaithe/KnYuan autonomous scanning operation, and JADEPUFFER, the first documented agentic threat actor tracked by the RSO team, which demonstrated agentic AI capability by exploiting Langflow and pivoting to database extortion before either the Taiwan or Unit 42 reports were published. Security vendors documented three additional early-stage agentic exploitation incidents during Q1 and Q2 of 2026.

Second, defensive AI escape: a confirmed sandbox escape by a frontier AI model during legitimate safety testing demonstrated that advanced AI systems can independently breach their containment boundaries without any adversary involvement. Other AI laboratories have reported similar incidents, reinforcing the pattern.

The RSO team treats these as a single analytical cluster because they share the same root exposure condition: autonomous AI systems acting beyond the boundaries their operators intended. Whether the system was weaponized by an attacker or broke out during legitimate use, the downstream risk to organizations is the same, systems they assumed were controlled were not. This is why the RSO team classifies the open-source AI agent framework weaponization pattern and the broader AI governance gap as distinct exposure conditions tracked under the same cluster umbrella.

What makes this different from previous AI-assisted cyber attacks?

The individual Taiwan campaign is significant on its own terms, but the cluster pattern is what changes how organizations need to think about risk. Earlier AI-assisted intrusions used AI to accelerate a specific step, such as writing phishing content or triaging scan output, while a human operator directed the overall operation. The Taiwan campaign compressed reconnaissance, credential attacks, and lateral expansion into a continuous, largely self-directed sequence: the agents chose which systems to map, which techniques to pull from public sources, and when to expand into new sectors, all without step-by-step human direction. Kevin Surace, CEO of TokenCore, described the operation as “near-autonomous rather than completely independent,” adding that "humans still selected the targets, defined the objectives, assembled the framework, and reportedly persuaded the underlying model that the operation was an authorized security test." Tenable’s RSO team adopts the same “near-autonomous” framing.

What elevates this beyond a single incident is the convergence the cluster reveals. Two unrelated actors independently adopted the same framework. A third actor (JADEPUFFER) demonstrated agentic capability through a different operational pattern. AI systems escaped containment without adversary involvement. The barrier to entry collapsed far enough that a solo operator in Zhuhai built comparable tooling to what was used against a national government. As Trey Ford observed, this is “not the first AI-driven government attack,” but rather “the first one we’ve heard about.” The cluster data suggests he is right.

What does the tradecraft analysis reveal about how these attacks actually work?

Tenable’s RSO team conducted structured tradecraft profiling across all three actors and the anchor campaign to understand how agentic AI attacks compare to conventional intrusions at the operational level. Four findings stand out.

First, agentic AI tradecraft is additive, not transformative. The innovation in this cluster is concentrated in one dimension: the use of AI agents as the execution engine. Everything else, the command-and-control infrastructure, the initial access vectors, the operational security practices, remains at commodity levels. The Taiwan operator’s AI agents autonomously mapped 21 systems and compromised 85 accounts, but the underlying techniques they used (credential brute force against weak passwords, abuse of discoverable OAuth and Keycloak metadata, exploitation of publicly known vulnerabilities) are familiar. What changed is the speed, parallelism, and self-direction with which those techniques were applied. For defenders, this means the kill chain itself has not fundamentally changed. What has changed is the tempo at which an attacker can execute it.

Second, the convergence across unrelated actors is not coincidental, and the tradecraft data confirms it. When the RSO team compared the operational profiles of the Taiwan operator, knaithe/KnYuan, and JADEPUFFER, all three produced strikingly similar capability levels despite having no organizational relationship, shared training, or common infrastructure. The similarity is structural: the same freely available open-source tools (Hermes Agent, OpenClaw, DeepSeek) impose a common operational template on anyone who uses them. This is the clearest evidence that the barrier to autonomous AI offensive capability has collapsed. The tools define the tradecraft, and the tools are available to everyone.

Third, these actors are not living off the land. The RSO team estimates the substantial majority of the observed tradecraft in this cluster was AI-agent-driven rather than reliant on the target environment’s native tools. The small portion that did leverage target infrastructure involved abusing the inherent discoverability of federated authentication systems (OAuth discovery endpoints, OpenID Connect metadata, Keycloak realm configurations). This matters for detection strategy: catching agentic AI intrusions requires a different detection model than living-off-the-land indicators that flag conventional APT activity. The detection focus can be on execution-layer anomalies, specifically the behavioral signatures of AI-driven reconnaissance, automated credential campaigns, and parallel multi-target scanning.

Fourth, the speed of adaptation compresses the defender’s window to near zero. In the JADEPUFFER campaign documented by Sysdig, an AI agent diagnosed a failed credential insertion, identified the cause as a missing runtime dependency in the execution environment, and issued a corrective multi-step payload within 31 seconds. Traditional incident response timelines assume minutes to hours between attacker actions. Agentic AI eliminates that breathing room. Every exposed credential, every misconfigured authentication endpoint, every unpatched service will be found and will be exploited at machine speed. The window between exposure and compromise is collapsing, which makes foundational cyber hygiene (patching, hardening, reducing the discoverable attack surface) more urgent than it has ever been, not less.

How does this affect organizations deploying AI agents?

The attack surface the Taiwan agents exploited is not specific to Taiwanese government infrastructure. Any organization running interconnected web applications with centralized authentication (OAuth or OpenID Connect federation, SAML providers, or Keycloak deployments) exposes the same category of discoverable metadata the Taiwan operator's agents used to map 21 systems from a single entry point. The methodology is geography-agnostic: the agents require only one foothold and self-discover everything else.

The Taiwan agents also autonomously discovered and scraped a GitBook documentation portal hosting the national SSO integration guide, using GitBook's built-in content features to download SDK integration samples. Organizations that host developer documentation, API guides, or integration resources on publicly accessible platforms treat that content as part of the discoverable attack surface: autonomous agents will find it.

Separately, organizations that deploy their own AI agents face an additional governance exposure. Industry survey data from Kiteworks indicates that 63% of organizations cannot enforce purpose limitations on the AI agents they deploy, 60% cannot quickly terminate a misbehaving agent, and 55% cannot isolate AI systems from broader network access. The Cybersecurity and Infrastructure Security Agency (CISA) and Five Eyes partners published joint guidance titled "Careful Adoption of Agentic AI Services" in May 2026, identifying privilege escalation, design and configuration failures, behavioral misalignment, structural brittleness, and accountability gaps as the core risk categories. These are two distinct exposure categories: being targeted by AI agents and governing your own, but both require action now.

What can organizations do to protect themselves?

This campaign is a forcing function to address two distinct exposure categories. First, the identity and authentication weaknesses the Taiwan attacker actually exploited (exposed discovery endpoints, weak credentials, and misconfigured federation) exist in most enterprise environments today and are exactly the kind of foothold agentic AI will find at machine speed. Second, organizations deploying their own AI agents face the governance gaps Kiteworks documented: if you cannot enforce purpose limitations or terminate a misbehaving agent, you share the same structural vulnerability from the inside. Neither category has a single patch. Both require architectural and operational changes.

Audit public-facing authentication surfaces for information disclosure. Review OAuth, OpenID Connect discovery endpoints, and Keycloak realm configurations for unnecessary public exposure, since the Taiwan operator’s entire ecosystem map originated from data these interfaces exposed voluntarily. The Taiwan agents autonomously discovered a GitBook documentation portal hosting the national SSO integration guide, scraped it, and downloaded SDK integration samples, all from a single URL embedded in the portal's JavaScript. Publicly accessible developer documentation, integration guides, and SDK samples are part of the discoverable attack surface that agentic AI will find.
Deploy behavioral detection for automated reconnaissance and credential attacks, including quick sequential API enumeration, mass credential testing paired with CAPTCHA solve-and-retry patterns, and parallel scanning of multiple connected systems within minutes of an initial compromise. Indicator-based detection alone is insufficient because autonomous AI agent traffic closely resembles legitimate security testing.
Reduce the discoverable attack surface. The Taiwan agents built their entire operation from information the target environment volunteered: authentication metadata, API endpoints, developer documentation, and SDK integration guides hosted on publicly accessible platforms. Audit what internet-facing applications expose through JavaScript bundles, discovery endpoints, documentation portals, and integration resources. If it helps a legitimate developer integrate, it helps an autonomous agent map your environment.
Close the purpose-limitation and kill-switch gap identified by Kiteworks. Organizations that cannot quickly terminate a misbehaving AI agent or restrict what it is authorized to do are exposed to the same category of risk the Taiwan attack demonstrated, independent of any single vulnerability.

Organizations running Citrix NetScaler, Marimo Notebook, Langflow, n8n, Apache Tomcat, PAN-OS, or Windows IKE VPN, the platforms targeted in the related knaithe/KnYuan campaign, can check patch status via the CVE links in the Product Coverage section below. Manual exploitation following autonomous reconnaissance has already produced confirmed data exfiltration and command execution against unpatched instances of some of these products.

Has Tenable released any product coverage for these threats?

Tenable customers can use the Tenable One Exposure Management Platform to assess their exposure to this threat cluster across three dimensions. Tenable One Attack Surface Management helps identify internet-facing authentication surfaces, OAuth and OpenID Connect discovery endpoints, and exposed AI agent framework instances before an adversary finds them. Tenable One Identity Exposure helps organizations surface the excessive privileges, weak credential patterns, and misconfigured single sign-on integrations that AI agents in this campaign exploited without needing a single CVE. Tenable One Vulnerability Management provides coverage for the known vulnerabilities exploited in the related knaithe/KnYuan campaign, including:

CVE-2026-33017 (Langflow)
CVE-2026-3055 (Citrix NetScaler)
CVE-2026-39987 (Marimo Notebook)
CVE-2026-34486 (Apache Tomcat)
CVE-2026-21858 (n8n)
CVE-2025-68613 (n8n)
CVE-2026-0300 (PAN-OS)
CVE-2026-33824 (Windows IKE VPN)

These links will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

JADEPUFFER, a separate actor in the same cluster, exploited an earlier Langflow vulnerability (CVE-2025-3248) in its database extortion campaign. Tenable plugin coverage for that CVE is also available.

During the autonomous SDK code review phase, the agents also identified a Cross-Site Request Forgery weakness in the portal’s SSO integration. CSRF was not among the confirmed breach vectors in this campaign (the actual compromises came from server-side authentication flaws), but Tenable One Web App Scanning can identify this class of vulnerability in customer-facing portals with federated authentication:

What does this mean for the future of cybersecurity?

Tenable’s RSO team is actively monitoring seven indicators tied to this cluster. The four forecasts in our internal assessment deserve public summary.

First, framework proliferation: the RSO team assesses with moderate confidence that additional actors across multiple capability tiers will adopt autonomous AI attack methodologies within the next six to 12 months. Two distinct actors already built comparable capability independently, and the open-source tools they used remain freely available under permissive licenses.

Second, target expansion: the methodology is geography-agnostic. The AI agents require only a single entry point and self-discover everything else. The RSO team assesses that the same or similar frameworks will likely appear against non-Taiwan targets within three to six months, a timeline the knaithe/KnYuan discovery (which predated the Taiwan disclosure) already suggests is conservative.

Third, regulatory acceleration: the Taiwan incident provides concrete evidence for regulatory bodies that were already moving on agentic AI governance. The RSO team assesses that CISA or an equivalent Five Eyes agency will likely issue additional agentic AI guidance within three months, building on the joint guidance published in May 2026.

Fourth, defensive AI containment failures will continue. The sandbox escape incident tracked as FIND-020 and similar events at other AI laboratories are not anomalies. As AI models grow more capable, organizations face a dual-axis threat: offensive weaponization by adversaries from the outside and defensive containment failure from the inside. Both vectors converge on the same exposure: autonomous systems operating beyond the boundaries organizations assume they control.

The RSO team will continue to track this cluster and publish updates as monitoring indicators are triggered. Organizations that treat the Taiwan event as an isolated incident rather than a pattern will find themselves behind the curve when the next data point arrives.

Get more information

Tenable One Exposure Management Platform
CISA and Five Eyes - "Careful Adoption of Agentic AI Services" (May 2026)
Unit 42 - “Chinese-Speaking Threat Actor Harnesses AI Models” (July 30, 2026)
Dream Security - “Inside a Multi-Agent AI Framework Used to Compromise Government Entities in Asia” (Aug. 12, 2026)
Sysdig TRT - “JADEPUFFER: Agentic Ransomware for Automated Database Extortion” (July 1, 2026)
Taiwan Ministry of Digital Affairs - official confirmation (English Translation) (Aug. 13, 2026)
Tenable Vulnerability Watch - authoritative vulnerability classification

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

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

Microsoft's August 2026 Patch Tuesday addresses 398 CVEs (CVE-2026-68820)

Research Special Operations — Tue, 11 Aug 2026 14:04:04 -0400

42Critical
355Important
1Moderate
0Low

Microsoft addresses 398 CVEs in the eighth Patch Tuesday of 2026, with three zero-days, including one that was exploited in the wild.

Microsoft patched 398 CVEs in its August 2026 Patch Tuesday release, with 42 rated critical, 355 rated as important and one rated as moderate. Our counts omitted two CVEs assigned by MITRE; CVE-2026-6726 and CVE-2026-6727.

This month’s update includes patches for:

.NET
.NET Core
.NET Framework
AMD Zen
Active Directory Certificate Services (AD CS)
Application Information Services
Azure Active Directory
Azure CycleCloud
Azure Monitor Agent
Azure Storage Explorer
Capability Access Management Service (camsvc)
Desktop Window Manager
Dynamics Business Central
GitHub Copilot and Visual Studio Code
Microsoft Azure Attestation service and Device Health Attestation Service
Microsoft COM for Windows
Microsoft Defender for Endpoint
Microsoft Digest Authentication
Microsoft Dynamics 365 (on-premises)
Microsoft Entra Connect Sync
Microsoft Exchange Server
Microsoft High Performance Computing (HPC) Pack
Microsoft Identity Services
Microsoft Local Security Authority Server (lsasrv)
Microsoft Office
Microsoft Office Access
Microsoft Office Excel
Microsoft Office Graphics Component
Microsoft Office Outlook
Microsoft Office PowerPoint
Microsoft Office SharePoint
Microsoft Office Word
Microsoft OneDrive
Microsoft PowerShell
Microsoft PowerShell Core
Microsoft QUIC
Microsoft Remote Registry Service
Microsoft Teams Mobile
Microsoft Teams for Android
Microsoft Windows Codecs Library
Microsoft Windows Media Foundation
Microsoft Windows Search Component
Power BI
RPC Runtime
Reliable Multicast Transport Driver (RMCAST)
Remote Desktop Client
User-Mode Power Service (UMPS)
Virtual Hard Disk (VHD) Miniport Driver
Visual Studio Code
Visual Studio Code - Python extension
Visual Studio Code CoPilot Chat Extension
Windows Accessibility Infrastructure (ATBroker.exe)
Windows Active Directory
Windows Ancillary Function Driver for WinSock
Windows Autopilot
Windows Backup Engine
Windows Bind Filter Driver
Windows Cloud Files Mini Filter Driver
Windows Common Log File System Driver
Windows Container Isolation FS Filter Driver (unionfs.sys)
Windows Cross Device Service
Windows DHCP Client
Windows DHCP Server
Windows DNS
Windows DWM Core Library
Windows Defender Firewall Service
Windows Deployment Services
Windows Device Association Service
Windows Display Enhancement Service
Windows Encrypting File System (EFS)
Windows Event Logging Service
Windows GDI
Windows GDI+
Windows Graphics Kernel
Windows HTTP Protocol Stack
Windows HTTP.sys
Windows Hello
Windows Hyper-V
Windows Imaging Component
Windows Installer
Windows Kerberos
Windows Kernel
Windows Key Guard
Windows LDAP - Lightweight Directory Access Protocol
Windows LUAFV
Windows License Manager
Windows MIDI Service Module
Windows Management Instrumentation
Windows Management Services
Windows Message Queuing
Windows Modern Device Management (MDM)
Windows NTFS
Windows Narrator Braille
Windows Network Address Translation (NAT)
Windows Network Connection Broker
Windows Network File System
Windows Package Manager
Windows Program Compatibility Assistant Service
Windows Projected File System
Windows Push Notifications
Windows RPC API
Windows Remote Access API
Windows Remote Access Connection Manager
Windows Remote Desktop Services
Windows Remote Help
Windows Remote Help Defense
Windows Routing and Remote Access Service (RRAS)
Windows SMB Client
Windows SMB Server
Windows Schannel
Windows Secure Socket Tunneling Protocol (SSTP)
Windows Sensor Data Service
Windows Shell
Windows Storage
Windows Storage Port Driver
Windows TCP/IP
Windows Telephony Service
Windows USB Driver
Windows Universal Disk Format File System Driver (UDFS)
Windows User Profile Service
Windows Win32K
Windows Wired AutoConfig Service
Windows Work Folder Service
Windows iSCSI Target Service
Winlogon

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

Important

CVE-2026-68820 | Windows Ancillary Function Driver for WinSock elevation of privilege vulnerability

CVE-2026-68820 is an EoP vulnerability affecting Windows Ancillary Function Driver for WinSock. It received a CVSSv3 score of 7.0 and was rated as important. A local attacker could exploit this vulnerability to elevate to SYSTEM privileges. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

Two additional EoP vulnerabilities affecting this driver were patched this month. CVE-2026-61348 and CVE-2026-70307 also received CVSSv3 scores of 7.0, however no exploitation has been reported for these flaws. Both were assessed as "Exploitation More Likely" according to Microsoft's Exploitability Index.

Prior zero-days in this driver include CVE-2025-32709 in May 2025, CVE-2025-21418 in February 2025, and CVE-2024-38193 in August 2024.

Important

CVE-2026-62832 | Windows User Profile Service elevation of privilege vulnerability

CVE-2026-62832 is an elevation of privilege vulnerability affecting Windows User Profile Service. It received a CVSSv3 score of 7.8 and is rated as important. A local attacker could exploit this vulnerability to gain ADMINISTRATOR privileges. It was publicly disclosed prior to a patch being available and was assessed as “Exploitation More Likely.”

Historically, the Windows User Profile Service has received four total CVEs since January 2022. Prior zero-days in this family include CVE-2022-21919 in January 2022 and CVE-2022-26904 in April 2022.

Important

CVE-2026-72971 | Windows Container Isolation FS Filter Driver (unionfs.sys) tampering vulnerability

CVE-2026-72971 is a tampering vulnerability affecting the Windows Container Isolation FS Filter Driver (unionfs.sys). It received a CVSSv3 score of 5.5 and is rated as important. It was publicly disclosed prior to a patch being available. Successful exploitation would allow a local attacker to perform tampering. Despite being publicly disclosed, Microsoft assesses this vulnerability as “Exploitation Unlikely.”

Critical

CVE-2026-62893 | Windows Deployment Services TFTP Server remote code execution vulnerability

CVE-2026-62893 is a remote code execution vulnerability affecting Windows Deployment Services Trivial File Transfer Protocol (TFTP) Server. It received a CVSSv3 score of 9.8 and is rated as critical. It was assessed as "Exploitation More Likely." Successful exploitation of this flaw could occur when a remote, unauthenticated attacker sends crafted packets to a vulnerable service, resulting in code execution. It was reported to Microsoft by Nikolai Skliarenko of TrendAI Research.

Critical

CVE-2026-62823 | Windows DHCP Server remote code execution vulnerability

CVE-2026-62823 is a remote code execution vulnerability affecting Windows DHCP Server. It received a CVSSv3 score of 8.8 and is rated as critical. It was assessed as "Exploitation More Likely" according to Microsoft's Exploitability Index. Successful exploitation would allow a remote, unauthenticated attacker to execute code over an adjacent network by exploiting a heap-based buffer overflow flaw using a crafted packet.

13 additional Windows DHCP server vulnerabilities were patched this month, however these flaws were only rated as important. The flaws include eight information disclosure vulnerabilities with CVSSv3 scores of 6.5 (CVE-2026-62714, CVE-2026-62715, CVE-2026-62716, CVE-2026-62718, CVE-2026-62720, CVE-2026-62742, CVE-2026-62745 and CVE-2026-62814) and five EoP vulnerabilities with CVSSv3 scores of 7.8 (CVE-2026-62761, CVE-2026-62776, CVE-2026-62803, CVE-2026-62807 and CVE-2026-62812).

Critical

Multiple CVEs | Microsoft Office SharePoint spoofing, remote code execution, elevation of privilege, information disclosure and tampering vulnerabilities

This month's update includes patches for 29 CVEs affecting Microsoft Office SharePoint. Of the 29 CVEs, three were rated as critical and three were assessed as 'Exploitation More Likely.' A breakdown of the CVEs can be found in the table below:

CVE	Description	CVSSv3	Severity	Exploitability Index
CVE-2026-70306	Microsoft Office SharePoint Spoofing	9.3	Important	Exploitation Less Likely
CVE-2026-62827	Microsoft SharePoint Server Elevation of Privilege	8.8	Critical	Exploitation Less Likely
CVE-2026-65665	Microsoft SharePoint Server Remote Code Execution	8.8	Critical	Exploitation More Likely
CVE-2026-64921	Microsoft SharePoint Server Elevation of Privilege	8.8	Critical	Exploitation Less Likely
CVE-2026-63514	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-64901	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-65658	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-65663	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-66805	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-66808	Microsoft SharePoint Server Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-70321	Microsoft SharePoint Remote Code Execution	8.8	Important	Exploitation Less Likely
CVE-2026-70324	Microsoft SharePoint Elevation of Privilege	8.8	Important	Exploitation Less Likely
CVE-2026-70326	Microsoft SharePoint Server Elevation of Privilege	8.8	Important	Exploitation Less Likely
CVE-2026-63520	Microsoft SharePoint Server Remote Code Execution	8.1	Important	Exploitation More Likely
CVE-2026-57105	Microsoft Office SharePoint Spoofing	8.0	Important	Exploitation Less Likely
CVE-2026-70355	Microsoft SharePoint Server Elevation of Privilege	7.3	Important	Exploitation More Likely
CVE-2026-58639	Microsoft SharePoint Server Spoofing	6.5	Important	Exploitation Less Likely
CVE-2026-62837	Microsoft SharePoint Server Information Disclosure	6.5	Important	Exploitation Less Likely
CVE-2026-62839	Microsoft SharePoint Server Spoofing	6.5	Important	Exploitation Less Likely
CVE-2026-63512	Microsoft SharePoint Server Tampering	6.5	Important	Exploitation Less Likely
CVE-2026-63516	Microsoft SharePoint Server Spoofing	6.5	Important	Exploitation Less Likely
CVE-2026-65660	Microsoft SharePoint Server Spoofing	6.5	Important	Exploitation Less Likely
CVE-2026-62829	Microsoft SharePoint Server Spoofing	4.6	Important	Exploitation Less Likely
CVE-2026-62917	Microsoft SharePoint Server Spoofing	4.6	Important	Exploitation Less Likely
CVE-2026-64897	Microsoft SharePoint Server Spoofing	4.6	Important	Exploitation Less Likely
CVE-2026-64922	Microsoft SharePoint Server Spoofing	4.6	Important	Exploitation Less Likely
CVE-2026-64900	Microsoft SharePoint Server Spoofing	7.3	Important	N/A
CVE-2026-64902	Microsoft SharePoint Server Spoofing	4.6	Important	N/A
CVE-2026-64916	Microsoft SharePoint Server Spoofing	4.6	Important	Exploitation Unlikely

Tenable solutions

A list of all the plugins released for Microsoft's August 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.

Get more information

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.

Agentic AI for cyber defenders: What security teams built at Black Hat USA 2026

Nick Hayes — Fri, 07 Aug 2026 08:00:00 -0400

Agentic AI armed attackers first, but it also put real building power in defenders’ hands. Here’s what security practitioners built in two days at Black Hat USA 2026, and how the CyberAgents Exchange keeps that work compounding long after the event.

Key takeaways

Building defensive cybersecurity tooling no longer requires a developer. Agentic tooling drove the cost of finding and exploiting a vulnerability down to 1990s levels; it also removed the engineering barrier that kept defenders from building the automation they’ve always wanted.
The unglamorous work won the room: triage, reconciliation, toil. Given two days and a requirement to publish, practitioners at SWARM developed agents for prioritization, cross-tool reconciliation, and the unglamorous toil they recognize from their own environments.
All SWARM builds live on the CyberAgents Exchange, source repos attached. Every component built at SWARM is published open source with its source repository attached, so the next team facing the same problem starts from working code instead of a blank editor.

Another security team already built the AI agent you need

You may not realize it, but somewhere out in the ether, there’s a security team facing the same challenge as you. The only difference is they just solved the problem with agentic AI. The problem is, you have no way to find out the solution even exists.

It could be an asset inventory that three systems describe in three different ways; a findings queue nobody has the hours to work; or a “critical” that a platform upgrade quietly neutralized six months ago, still sitting there waiting for someone to prove it. Somebody has already built the thing you keep meaning to build. Now it’s time we help you find it.

At Black Hat USA 2026, nearly 100 registrants had the opportunity to come together for 48 hours and solve both halves of that problem: identifying a key operational pain point and building the fix.

Problems like those got solved at SWARM, and the fixes are sitting on the CyberAgents Exchange right now, open source, with their source repositories attached.

One team built the agent that works out which handful of fixes retires the most risk across thousands of findings. Another correlated two scanners to tell whether a flaw in the code is even reachable in the running application. A third made the case that a finding had already been mitigated, with evidence an auditor would accept. You can download and deploy any of them today.

Agentic AI doesn’t just arm attackers

Black Hat’s keynote stage spent this year focused on one theme: the plummeting cost of cyber offense in the agentic AI era. The price for an attacker to find and exploit a vulnerability is at lows the industry hasn’t seen since the 1990s, when a working exploit meant weeks of expert reverse engineering. Now all it takes is an afternoon and a subscription.

The artisanal exploit isn’t rare anymore. True. But neither is the defender who can build.

The same agentic tooling that’s arming attackers puts real building power in everyone’s hands, and that half of the story got almost no airtime. Security automation used to require the work and ongoing maintenance of skilled engineers. Now practitioners who understand the problem can build the fix.

Inside the conference room at the Mandalay Bay where Tenable hosted our inaugural SWARM event, the proof of that was on every table. The winning ranking engine ships as a skill that runs on the Python standard library alone — no packages, no install step, no build pipeline. Point it at the bundled demo estate and it answers “what should we fix first?” in seconds. That’s a deliverable a practitioner can produce and a colleague can run, and two days was enough.

The attacker-defender asymmetry doesn’t stem from a lack of talent or willingness. Offensive cyber capabilities compound because the tooling circulates: it’s built once, forked, passed on, or sold to the next threat actor to leverage in their attack.

Meanwhile, defenders continue to build in silos, with hundreds of teams solving the same fix for the same problem. Not because anyone wants to keep it to themselves, but because there’s never been an easy way to pass it along. Defensive cyber tools are built, then lost, then rebuilt somewhere else. That’s a distribution gap, and now defenders can close it themselves on the CyberAgents Exchange.

We gave defenders a mission and two days to build

Tenable hosted its first SWARM event, running alongside Black Hat, so practitioners could come together and build open-source agentic AI. Sponsored by AWS and with technical staff from Anthropic onsite for judging, SWARM came with a couple simple rules: build something practical that solves a real problem for your team, and publish it to the CyberAgents Exchange.

Then we got out of the way, and the magic immediately took shape.

Practitioners built AI agents for Monday morning, not for the demo

The room skewed hard toward unglamorous work. Not autonomous red teams or self-healing networks, but the specific tasks that eat a practitioner’s week: reconciling asset inventories that three systems disagree about, triaging a findings queue nobody has time for, chasing down whether a finding is even real before someone spends a sprint on it.

One team built an agent that reads vendor advisories and mitigation notes, compares them against live findings, and recommends risk recasts — the kind of work a senior engineer does by hand, one CVE at a time, and never gets credit for. They built the thing that was annoying them last Tuesday.

Defenders didn’t build robot analysts, they built plumbing

The most common thing in the room wasn’t a flashy autonomous agent. It was connective tissue: capabilities to normalize findings across scanners that describe the same asset three different ways, wrap the tools that teams already own so an agent can reach them, and package recurring analyst tasks as reusable skills instead of one-off scripts.

That tracks with how this technology actually gets adopted. Nobody rips out their stack to adopt agentic AI. They teach an agent to drive what’s already there, and the integration layer is where the real work sits.

The agentic AI builds the judges put on the podium

Three teams took the podium. None of their work stayed in the room: every build had to ship to the CyberAgents Exchange as open source to be eligible to win, so the shortlist below is a set of tools you can read and run tonight. The judges — Tenable CSO Robert Huber, AWS Security Specialist SA Leader Chris Elmore, and a member of Anthropic’s technical staff — scored impact above everything else, and all three solve problems you probably recognize.

First place: from thousands of findings to a handful of proven fixes

Chokepoint Finder

Built by Team Vauban; MIT licensed

Security teams don’t have a detection problem, they have a selection problem: a mid-size estate carries thousands of open findings and capacity for maybe 10 changes a week. Published as four agentic components—an agent, MCP server, skill, and playbook—Chokepoint Finder ranks fixes, not findings. It groups findings by the single action that resolves them (i.e., patches, base images, IAM roles, security groups, etc.) then solves for the shortest ordered list that mitigates the most weighted risk, leveraging its playbook to agentically inspect and rank fixes over eight distinct stages, with a human decision in the middle.

That discipline earned the top spot. The agent holds no write credentials, evidence it can’t read or can’t date resolves to a hold, and a re-scan has to prove the risk moved before the record closes. The team’s week stops being an unmanageable queue, collapsing its demo estate with 3,734 synthetic findings across 783 assets into seven concrete remediation actions. Each member of Team Vauban took home $2,000 in Anthropic credits, an AWS specialist certification voucher, and a gold-border SWARM patch.

2nd Place: determine if flaws in code are reachable

ThreatCorraling

by Team ShellCodeandChill; MIT licensed

A team running two scanners has two lists and no shared view: the code scanner flags a flaw, the application scanner watches the running app, and nobody can say whether the flaw is reachable. ThreatCorraling correlates Checkmarx static analysis results against Tenable Web Application Scanning findings for the same scoped assets, so a team can tell which flagged flaws are actually exposed in production.

From there it maps what it finds to SOC 2 and ISO 27001 controls and generates remediation and regression-testing patterns specific to the team’s stack, rather than generic advice. The reconciliation spreadsheet becomes a ranked, control-mapped list. It ships as both halves of the same code: a local app, and an MCP server exposing the same tools to clients like Claude Code. Each member of Team ShellCodeandChill took home $1,500 in Anthropic credits, an AWS specialist certification voucher, and a silver-border SWARM patch.

3rd place: prove if findings were already mitigated

Evidence-Backed Vulnerability Investigator

by Team ZeroSignal; MIT licensed

Arguing that a finding was already mitigated usually means an analyst has to rebuild the case from memory with no traceable record of why. The Evidence-Backed Vulnerability Investigator loads scanner findings, matches them against the vendor advisories a team already keeps on disk, and asks Claude for a disposition with detailed justification evidence.

The matching is deterministic, performed by an identifier and keyword scoring script so analysts can reliably see why advisories are returned, and only the human’s decision gets recorded. The disposition arrives with its evidence attached instead of as an assertion. Anyone who’s argued with an auditor about a “critical” upgrade that’s quietly fixed knows what that saves. Each member of Team ZeroSignal took home $1,000 in Anthropic credits, an AWS specialist certification voucher, and a bronze-border SWARM patch.

Congratulations to the winners!

Congratulations to all three teams, and to everyone who shipped something in 48 hours and put their name on it in public. That takes more nerve than a demo. One SWARM participant walked out with an NVIDIA DGX Spark, drawn from raffle tickets every ceremony attendee earned just by being in the room.

SWARM was two days, the CyberAgents Exchange lives on

Every component built at SWARM is now on the CyberAgents Exchange, under open licenses, and that’s the whole point. The work gets done once. Take two days of work from a few dozen practitioners, then multiply it by a community publishing continuously instead of once at a hackathon, and you get the two things threat actors have always had that defenders haven’t: scale and distribution.

What is the CyberAgents Exchange?

The CyberAgents Exchange is the industry’s first open-source, vendor agnostic AI agent exchange, a cybersecurity-native registry for AI agents, skills, MCP servers, and multi-agent playbooks. It’s built around the objection practitioners actually have to agentic AI, and that objection was never automation. It’s opacity. You can’t responsibly hand production authority to something whose reasoning and provenance you can’t inspect. That isn’t blind distrust; it’s justifiable caution.

So every component links to its source repository. No bundled binaries. You can see who built it, when, and whether it’s been reviewed by Tenable, vetted by the community, or if it was freshly submitted. You set your own trust threshold before you run anything. The CyberAgents Exchange is free: there are no fees to list or use what’s there. SentinelOne and Recorded Future joined as founding members, which matters, because a registry carrying one vendor’s agents isn’t an exchange.

That’s the idea Tenable CTO Vlad Korsunsky keeps coming back to: “Security is a team sport,” he says. “We’re creating a collaborative ‘town square’ where cybersecurity practitioners can build, test, improve, and share the best in agentic defense.” Security has already learned to circulate threat intelligence, indicators of compromise, and detection rules. Agentic tooling is simply the next.

Your turn to build an AI agent

Please check out the CyberAgents Exchange for yourself!

Start by leveraging what other teams have already contributed. Find the component that maps to your own worst Tuesday scenario, read the source, inspect the code, and deploy it on your terms. Build if you feel inspired. If not, express your gratitude to builders, and strengthen our collective defense either way.

Learn more

Read the announcement of the CyberAgents Exchange, the industry’s first open-source AI agent exchange for cybersecurity
See what 30 days with Claude Mythos Preview taught Tenable’s own security team about proving exploitability instead of ranking suspicion
Explore how Tenable Hexa AI automates exposure remediation with agentic routines, with a human in the loop

AI code security with Claude Mythos Preview: Inside Tenable’s 500+ hours of testing for Project Glasswing

Robert Huber, Tenable Research — Thu, 06 Aug 2026 08:00:00 -0400

We spent 500+ hours and 40 billion tokens testing Anthropic’s Claude Mythos Preview for Project Glasswing. The takeaway: frontier AI won't run your code security program, but used well, it can make one even stronger.

Key takeaways

Frontier AI dramatically scales security testing. In one month, Tenable dedicated 11 security experts and more than 40 billion tokens testing Claude Mythos Preview across source code analysis, exploit creation, binary reverse engineering, threat modeling, and dynamic testing.
Human expertise turns frontier AI findings into real risk reduction. More findings don't automatically mean more risk. Mythos Preview surfaced a high volume of findings, but only a fraction proved to be true exposures once Tenable experts determined their reachability, exploitability, and whether existing controls already mitigated them.
Source code access is the defender's asymmetric advantage. Frontier AI is far more powerful when it can read the full source, and that visibility is something defenders have and outside attackers don't. Securing code repositories is more important than ever.

Ever since Anthropic introduced Claude Mythos Preview, the security community has been buzzing with equal amounts of excitement, anxiety, and healthy skepticism.

After well over 500 hours of rigorous testing at the hands of Tenable security analysts, engineers, and researchers, we’re excited to share our assessment, even as we proceed with testing Claude Mythos 5 (more to come on that).

Here’s what Tenable learned from our month in the trenches with Mythos Preview, and what it means for your organization’s security posture. Our headline finding: used well, frontier AI earns a real place in a modern code security program. It won't run the program on its own, but paired with the right harness and expert oversight, it makes a strong program measurably stronger.

How Tenable is testing Claude Mythos Preview

It’s important to clarify that we are not using Claude Mythos Preview in any Tenable products. The same restriction applies to all Project Glasswing participants: The model may be evaluated for research purposes, but it cannot be incorporated into commercial products.

We evaluated the source code scanning, exploit creation, binary reverse engineering, threat model creation, and dynamic testing capabilities of Claude Mythos Preview. Tenable dedicated a team of experienced security engineers for the testing along with white-box source code analysis and a purpose-built testing harness (the set of prompts and tools that constrain and orchestrate a model across a multi-step task).

Before evaluating Claude Mythos Preview, we built an independent testing harness. Our testing showed that the real power comes not from the model alone, but from the combination of the model, a purpose-built harness, rich context, and expert human oversight.

Where Mythos and frontier AI fit alongside SAST, DAST, and SCA

To understand where a frontier model like Claude Mythos Preview fits into your software security posture, it helps to compare Mythos directly to your existing stack of deterministic tools, including static application security testing (SAST), dynamic application security testing (DAST), and software composition analysis (SCA).

Deterministic tools rely on hard-coded rules and produce the same exact output for any given input. Non-deterministic tools, like frontier AI models and generative AI systems, use statistical probabilities to predict outcomes. Consequently, non-deterministic systems can yield different results across identical inputs.

The bottom line: Traditional, deterministic code security tools remain the core of an effective, audit- and compliance-ready program. Frontier AI models like Claude Mythos Preview provide additional capability for the creative, variance-tolerant layer where humans continue to review findings. In other words, it’s a powerful new arrow in the quiver with the potential to make your whole security arsenal more effective.

Table 1: Traditional security scanning tools vs. Claude Mythos Preview

Feature	Traditional tools (SAST, DAST, SCA)	Frontier AI models
Consistency	Deterministic: Produces identical, highly repeatable results every run. Perfect for enterprises with rigorous compliance requirements.	Non-deterministic: Yielded as much as a 30% run-to-run variance in finding counts and severity rankings during Tenable’s testing.
Operational cost	Low: Fast, cheap, and easily integrated into continuous CI/CD pipelines.	High: Expensive to validate raw, noisy outputs; best used for periodic testing.
Strength	Catching known vulnerabilities, patch-diffing, and maintaining compliance baselines.	Creative, exploratory “offensive” testing, threat modeling, and contextual code analysis.

Match the tool to the task: determinism for audit, frontier AI for exploration

Frontier AI models, including Claude Mythos Preview, are fundamentally non-deterministic. If you run the exact same target through the exact same model on different days, the model will yield different results.

In Tenable’s testing, we observed Mythos outputting different issue counts and different severity rankings, despite using the exact same prompt. That variance is an asset for creative, exploratory work with an expert reviewing output, but it's the wrong fit as the backbone of a consistent, repeatable, audit-grade security or compliance program. For this reason, deterministic tooling remains core, though it will need to adapt to AI and integrate it in a meaningful way.

That adaptation isn't free. Before you fold a frontier model into a security program, three constraints shape where and how it earns its place:

The cost - The economics only work when you're deliberate about where you deploy it. The tokens required to run the model as a continuous scanning tool would be cost-prohibitive — in our estimation, costs could reach $500,000 per full-time employee (FTE) per year, based on an estimated one-month token usage of roughly $41,700 per FTE.
The noise - In Tenable tests, model outputs (the findings) were noisy and required heavy validation. Consequently, if you’re going to use Claude Mythos Preview for source code scanning, you’ll want to feed the model’s high-quality findings into your existing static analysis and gating workflows. Without a validation pipeline working alongside the model, you’ll get buried in noise.
The results - Claude Mythos Preview produced different outputs even when our inputs were the same. This kind of inconsistent model behavior breaks pipelines that need to run predictably at scale. What’s more, compliance requirements demand reproducible, defensible evidence. A model that produces different results each run won’t stand up to auditors.

The real costs of code security with frontier AI go beyond tokens

When calculating the total cost of ownership (TCO) for frontier AI as code security tool, many organizations make the mistake of focusing exclusively on API and token costs.

While token costs can quickly add up, they still represent just one factor in the TCO equation. Because frontier models generate a high volume of noisy findings, your TCO model should include the cost to validate the findings, which includes the cost of the experienced security engineers required to handle the manual validation.

TCO is why frontier AI works best as a targeted, high-value layer rather than a day-to-day security scanning engine. Run it against everything continuously and the costs quickly become prohibitive, quickly. Consider that just one of our security analysts used more than 10 billion tokens in a month of rigorous testing, which cost $41,700. Multiply that by 12 months, and you’ve got a nearly $500,000 annual run rate for just that one person.

Frontier AI changes the scale of discovery, not the nature of source code flaws

Some organizations are bracing for a new class of “Mythos-level” bugs. Based on our experience with Mythos, that’s the wrong worry. The model finds the same kinds of source code flaws a pen tester would, such as broken logic and memory corruption; it just finds far more of them, at much greater speed, and if appropriately prompted, can create the exploit. Claude Mythos hasn’t uncovered a new class of vulnerabilities; it’s amplified the speed and volume of findings.

It’s important to remember that a potential finding is not the same as a validated exposure. A finding signals a potential issue. AI surfaces a large volume of findings, but security teams require context about potential flaws in the source code — whether they’re reachable, exploitable, and the extent to which any existing security controls mitigate them — to validate and remediate the findings that do indeed create true exposure.

In a world of AI-driven vulnerability discovery, the context, triage, validation, and prioritization work become much more important. Once you subtract what your existing tools already catch, what others have reported, and what isn’t actually reachable, the list worth acting on gets shorter. Your capacity to validate and fix is the constraint now, not discovery.

Source code access gives defenders a major advantage

The immense power of frontier models in code security relies on “white-box” source code analysis. Source code access gives internal security teams the ultimate asymmetric advantage against threat actors. The deep source code visibility that supercharges an internal defender’s automated pipeline is exactly what an outside, black-box attacker lacks.

Consequently, protecting your source code repository has never been more vital. If an attacker gains access to your source code, they gain the keys to run their own highly optimized AI discovery engines against you.

The bottom line: frontier AI shifts your edge from finding flaws to proving what matters

Tenable testing confirmed Claude Mythos Preview can function as a highly capable pen-testing tool.

When combined with a purpose-built harness and the two things only a human defender has — source code access and the ability to validate findings live — Claude Mythos Preview can deliver powerful results. Give it a harness and an expert to drive it, and it becomes a genuine force multiplier; leave Mythos to run on its own and the output tends to be noisy, with many of the findings never making it to validation. Either way, frontier AI shifts the hard work from discovery to verification, prioritization, and remediation.

We continue to evaluate frontier AI models, including Mythos 5, to identify where they’ll serve customers best, and we look forward to sharing our ongoing findings in upcoming blogs.