Tenable Blog

When AI accelerates the speed and scale of vulnerability discovery, the pressure on security teams shifts to prioritization and identifying the exposures that are the most critical to fix first. 

Key takeaways

1. There’s a growing narrative that AI will overwhelm cybersecurity. That attackers will simply outpace defenders. That’s too simplistic.
    
2. AI changes both sides of the equation. It accelerates vulnerability discovery in some domains, especially where data is rich and accessible, and expands what defenders can see across their environments.
    
3. Even when organizations can see more, they still struggle to decide which exposures matter most and act on those decisions fast enough. When AI is capable of finding more exposures, across more of your environment, the pressure shifts to what you choose to fix first.
    
4. The pace of AI-driven vulnerability discovery doesn't just call for faster patching. It’s calls for a completely different operating model.

When Anthropic’s CEO Dario Amodei talks about a “moment of danger,” it’s worth paying attention. The headline takeaway from the Anthropic news cycle is straightforward: AI models like Mythos are discovering vulnerabilities at a speed and scale we’ve never seen before. The time between discovery and exploitation is collapsing. What used to take weeks could soon take hours.

That is a real shift.

But the industry’s instinctive reaction is to treat this as a vulnerability problem. More findings. Faster scanning. Shorter patch cycles. That framing is already outdated. This is not a vulnerability crisis. It is an exposure crisis.

Discovery just became infinite

For years, security programs have been built around a simple loop: find issues, prioritize them, fix them, repeat. It was never perfect, but it was at least bounded by human limits.

AI just removed those limits. Discovery is no longer the bottleneck. Machines can now surface weaknesses continuously, across code, cloud, identity, and infrastructure, at a pace no team can match. And more importantly, they can identify paths of attack no human has ever considered — chaining weaknesses together in ways that weren’t previously visible.

That doesn’t just increase volume. It fundamentally changes the nature of the problem.

Because when discovery becomes effectively infinite, and attack paths expand beyond human intuition, the idea that you can “keep up” starts to fall apart.

And that’s exactly what this moment is revealing.

It’s also why this isn’t just a call for faster patching. It’s a call for a different operating model entirely.

If discovery is continuous, exposure management must be continuous too.

The industry is solving the wrong problem

Most organizations already understand vulnerabilities. They have scanners. They track CVEs. They run patch cycles. If more findings alone made companies safer, we would have solved this by now.

But breaches don’t happen because a vulnerability exists in isolation. They happen because a weakness sits in the wrong place, is reachable in the wrong way, and can be combined with other exposures, like misconfigurations, over-privileged identities, or unprotected assets, to create real impact.

That combination is what actually matters. That combination is exposure.

What AI is accelerating is not just the number of flaws, but the number of meaningful attack paths that connect these exposures across an environment. It is shifting the problem from “what is broken?” to “how can this be exploited in context?”

And most security programs are not built to answer that second question.

The real bottleneck has shifted

The uncomfortable truth is that AI is not just creating pressure on defenders. It is exposing where the real bottleneck has always been.

Yes, discovery has mattered and still does. You can’t secure what you can’t see. Gaps in visibility, incomplete inventories, and blind spots across environments are still very real challenges.

But even when organizations can see, they still struggle to act. Because the true bottleneck isn’t just discovery. It is decision and action.

Even before this moment, organizations were patching only a fraction of what they found. Not because they didn’t care, but because they didn’t have the clarity to know what mattered most. Now multiply that by an order of magnitude. More findings don’t lead to more security. They lead to more indecision. And indecision, at machine speed, is risk.

This is why the conversation has to move beyond vulnerability management. The question is no longer how many issues exist. It is which ones actually matter, which ones can be exploited right now, and what will reduce risk the fastest.

That requires a different way of thinking. One that connects assets, identities, configurations, and vulnerabilities into a single, contextual picture. One that understands not just severity, but reachability and impact. One that can guide action, not just report findings.

In other words, exposure management. Not as a buzzword, but as a necessity.

The AI arms race is really about prioritization

There’s a growing narrative that AI will overwhelm cybersecurity. That attackers will simply outpace defenders. That’s too simplistic.

AI is changing both sides of the equation. It is accelerating vulnerability discovery in some domains, especially where data is rich and accessible, while also expanding what defenders can see across their environments.

But discovery is not uniform. Gaps in asset visibility still exist. Proprietary environments, incomplete inventories, and fragmented tooling mean organizations are often still working with partial pictures of their attack surface.Which makes the real challenge even clearer.

Because even when organizations can see more, they still struggle to decide what matters most and act on it fast enough. When more can be found, across more of the environment, the pressure shifts to what you choose to fix first.

The advantage will not go to the organization with the most data or the most alerts. It will go to the one that can turn what it knows into clear, confident decisions and act on them immediately.

In this environment, prioritization is no longer a supporting function. It is the strategy.

Where Tenable fits

This is the shift Tenable has been building toward.

Not another detection engine. Not another flood of findings. But a way to understand how risk actually forms across an environment and to drive the actions that reduce it. Because visibility alone creates noise. Context without action leaves you exposed. And speed without prioritization just accelerates the chaos.

What’s needed now is a system that can connect the dots, identify what matters, and help organizations move at the same speed as the threat.

That’s the real challenge of this moment.

The bottom line

The “moment of danger” is not that AI can find vulnerabilities. It’s that AI is exposing how unprepared most organizations are to act on them.

The future of cybersecurity will not be defined by who discovers the most issues. It will be defined by who can answer, in real time, where they are truly exposed and what to do about it.

That’s the problem that matters now.

As AI adoption accelerates, CISOs face a dual challenge: fueling innovation while mitigating the risks of a rapidly expanding attack surface. Tenable’s five-step framework for securing AI offers a systematic approach to reducing AI security risks as your organization races to achieve the productivity benefits of AI. 

Key takeaways

1. Get a five-step framework to help you secure AI usage throughout your organization and mitigate the security risks that AI tools create.
    
2. Securing enterprise AI use demands a combination of robust AI discovery capabilities, mechanisms to secure AI workloads and the infrastructure running AI, prompt-level visibility, the ability to analyze AI security risks alongside other exposures, and technical controls to ensure compliance with your organization’s AI acceptable use policy. 
    
3. Learn why your existing security controls may be inadequate when it comes to securing AI.

 

As AI transforms enterprises, security leaders like me are grappling with how to most effectively manage the security risks it creates.

The challenge is that AI is now embedded virtually everywhere across our organizations: in employee productivity tools, SaaS platforms, developer libraries, cloud services, APIs, and web apps. The result? Our teams are left with a growing AI exposure gap: a vast and largely invisible attack surface that our traditional security tools weren’t designed to monitor. 

Complicating matters is that we often can’t isolate AI risk to a single asset. Rather, it emerges from a string of interconnected elements (such as applications, infrastructure, identities, and data) that in aggregate create exposure. Here’s an example of what I mean.

Let's say an employee uses an approved AI chatbot for technical support resolution that relies on Amazon Bedrock agents, and those agents have elevated privileges to access sensitive internal systems like enterprise resource planning and customer resource management tools. If a threat actor gains access to the agent through an unpatched vulnerability on the employee’s laptop, then the threat actor can use the agent to breach sensitive data, and a seemingly safe use of an approved AI tool turns out to be a high-impact exposure.

Protecting data in today’s AI-assisted work environments becomes exponentially more difficult because each one of the myriad interactions with AI assets (e.g., every prompt, file upload, generated response, integration, and configuration) can put intellectual property, customer information, and confidential plans at risk.

So, how do we tame this challenging new attack surface that grows unchecked as our organizations expand their use of AI? Here’s a strategic framework I’ve implemented for governing, discovering, and securing AI wherever it crops up and creates risk for your organization. 

Strategic framework: 5 steps for securing enterprise AI1. Establish an AI governance committee, framework, and acceptable use policy

Securing AI starts with setting clear expectations with employees about acceptable use. Establish an AI acceptable use policy that:

• provides a list of approved and unapproved AI tools;
• defines appropriate and inappropriate business use cases;
• explains the types of data that can and can’t be shared with LLMs;
• prescribes rules for data handling;
• addresses copyright laws; and
• states the consequences of policy violations.

Based on your organization’s AI acceptable use policy, you can implement controls to enforce and monitor compliance with it.

2. Discover AI across your entire attack surface 

When I talk with other CISOs about securing AI, they say discovering and detecting it is one of their biggest challenges. And I get it: it’s freakin’ everywhere, and a lot of it is really hard to find, in part because AI’s presence extends well beyond centrally-managed systems that are clearly visible. 

As security leaders, we need to account for: 

• AI assets, agents, plugins, browser extensions, and workloads, regardless of whether they’re...
  • run in the cloud or on-premises
  • internally or externally accessible
  • approved or unapproved
• Forgotten AI test deployments
• AI tools embedded in endpoints and applications
• All AI software, libraries, models, and services
• Publicly exposed AI services, large language model (LLM) APIs, and AI chatbots on endpoints and in cloud applications.

Your existing data loss prevention (DLP), cloud access security brokers (CASB), and cloud security posture management (CSPM) solutions can provide a good initial starting point to discover AI assets. But holistic discovery requires specialized discovery tools because the non-deterministic nature of AI defies traditional rules-based security protections. It also requires unique detection capabilities to identify embedded AI tools and libraries and understand how AI systems work together to create exposure.

With a continuous and complete view of your enterprise’s AI usage, you’ll know precisely what workloads and infrastructure you need to secure, and you can begin to assess your organization’s overall AI exposure and prioritize specific remediation actions accordingly.

3. Secure AI workloads and agents

Because AI workloads are deeply interconnected and often severely misconfigured or over-permissioned, this step involves proactively securing the infrastructure where AI runs and hardening AI workloads before attackers can exploit them. For example, if developers at your organization are building AI-enabled applications in the cloud, you want to make sure that cloud infrastructure is secure. 

Effective protections require capabilities to: 

• Identify misconfigurations and risky configurations in cloud-based AI workloads.
• Detect vulnerabilities that could expose models, agents, data, or APIs to unauthorized access.
• Implement identity-driven exposure reduction, since AI relies heavily on non-human identities.
• Detect the overprivileged service accounts, roles, and machine identities that AI workflows use and strictly enforce least-privilege access.
• Understand potential attack pathways from AI assets and workloads that could impact business-critical systems or lead to sensitive data.
• Quickly isolate erratic or compromised AI agents into controlled environments to minimize potential breach impact.

I’ll dive deeper into this specific topic of securing AI workloads and agents in a follow-up blog I have planned. In the meantime, you can understand how identity weaknesses and infrastructure flaws combine to create critical exposure by conducting deep risk analysis of your AI stack. Based on these insights, you can provide actionable playbooks to your security teams to harden environments and ensure services run on secure, resilient, and validated architectures.

4. Assess AI usage and interactions

This step involves understanding how your employees interact with generative AI tools and autonomous agents to make sure employees aren’t violating your organization’s AI acceptable use policy. It’s critical to understand how data flows through all AI applications and determine where exposure is being created. 

This requires granular visibility into: 

• Who’s using AI
• For what purpose
• Where risky behavior and misuse originates
• What data employees are sharing through prompts, uploads, or automated actions
• Attempts to jailbreak approved AI tools and provide malicious prompts

Prompt-level visibility into employee AI use allows your security team to detect policy violations and reinforce safe AI behavior. It also allows your security team to identify any sensitive data, including intellectual property and PII, that employees or agents share with AI tools via prompts, uploads, and automated interactions and that could create exposure via an accidental leak. And it enables your security team to detect and respond to new AI-specific threats and misuse, like prompt injection attempts and other malicious instructions designed to manipulate AI systems. 

Whether it’s discovering a malicious tool connected to a Microsoft Copilot agent or an employee misusing AI for inappropriate situations that the tool was not designed for (e.g., internal hiring decisions), you need to respond quickly to address the exposure and reinforce safe use.

5. Analyze AI security risks in the context of other exposures

To mitigate AI security risks, it’s not enough to detect in isolation unpatched vulnerabilities in AI software, weak configurations of AI systems, and overprivileged agents. After all, AI is becoming fully integrated into all of our apps, data, and business processes.

Mitigating AI security risks requires a unified, automated approach to gathering contextually-rich AI security data and correlating and analyzing it alongside other exposure data, such as a publicly exposed S3 bucket, a vulnerable laptop, or an orphaned account with admin privileges. At Tenable, we call this approach exposure management, and we see the industry quickly catching on. Exposure management allows you to proactively see how security weaknesses across your environment combine to create exposure: high-risk attack paths leading to your organization’s most sensitive systems and data. 

Exposure management also surfaces risks with precise context — including the specific AI engine, user, and session — to enable high-fidelity issues management and rapid response. It’s about understanding how toxic combinations of risk coalesce to create business exposure. One medium-criticality misconfiguration in Amazon Bedrock could be connected to an unsecured LLM providing over-provisioned entitlement access for agents. Exposure management requires this complete understanding of the entire environment and attack surface.

Securing the future of AI innovation

The rapid integration of AI across the enterprise has created a complex, interconnected attack surface that traditional security controls are simply not equipped to handle. To close the AI exposure gap, security leaders must shift from a reactive, tool-centric approach to a proactive, unified strategy.

By implementing this five-step framework, you can create a resilient security posture that evolves alongside AI technology. Ultimately, effective exposure management isn't about slowing down innovation; it's about providing the necessary guardrails to ensure your organization can embrace the power of AI safely and confidently.

Detecting a vulnerability is easy. Finding the person responsible for fixing it is where remediation programs often break down. See how Tenable Hexa AI uses MCP to connect your exposure data to your identity provider — automating the hunt for asset owners in seconds.

Key takeaways

1. The accountability gap is the real bottleneck. Finding a vulnerability is only a part of the battle — you must also know who is responsible for the asset. Every hour spent playing detective is another hour the system stays exposed.
2. Live identity context beats stale CMDB data. By linking Tenable Hexa AI to identity providers like Okta through MCP, you instantly find out an asset’s current owner — not who owned it the last time someone updated a spreadsheet.
3. Automated ownership discovery slashes MTTR and eliminates the “not my job” problem. When Tenable Hexa AI cross-references exposure data with identity data in a single workflow, tickets route themselves — turning hours of manual Slack triage into an instant hand-off.

In our first use case blog, we showed how Tenable Hexa AI can identify assets impacted by a supply chain attack like the Axios npm compromise. In our second post, we walked through how custom Tenable Hexa AI agents can automate patching at machine speed using Tenable Patch Management.

But there’s a step hiding between “we found the vulnerability” and “we deployed the fix” that quietly consumes more analyst hours than either of those activities: figuring out who actually owns the vulnerable asset. This post explains how to close that gap and accelerate vulnerability remediation using Tenable Hexa AI.

The Friday afternoon fire drill

Picture the scenario every security team knows by heart. It’s 4:45 p.m. on a Friday. A critical CVE drops. Your Tenable scan lights up 47 affected hosts across three business units. The IPs are real, the findings are accurate, the severity is clear — and nobody knows who owns half of these impacted assets.

The next two hours look the same as they always do: a flurry of Slack messages to #infra, #platform, #cloud-ops. “Is prod-api-17 yours?” “Who owns the subnet in us-east-1b?” “I think that was Maria’s team before the reorg.” By the time someone confirms ownership on the last host, half the team has logged off for the weekend, and the exploit window is still wide open.

This is the accountability gap: scanners see technical assets, identity providers see people, and configuration management databases (CMDBs) try to bridge the two, but the entries are usually months old — frozen at the moment the asset was provisioned, and most likely not updated when the owner changed teams, left the company, or handed off the service. The result is a security team forced to do detective work instead of remediation.

It’s not a niche problem, either. The Center for Internet Security’s CIS Critical Security Control 01 — the very first control on the list — calls out accurate inventory and ownership as the foundation every other control builds on. You can’t protect what you can’t attribute.

The fix: Live identity context, on demand

Tenable Hexa AI closes this gap by acting as the connective tissue between your exposure data and your identity source of truth. Tenable Hexa AI uses the Model Context Protocol (MCP) to orchestrate tasks between, for example, the Tenable One Exposure Management Platform on one side, and identity providers – such as Okta and Entra ID – and CMDBs like ServiceNow on the other.

This is the important distinction: Hexa AI isn’t just reading a static tag you populated six months ago. It’s issuing a live query against the identity provider at the moment you need the answer. Who currently owns this service account? Who provisioned this EC2 instance? Who is the on-call stakeholder for this application in PagerDuty? The answer you get from Tenable Hexa AI reflects today’s org chart, not last quarter’s.

By treating identity as a real-time data source rather than a point-in-time field on an asset, you skip the CMDB-rot problem entirely.

A practical workflow: From vulnerability finding to remediation owner in under a minute

Let’s walk through what this looks like end-to-end. The prompt is plain English; the orchestration happens underneath.

Step 1: Command Tenable Hexa AI with a natural language prompt

The workflow begins in Claude with a prompt like:

“Find the most critical VPR finding on each of the 5 most critical assets. query Okta to identify the most likely owner based on service-owner group membership, app admin assignment, and recent login activity. Route a ticket to that asset owner in the Test Jira project.”
 

 

Step 2: Tenable Hexa AI cross-references exposure data with identity data

The prompt triggers the Tenable Hexa AI agent to query Tenable for unassigned critical findings, filtered by Vulnerability Priority Rating (VPR), so you’re only resolving ownership for the findings that actually matter. For each affected asset, Hexa AI then calls the Okta MCP server to resolve ownership — looking at who holds admin-level access, who recently authenticated against the host, and who belongs to the owning group or application assignment.

This is the step that wrecks your Friday afternoon. Tenable Hexa AI does it in seconds, at scale, across every unassigned finding in the environment.
 

 

Step 3: Tenable Hexa AI assigns the owner and routes the ticket

Once the owner is identified, a ticket is opened in your system of record, such as Jira or ServiceNow, pre-filled with the finding detail, the VPR score, the affected host, and the person who can actually fix it.

To make sure this is trusted execution rather than blind automation, Hexa AI relies on Tenable’s Exposure Data Fabric — the unified layer that maps the relationships between vulnerabilities, identities, and assets across your environment. That context is what lets the agent distinguish between “the person who logged in once” and “the person who actually runs this service.” And as always, you can place human-in-the-loop (HITL) checkpoints wherever your change-management policy requires them — for example, requiring analyst sign-off before a ticket routes to a VP, or before ownership is rewritten on a tier-0 asset.
 

The NIST Cybersecurity Framework 2.0 (ID.AM-03) explicitly calls for organizations to prioritize resources based on business value and owner accountability. This workflow is how you meet that requirement operationally, not just on paper.

The operational payoff

What does this actually buy you?

• MTTR measured in minutes, not days. The administrative overhead between discovery and assignment collapses. The security team gets a head start against the attacker because the first person to see the ticket is the first person who can act on it.
• A culture shift inside IT and security. Clear, automated ownership eliminates the “it’s not my job” reflex. When the system says you own prod-api-17 and here’s the evidence trail from Okta, there’s nothing to argue about. Trust between the security team and the asset owners goes up, because nobody is getting tickets that belong to someone else.
• Compliance and reporting that write themselves. When your CISO or an auditor asks “who is responsible for our top 20 critical exposures?”, you can show them a live report instead of promising to chase it down. Ownership becomes a queryable attribute, not an archaeological dig.

The speed at which the right information reaches the right person is one of the strongest predictors of organizational stability and recovery performance. Automating ownership is how you raise that signal speed for your security program.

Scaling accountability for vulnerability remediation with agentic AI

The accountability gap isn’t a people problem — it’s an integration problem. Security teams have always known that asset ownership matters; now they have a clean, real-time way to resolve it at the speed modern threats demand. Tenable Hexa AI, together with MCP-based identity connectors, turns that resolution into a background function of the platform.

When every critical finding arrives pre-attributed to the right person, vulnerability management stops being a ticket-routing exercise and becomes what it was always supposed to be: a remediation function.

Ready to close your accountability gap?

Tenable Hexa AI is currently in private preview for select Tenable One customers. 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 Tenable agentic AI capabilities, including the growing catalog of MCP integrations across identity, ticketing, and patching tools.

Bridge the gap between AI-driven vulnerability discovery and prioritized remediation. Learn how to integrate Claude Security’s deep-logic analysis into Tenable One to unify your attack surface, eliminate noise, and focus on the risks that matter most.

Key takeaways

1. As frontier AI models like Claude accelerate the pace of vulnerability discovery, security programs must shift their focus toward efficient exposure prioritization and remediation to avoid drowning in noise.
2. Integrating Claude Security with the Tenable One Exposure Management Platform allows teams to centralize deep-logic code analysis alongside the rest of the attack surface. This unified view helps normalize raw AI findings into actionable intelligence and a prioritized remediation plan.
3. The integration process involves scanning code in Claude, exporting the findings, and using the Tenable Open Connector to map and aggregate data attributes. Proper aggregation ensures that vulnerabilities are grouped by root cause, preventing the artificial inflation of risk scores and allowing teams to focus on critical issues.

The promise of AI in security is compelling: find vulnerabilities faster than ever before. But speed of discovery alone doesn’t make organizations safer.

As AI tools like Claude Security surface complex, deep-logic vulnerabilities at an unprecedented scale, the bottleneck has quietly shifted. Discovery is no longer the hard part. Remediation and prioritization are.

Security teams are being buried under a surge of new vulnerability data. When AI-generated findings pile up in silos, disconnected from the rest of your attack surface, they don’t reduce risk. They add noise. And more noise means more time spent triaging instead of fixing.

To keep pace, organizations need to do more than discover faster. They need to normalize AI-driven findings against the rest of their attack surface to understand which ones actually pose a business risk. 

By bringing Claude’s advanced code security insights directly into the Tenable One Exposure Management Platform via the Tenable One Open Connector, you can transform a flood of raw data into a unified, prioritized remediation plan.

Step 1: Run the security scan in Claude

The process begins by leveraging Claude’s deep-reasoning capabilities to perform a comprehensive security analysis of your codebase. Whether triggered via console or performed periodically, Claude Security can automatically identify complex logic flaws and vulnerabilities in a code repository of your choosing:
 

The first stage of the integration is generating raw security intelligence. Within the Claude Security interface, you’ll define the scope by connecting your target repository and selecting the appropriate branch (e.g., main). You can then choose the AI model used in the scan and the level of effort in which it should run. 

In this example, we are using Claude Opus 4.7 with the effort level set to Extended for a comprehensive review. Keep in mind that the duration and cost of this scan will depend heavily on the complexity of your code repository.

Once Claude Security has finished analyzing your repository, you will be presented with a summary of the open security findings.
 

 

Step 2: Export the findings

To be able to ingest these findings within Tenable One, findings need to be exported. This can easily be done by clicking on the “Export all findings” option available within the scan screen and selecting Download CSV.
 

While a manual export is useful for initial validation and for the purposes of this review, manual processes cannot scale with the volume of vulnerabilities AI is capable of discovering. To truly bridge the gap, this workflow should be automated.

By leveraging Claude Security’s API webhooks and scheduled scans, you can automate the delivery of security findings directly to a secure cloud storage layer (such as Amazon S3). From there, the Tenable One Open Connector can be configured for continuous ingestion, ensuring your "single pane of glass" reflects your code’s security posture in near real-time without manual intervention.

Step 3: Set up the Tenable Open Connector

With the analysis complete, the focus shifts to centralizing that data within the Tenable Exposure Management platform. To account for the rapid evolution of AI-driven security tools, we utilize the Tenable One Open Connector. This approach allows security teams to seamlessly ingest Claude’s security findings into the Tenable platform, providing a versatile way to centralize AI-driven vulnerability data alongside the rest of your attack surface.

Within the Tenable One console, navigate to the Connectors management page to initialize a new Tenable Open Connector. We recommend a descriptive naming convention - such as "Claude Code Security" - to ensure clear attribution within your console.

To facilitate the data transfer, configure the connector with the following parameters:

• Data-pulling configuration: For uploading a single exported file, select the ״Static File Upload״ option.
• Data update mode: Select ״Override Data (Full Fetch):. This is a critical setting for maintaining data integrity. By selecting "Full Fetch," each new upload serves as the definitive source of truth. This ensures the platform completely refreshes your posture, automatically clearing remediated issues and preventing your dashboard from being cluttered by stale "ghost" vulnerabilities.
   

Step 4: Map the data attributes

This is the most critical phase of the integration. For Claude Security’s insights to be actionable, they must be translated from raw AI findings into the structured vulnerability language that Tenable One uses to calculate risk.

Upon uploading your Claude-generated CSV, you will be directed to the Attribute Mapping interface. This is where you define the relationships between Claude’s discovery fields and Tenable’s exposure attributes.

Based on Claude's output, you should configure the mappings as follows:

• Severity -> Severity
• Status -> Finding State
• Date created -> Asset Created Date
• Repository -> Asset Name
• Description -> Finding Description
• CWE -> Finding CWEs
• File path & Line -> Asset Generic Details (Custom)
• Finding URL -> Finding Generic Details (Custom)
• Name -> Finding Name

The final step is to define the uniqueness and aggregation logic. This tells Tenable One how to cluster individual findings so it can accurately calculate your Asset Exposure Score. Without proper aggregation, the same vulnerability found across multiple files could artificially inflate your risk score, creating the very "noise" we are trying to eliminate.

To ensure a clean data set, set the unique identifier to Finding Name.

By grouping based on the specific weakness identified, Tenable can consolidate multiple instances of a vulnerability into a single, high-context entry. This allows your security teams to focus on the root cause of the exposure rather than triaging hundreds of identical alerts. Once these logic parameters are set, you have successfully transformed Claude's raw AI discovery into a prioritized, enterprise-ready security asset.
 

Step 5: Execution and review

Once your mapping and aggregation logic are confirmed, click Save and Execute.

Your new integration will appear in the Connectors list with a "Connecting" status as Tenable One begins the initial ingestion and normalization process.
 

Within minutes, the "discovery bottleneck" begins to clear: Claude’s high-fidelity AI insights will populate your Tenable One dashboard, as distinct instances of weaknesses on your assets, fully integrated into your existing workflows and ready for prioritized remediation.


 

From AI discovery to actionable intelligence

By bridging Claude Security and Tenable One, you are doing more than just moving data between platforms - you are transforming a flood of raw AI findings into tracked, prioritized business metrics. Now you can understand how application code vulnerabilities may create new attack pathways or which ones are associated with revenue generating workloads. Static code risks will also inform resource decisions and executive communication as part of your exposure management governance to help you answer, "how secure am I" in this new AI-driven world.

In an era where AI can discover vulnerabilities faster than any human team can fix them, the goal of security operations has shifted. Success is no longer measured by the volume of your findings, but by the speed and accuracy of your response.

Why leave your most advanced security insights in a silo? By centralizing Claude’s deep-logic analysis within the Tenable Exposure Management Platform, you give your team the context they need to focus on what actually matters. You aren't just managing vulnerabilities; you are managing your entire attack surface from a single, unified source of truth.

A flaw in the Linux kernel present since 2017 allows a local user to gain root access on virtually every major Linux distribution. A public exploit is available and reported to work reliably.

Key Takeaways

1. CVE-2026-31431 is a high severity local privilege escalation vulnerability in the Linux kernel reportedly affecting virtually every major distribution released since 2017.
    
2. A public exploit is available and reported to be reliable, drawing comparisons to previous high-profile Linux kernel privilege escalation flaws.
    
3. Patched kernel versions are available, though some major distributions have not yet shipped updates.

Background

Tenable's Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding CVE-2026-31431, a Linux kernel local privilege escalation vulnerability dubbed "Copy Fail."

FAQ

When was Copy Fail first disclosed?

On March 23, researcher Taeyang Lee of Theori reported the vulnerability to the Linux kernel security team. The flaw was discovered in part using Theori's AI-assisted security scanning tool, Xint Code. A mainline patch was committed on April 1, CVE-2026-31431 was assigned on April 22 and public disclosure occurred on April 29.

What is CVE-2026-31431?

CVE-2026-31431 is a local privilege escalation vulnerability in the Linux kernel's cryptographic subsystem. It was assigned a CVSSv3 score of 7.8.

CVEDescriptionCVSSv3CVE-2026-31431Linux Kernel Local Privilege Escalation Vulnerability7.8

The flaw allows a local user to modify the kernel's cached copy of a file in memory without changing the file on disk. By targeting a privileged binary, an attacker can gain root access. Because the modification exists only in the page cache, the underlying file on disk remains unchanged. Standard disk forensics would not detect the alteration, and clearing memory through a reboot or resource pressure causes the cache to reload from the original file. For a detailed technical breakdown, refer to the Xint Code blog post.

Everyone focuses on memory corruption bugs in the Linux kernel, but we shouldn’t overlook logical bugs. https://t.co/PrSI435i35

— 5unkn0wn (@5unKn0wn) April 30, 2026

 

How does Copy Fail compare to Dirty Cow and Dirty Pipe?

Copy Fail has drawn comparisons to two other well-known Linux kernel privilege escalation vulnerabilities: Dirty Cow (CVE-2016-5195) and Dirty Pipe (CVE-2022-0847). Both are in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalog.

Dirty Cow relied on a race condition, which meant exploitation could fail or require multiple attempts. Dirty Pipe had constraints around how data could be written and where in a file it could be modified. Copy Fail reportedly works consistently across distributions without relying on a race condition or write-position constraints.

How severe is CVE-2026-31431?

Any local user on a system running a vulnerable kernel can exploit this flaw to gain root access. The exploit uses kernel features that are enabled by default on most distributions and does not require special privileges or configuration.

The highest risk environments are those where multiple users or workloads share a Linux kernel: cloud and multi-tenant systems, container clusters and CI/CD pipelines that run untrusted code. Because the exploit targets the kernel's shared file cache, it can also cross container boundaries. On single-user systems, the risk is lower since an attacker would already need local access.

Which Linux distributions are affected?

Any Linux distribution shipping kernel 4.14 or later is affected. The vulnerability was introduced in 2017 and persisted across nearly a decade of kernel releases. Distribution patch status as of April 30:

DistributionPatch StatusUbuntuPatchingSUSEPatchingRed HatPatchingDebianVulnerableAmazon LinuxVulnerableArch LinuxPatched

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

Yes. A public PoC was released on GitHub alongside the disclosure. The exploit is a short Python script that modifies a privileged binary in memory and then executes it to obtain root. It is reported to work reliably without requiring multiple attempts or precise timing.

Are there other vulnerabilities related to Copy Fail?

According to Theori, the same research effort that uncovered Copy Fail found additional security flaws in the kernel, at least one of which is also a privilege escalation issue. Those findings remain under coordinated disclosure. This blog will be updated if and when additional information becomes available.

Are patches or mitigations available?

Patched kernel versions have been released:

Affected Kernel Version RangeFixed Kernel Version4.14N/A5.10.*5.10.2545.15.*5.15.2046.1.*6.1.1706.6.*6.6.1376.12.*6.12.856.18.*6.18.226.19.126.19.12>7.07.0

The fix removes the 2017 optimization that allowed the vulnerability, restoring a safer separation between read and write operations in the kernel's crypto interface.

For systems where an immediate kernel update is not feasible, two workarounds are available depending on kernel configuration.

If the module is loaded dynamically (CONFIG_CRYPTO_USER_API_AEAD=m):

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf rmmod algif_aead 2>/dev/null || true

If the module is compiled into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), which is the case on some enterprise kernels, the above will not work. Contributors on the oss-security mailing list have reported that adding the following to the kernel boot parameters and rebooting blocks the exploit:

initcall_blacklist=algif_aead_init

Discussion on the oss-security mailing list has also identified several userspace applications that use the affected kernel interface, including but not limited to, cryptsetup and firefox-esr. In practice, initial testing by contributors on the thread has not caused these applications to fail, but the impact may vary by workload. Testing in a non-production environment before deploying either workaround is advisable.

Historical exploitation of Linux kernel vulnerabilities

The Linux kernel has a long history as a target for privilege escalation attacks. CISA's KEV catalog contains over 20 entries for Linux kernel flaws, including the two flaws most commonly compared to Copy Fail:

CVEDescriptionDate Added to KEVKnown Ransomware UseCVE-2016-5195Linux Kernel Race Condition (Dirty Cow)2022-03-03UnknownCVE-2022-0847Linux Kernel Improper Initialization (Dirty Pipe)2022-04-25Unknown

As of April 30, CVE-2026-31431 is not listed in the KEV catalog.

Has Tenable Research classified this as part of Vulnerability Watch?

Yes, we classified CVE-2026-31431 as a Vulnerability of Interest under Vulnerability Watch due to the availability of a public proof-of-concept exploit and historical exploitation of similar Linux kernel vulnerabilities like Dirty Cow and Dirty Pipe that were exploited in the wild.

Has Tenable released any product coverage for this vulnerability?

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

Get more information

• Copy Fail Advisory
• Xint Code Blog: Copy Fail Linux Distributions
• The Register: Linux Cryptographic Code Flaw
• oss-security: CVE-2026-31431 Disclosure

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.

As AI tools evolve from siloed chatbots to autonomous, hyperconnected systems, they create a vast new attack surface. Discover how to manage this risk by focusing on visibility, agency, and semantic security to protect your organization’s increasingly complex landscape of agentic AI systems.

Key takeaways

1. Organizations have moved from siloed AI chatbots to autonomous, hyperconnected agents that can execute actions and access sensitive internal data stores, exponentially increasing cyber risk.
2. A major security challenge arises because AI agents are often granted capabilities that far exceed their intended goals, creating an unnecessarily large and dangerous blast radius.
3. Securing agentic AI requires moving beyond reactive breach detection to a proactive strategy grounded on exposure management and focused on total visibility, posture adjustment, and monitoring of semantic attack vectors.

Here’s a common occurrence in organizations these days: A team – finance, human resources, marketing – sets up an AI agent to perform a seemingly simple action, such as getting task details and emailing them out to the appropriate recipients. 

But is this AI agent as harmless as it looks? A deeper look reveals a big potential for agentic AI security risks: This seemingly innocuous AI agent has been granted the power to connect to a sensitive data store and exfiltrate that data. Is it secure? Has it been properly configured?

Now multiply this scenario by a thousand – or more. The process of spinning up autonomous AI agents is becoming routine, as AI vendors make it increasingly easy to configure them. Thus, eager to automate processes and boost productivity, a typical organization today may have thousands of AI agents operating autonomously. 

For cybersecurity teams, this prevalence of AI agents represents a major new challenge. How do you secure thousands of AI agents that can act on their own and that are hyperconnected to each other and to myriad internal and external systems and data stores?

In this blog post, we’ll delve into this risky scenario and outline the right approach to protect this new attack surface created by this fast proliferation of AI agents.

The agentic AI security challenge is three-fold

The first wave of AI tools that organizations started adopting back in 2022 were mostly siloed chatbots that operated with little integration to other enterprise systems. Thus, they had limited or no access to internal databases and they couldn’t execute actions on internal systems.

What a difference a few years make. Fast-forward to today and organizations are awash in agentic AI tools, whose potential for cyber risk is exponentially higher due to three core elements: hyperconnectivity, agency, and semantics.

Let’s take a closer look at how each one of these characteristics of AI tools helps create a broad attack surface that cybersecurity teams must secure.

Hyperconnectivity

You need to look at your organization’s landscape of autonomous AI tools and see it not as a collection of individual assets, but rather as a multi-agent system constellation, made up of many interwoven components.

Some of those components are internal, while others are external. Some were built in house, while others came from third-parties. Some live in the cloud, others on endpoints, and yet others on AI platforms.

Cybersecurity teams must not only detect all of those AI components, wherever they are, but also understand how they connect to each other and how they interact.

For example, an organization may have a Copilot Studio AI agent designed to summarize information fetched from the internet. But in this hypothetical setup, that agent also interacts with another agent, built on AWS Bedrock, that runs some of your critical processes in the cloud.

What if the Copilot Studio agent retrieves an indirect prompt injection from the internet, which in turn opens the door for an attacker to tamper with the critical cloud operations the AWS Bedrock agent has access to? Suddenly, what appeared as a straightforward agentic AI setup has revealed itself as a toxic combination with potentially catastrophic consequences.
 

Adding to the challenge, AI tools’ configuration plane is getting increasingly complex. This means that cybersecurity teams can’t be content with simply reviewing and approving AI products like Anysphere’s Cursor, Anthropic’s Claude Code, or Microsoft's Copilot in a vacuum.

Once an organization greenlights an AI tool for use, the IT department will start configuring them in a variety of ways and integrating them with internal systems, creating the risk for misconfigurations and insecure connections. Ask yourself: Where is the code written by an AI tool getting sent to? 

Moreover, do you know that tools like Claude Code and Cursor can be configured to operate in “agent mode,” which allows them to execute commands on endpoints, effectively behaving as full-blown autonomous agents?

Finally, the context of these AI tools changes quickly and constantly, as they ingest a growing amount and diversity of inputs that can make them vulnerable to malicious tampering.

Agency

Here’s a hard truth: We’re building systems that can act autonomously, but we’re securing them as if they can’t. And this is a problem because humans are rarely in the loop anymore when it comes to AI. On top of that, AI systems are not deterministic systems, like conventional IT ware, but rather probabilistic, meaning that their outputs are hard to anticipate. This is a tectonic shift for cybersecurity teams.

Chances are that the next major AI cybersecurity incident you have to deal with will not be caused by a breach, but rather by an action one of your AI systems was allowed to perform. 

Let’s look at this in more detail. There are three main components to AI agency:

• Goal: An AI agent is created to summarize news, emails or tasks.
• Capabilities: Often, the AI agent is able to perform certain actions that exceed the scope needed to accomplish the intended goal.
• Blast radius: This is everything that can go wrong if the AI agent’s capabilities are compromised.

The problem is that quite often an AI agent’s capabilities – the tasks it can perform – exceed the goals for which it was created. In other words, most AI agents possess too much agency. This disparity between capabilities and goals creates an oversized level of cyber risk.

Compounding the problem is the reality that organizations’ tendencies are to trust AI, meaning that the human oversight over these systems is usually minimal. 

Semantics

While traditionally in cybersecurity we rely on exact matches to assess that a system hasn’t been tampered with, this approach doesn’t work with AI systems, which operate on meaning, not strict syntax.

That’s why it’s easy for an attacker to bypass traditional guardrails by modifying the input the AI tool processes using synonyms, typos, paraphrases and other such language tricks. It’s extremely hard to monitor this vast and ever-expanding semantic attack vector and prevent model poisoning, output manipulation and prompt injection attacks. 

In other words, attackers don’t need to break the security controls anymore. They just need to go around them using semantics tactics.

How do you secure agentic AI?

Historically, cybersecurity strategies have been focused on reactive breach detection and response. However, to protect your AI agents, it’s critical to shift to a preventive, proactive approach grounded on exposure management. That way, you’ll be able to understand AI agents’ dynamic systems and what they can do in runtime, as well as fix the misconfigurations and gaps before attackers exploit them.

To achieve effective agentic AI governance and security, you need to ground your exposure management strategy on three foundational concepts:

Visibility

You must inventory all the AI agents in your environment, as well as their individual components, wherever they are – on endpoints, in the cloud, in AI platforms and on-premises.

But you must go deeper. You need to also know the following about each agent: 

• The data it was trained on, the knowledge base it feeds off of and the data stores it’s connected to.
• The capabilities it possesses, such as the actions it can take and the agentic protocols that govern it.
• The connections it has to other systems both internally in your organization and externally; to other AI agents; and to AI and non-AI user identities.
• Its intent, such as its goals, along with its blast radius

Posture

You must understand what an AI agent can do as part of a broader dynamic system, as well as how its capabilities exceed its goals, so that you can adjust what it’s allowed to do without impacting its efficacy.

Let’s say you have multiple AI agents that are integrated and interact with each other, and these agents can, for example, connect to the internet and to your most sensitive cloud environment. It’s imperative to understand what this dynamic multi-agent system can do in the real world, in order to spot any potential toxic combinations within its components.

With these insights, you can pinpoint remediations to the security gaps created by the AI toxic combination.

Threat detection

Once you understand what this dynamic multi-agent cluster can do, you need to be able to spot trouble signals in your runtime environment for ongoing exposure reduction.

Conclusion

AI security needs to be everywhere in your environment, and the way to make AI security pervasive is by adopting an exposure management platform and strategy. . 

In a nutshell, exposure management empowers cybersecurity teams to discover every asset across your environment – not just AI systems, but also IT, cloud, identity, and OT wares. From there, it helps you assess, prioritize and orchestrate remediation across the entire AI attack surface, giving you control over this new landscape of AI agents populating your environment.

To learn about how Tenable can help you boost your AI security, visit the Tenable One AI Exposure page.

NIST’s shift toward selective CVE enrichment creates significant visibility gaps for teams relying solely on the National Vulnerability Database. As AI accelerates vulnerability disclosure rates, organizations need independent, high-fidelity intelligence to prioritize risks that the NVD may now overlook.

Key takeaways

1. NIST is pivoting to a prioritized enrichment model, focusing only on specific criteria like the CISA KEV catalog and federal software, which leaves a growing backlog of unenriched vulnerabilities.
2. Tenable remains unaffected by these changes because it doesn’t depend on the NVD to develop checks and scoring metrics.
3. Contextual intelligence is now a requirement for survival, as Tenable identifies significantly more "exploited in the wild" vulnerabilities and provides quick identification of known exploited vulnerabilities.

The National Institute of Standards and Technology (NIST) will no longer attempt to enrich all CVE entries in the National Vulnerability Database (NVD). The decision, announced last week, is bad news for organizations that depend entirely or primarily on the NVD for vulnerability metrics. It’s also a negative for organizations whose vulnerability scanning program relies on the Common Platform Enumeration (CPE) enrichment that is included in the NVD records.  

Instead, NIST said it will prioritize for enrichment the CVEs that meet the following criteria: 

• CVEs appearing in CISA’s Known Exploited Vulnerabilities (KEV) Catalog
• CVEs for software used within the federal government
• CVEs for critical software as defined by the 2021 Executive Order 14028

NIST’s decision was driven by the skyrocketing number of published CVEs, a years-long trend that is expected to continue to intensify, as AI accelerates the pace of vulnerability discovery and disclosure. In 2025, the annual record was broken again with more than 40,000 published CVEs. About two years ago, NIST acknowledged that it was struggling to enrich all CVEs, leading to a big backlog.

What does this mean for Tenable customers?

We have written in the past about previous delays in NVD enrichment and about the concerns raised when the CVE program was at risk of losing funding. As was true then, Tenable does not depend on NVD for scoring metrics or for developing checks for vulnerabilities. We have developed our own internal Vulnerability Intelligence Database which drives our internal prioritization and content. This database is also available in our products to help customers better prioritize remediation efforts and understand the full context required to understand the risk presented by a new vulnerability.

From our vulnerability intelligence we can also better understand some of the implications of this prioritization strategy and where the gaps might become problematic. While the CISA KEV is a great resource, its more limited scope and selection criteria means that some exploited vulnerabilities do not make the list. Specifically, based on our own intelligence, we track an additional 355 vulnerabilities as exploited in the wild -- 1,924 compared to the CISA KEV’s 1,569 currently.  Additionally, we have a median lead time of 3.2 days for identifying known exploited vulnerabilities. When time-to-exploit is measured in days or even hours, rather than weeks, 3.2 days can make a significant difference in staying ahead of attackers.

Additionally, because we develop our vulnerability coverage directly from vendor advisories rather than depending on NVD or MITRE, we’re able to deliver accurate and timely checks for emerging vulnerabilities.  This data also helps to build out our vulnerability intelligence so that we have comprehensive contextual data that would typically be pulled from NVD – data such as CVSS metrics, valuable references, and affected products and fixed versions.

What the NVD delays mean for security teams

Ongoing dependence on NVD for vulnerability data has always had its limitations given existing delays. While NIST’s new CVE-enrichment strategy aims to take a risk-centric approach, we can see that there are likely to be critical gaps – and those gaps create real risk for security teams. 

Thus, as the pace of vulnerability disclosures and real-world exploitations accelerates, further fueled by AI, security teams must have access to a reliable source of contextual intelligence to make the rapid, informed prioritization decisions necessary to protect their environments.
 

Tenable Vulnerability Management's vulnerability database search interface

With Tenable’s Vulnerability Intelligence, it is possible to quickly understand the real world risk that a vulnerability presents based on available proof of concept data, evidence of real world exploitation, association with ransomware, and many other critical data points. Vulnerability Intelligence is available in Tenable Vulnerability Management,Tenable Security Center and Tenable One.

Additionally, that same contextual data is incorporated into Tenable Cloud Security and the Tenable One Exposure Management Platform enabling teams to quickly focus on the highest risk vulnerabilities.  Tenable One compiles a comprehensive asset inventory of your environment, allowing you to check which of your applications have, for example, a recently disclosed zero-day vulnerability.  Because Tenable One brings together all of the data from multiple sensors into a single unified view, it can help you understand important context like account privileges, external exposure, asset properties, attacker pathways, and more.  In short, Tenable One gives you full visibility across your entire infrastructure, helping you understand where your organization is exposed, and prioritize remediation based on which targets present the most significant risk.

Meanwhile, Tenable’s Vulnerability Prioritization Rating (VPR) wraps all of this contextual data up into a score that can be used for prioritization based on either the numeric score or the risk rating (low, medium, high, critical). VPR uses machine learning algorithms to predict the likelihood of exploit activity in the subsequent 28 days and incorporates threat intelligence, vulnerability characteristics, and insights from the Tenable Research Special Operations team to pinpoint the critical 1.6% of vulnerabilities that represent actual risk. By joining the contextual data about the vulnerabilities with the Asset Criticality Rating (ACR) of affected assets, you can quickly go from triage to informed prioritization and remediation action, reducing the risk of exploitation.

Learn more

• “Why Early Visibility Matters: Risk Lurks in the Vulnerability Disclosure Gaps”
• “Study: Tenable Offers Fastest, Broadest Coverage of CISA's KEV Catalog”
• “Mind the Gap: How Waiting for NVD Puts Your Organization at Risk”

AI is uncovering vulnerabilities at a scale that will overwhelm legacy defenses. Here is how to build a security organization that is Mythos ready.

Key takeaways

1. While frontier AI models like Claude Mythos boost cyber defenses, they also empower attackers to discover and weaponize vulnerabilities at unprecedented machine speed.
2. To avoid getting buried by an avalanche of AI-discovered vulnerabilities, organizations must prioritize ruthlessly by shifting from legacy scoring to a risk-based filtering approach that focuses on attack paths.
3. Achieving “Mythos-ready” status requires implementing automated, agentic detection and remediation, as well as continuous adversarial validation to match the velocity of modern AI-driven threats.

Tenable is collaborating closely with Anthropic, OpenAI and other AI leaders as we integrate advanced AI into our Tenable One Exposure Management Platform, accelerating vulnerability research, remediation automation, and proactive cyber defense. In our recent discussions with these frontier AI model providers, one thing has become clear: the models are a game-changer on multiple fronts. They can identify vulnerabilities in open-source code and complex enterprise environments that have eluded human researchers for decades.

However, this breakthrough presents a paradox. While models like Anthropic’s Claude Mythos and OpenAI’s GPT accelerate our ability to defend, they simultaneously upgrade the capabilities of bad actors, allowing them to discover and weaponize flaws at machine speed. They also threaten to bring to light orders of magnitude more vulnerabilities that need to be prioritized and remediated. 

The attack surface has expanded. It’s no longer just about traditional infrastructure, but about the model access controls, identity entitlements, and operational workflows that surround the AI itself. Whether an attack utilizes an AI-discovered zero-day or targets the AI training pipeline directly, the challenge remains the same: you can’t manage what you don’t see, and you can’t defend what you don’t prioritize.

To thrive in the LLM era, here are the five key actions to take today:

1. Establish continuous, deterministic asset discovery

You can’t find vulnerabilities in assets you haven’t discovered. Organizations must implement a foundation of deterministic sensors (scanners, agents, and passive monitors) to maintain a real-time inventory of every digital asset. And with rapid AI adoption across the world's enterprises, it’s essential to have visibility into all your AI inventory, shadow and sanctioned.

Unlike the probabilistic nature of frontier AI, which can be inconsistent, your discovery must be deterministic. You need an auditable record of what is on your network to provide the "ground truth" required for compliance and risk reporting.

2. Move beyond legacy prioritization to ruthless risk filtering

With Mythos-driven discovery, the volume of vulnerability disclosures is expected to grow by orders of magnitude in the near term. Standard tools like CVSS or EPSS, which only measure theoretical severity or probability, will cause your team to drown in noise.

A Mythos-ready program uses machine learning to narrow the "60% critical" flood down to the 1.6% of vulnerabilities that create actual risk. By cross-referencing AI-discovered flaws with attack paths and business criticality, you ensure your team is fixing the holes that actually lead to your crown jewels, including the AI models themselves.

3. Neutralize toxic combinations via attack path analysis

Attackers don't look at vulnerabilities in isolation. They look for a path. They chain together a minor software flaw, a misconfigured cloud bucket, and an excessive identity permission to reach their target. In the AI era, exposure management is about identifying these "toxic combinations" before an adversary does.

The rapid growth of AI infrastructure means new attack paths form every day. And the intersection of poorly-configured AI infrastructure and traditional IT infrastructure creates powerful weaknesses that can be exploited.

Use attack path analysis to visualize how an attacker might use an AI-accelerated exploit to breach your perimeter and move laterally toward your AI training data or inference engines. If you close the path, the vulnerability becomes irrelevant.

4. Implement adversarial exposure validation (AEV)

When the "prompt-to-exploit" window shrinks from weeks to minutes, theoretical security is dead. You must implement Adversarial Exposure Validation (AEV), a continuous loop of automated red teaming.

By regularly challenging your environment against the MITRE ATT&CK framework, you gain evidence of how your defenses hold up against AI-speed exploits. This is the only way to ensure your incident response plan isn't just a document, but a proven shield against the reality of a Mythos-driven breach.

5. Govern AI exposure with agentic remediation

The fastest-growing risk surface in the world is the AI infrastructure itself: models, training pipelines, and autonomous agents with high-level access. These are now high-value targets requiring strict monitoring.

To match the speed of the threat, you must deploy agentic AI engines (like Tenable Hexa AI) to automate the triage and remediation of these exposures. This allows for "machine-speed defense" — using AI to discover, tag, and patch your infrastructure at the same velocity that Mythos is discovering its flaws.

The bottom line

The window to act is narrow. In our active conversations with the Office of the National Cyber Director, the Cloud Security Alliance and Anthropic, the consensus is clear that the lowest common denominator approach to security will no longer suffice. This reinforces the criticality of traditional cyber hygiene practices, while stressing the need to build automation and efficient systems into your program. Hope is not a strategy.

We must use the same principles of exposure management to handle the volume this increased discovery creates. See everything, prioritize ruthlessly, and remediate at machine speed. That is what it means to be Mythos ready.

To learn more about how Tenable can help, please also read Tenable CTO Vlad Korsunsky’s recent post “Claude Mythos: Prepare for your board’s cybersecurity questions about the latest AI model from Anthropic.”

Oracle addresses 241 CVEs in its second quarterly update of 2026 with 481 patches, including 34 critical updates.

Key takeaways:

1. The second Critical Patch Update (CPU) for 2026 contains fixes for 241 unique CVEs in 481 security updates
    
2. 34 issues (7.1% of all patches) were assigned a critical severity rating
    
3. Oracle Communications received the highest number of patches at 139, accounting for 28.9% of all patches
    

Background

On April 21, Oracle released its Critical Patch Update (CPU) for April 2026, the second quarterly update of the year. This CPU contains fixes for 241 unique CVEs in 481 security updates across 28 Oracle product families. Out of the 481 security updates published this quarter, 7.1% of patches were assigned a critical severity. High severity patches accounted for the bulk of security patches at 45.9%, followed by medium severity patches at 44.1%.

This quarter's update includes 34 critical patches across 22 CVEs.

SeverityIssues PatchedCVEsCritical3422High22199Medium212107Low1413Total481241Analysis

This quarter, the Oracle Communications product family contained the highest number of patches at 139, accounting for 28.9% of the total patches, followed by Oracle Financial Services Applications at 75 patches, which accounted for 15.6% of the total patches.

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

Oracle Product FamilyNumber of PatchesRemote Exploit without AuthOracle Communications13993Oracle Financial Services Applications7559Oracle Fusion Middleware5946Oracle MySQL343Oracle PeopleSoft217Oracle E-Business Suite188Oracle Analytics1511Oracle Retail Applications1515Oracle Siebel CRM1413Oracle Java SE117Oracle GoldenGate107Oracle Enterprise Manager98Oracle Virtualization91Oracle Database Server84Oracle Utilities Applications76Oracle Hyperion64Oracle Construction and Engineering43Oracle Life Science Applications43Oracle Supply Chain42Oracle Blockchain Platform32Oracle Commerce32Oracle JD Edwards33Oracle Adapter for Eclipse RDF4J22Oracle Autonomous Health Framework21Oracle REST Data Services22Oracle Systems21Oracle TimesTen In-Memory Database11Oracle Hospitality Applications11Solution

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

Identifying affected systems

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

Get more information

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

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

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

See how Tenable Hexa AI custom agents empower you to counter machine-speed threats by automating vulnerability remediation. Learn how the Model Context Protocol (MCP) automates execution of risk-driven patching workflows, shifting your strategy from reactive tracking to continuous exposure management.

Key takeaways

1. Even in previews, powerful AI models like Claude Mythos show us how quickly adversaries could weaponize newly discovered vulnerabilities. Traditional, manual patching cycles can’t keep up with machine-speed threats.
    
2. Tenable Hexa AI, the agentic engine of the Tenable One Exposure Management Platform, allows you to build custom agents to automate vulnerability prioritization and remediation at machine speed and scale.
    
3. Because Tenable Hexa AI uses the Model Context Protocol (MCP), it can function as the orchestration layer linking any LLMs you’re using to your other security tools. In other words, with Tenable Hexa AI, you can use an LLM to trigger vulnerability remediation workflows that leverage custom agents alongside your preferred patching tools to eliminate manual delays and accelerate risk reduction.

Frontier AI models like Anthropic’s Claude Mythos have demonstrated the potential to collapse the window between vulnerability discovery and exploitation from days to hours. In internal testing, Anthropic says Mythos Preview provided a fully functional exploit kit fully autonomously for a 17-year-old remote code execution (RCE) vulnerability within “several hours.”

In an environment where attackers operate at machine speed, traditional 30-day patch cycles and manual ticketing systems are not just slow, they’re a liability. 

As Tenable CTO Vlad Korsunsky recently wrote in a blog on Claude Mythos, closing your patch gap has never been more critical. Tenable Hexa AI is built to close this gap, accelerate exposure and vulnerability remediation cycles from human speed to machine speed, and automate a variety of complex, multi-step security tasks. 

The power of custom Tenable Hexa AI agents

In our first blog on use cases for the Tenable Hexa AI agentic engine, we showed how you can use Tenable Hexa AI to identify assets impacted by the Axios npm supply chain attack. While rapid identification and prioritization form the bedrock of exposure management, the sheer volume of modern threats requires teams to scale their response by automating mitigation for the specific risks that actually impact their environment.

Tenable Hexa AI enables you to build custom agents to automate workflows tailored to your unique environment. By utilizing the Model Context Protocol (MCP), Tenable Hexa AI securely connects large language models (LLMs) like Claude with your internal tech stack and execution tools. With this capability, you aren't just asking an LLM what is vulnerable; you’re mobilizing an agent to fix it.

Automating vulnerability prioritization and remediation with Tenable Hexa AI 

Let’s look at a real-world workflow where we use an LLM (in this case, Claude) combined with a custom Tenable Hexa AI agent to conduct automated patching and instantly accelerate risk reduction.

Step 1: Command the agent using natural language

The workflow begins in Claude with a natural language prompt:

“Use Tenable Vulnerability Management and Tenable Patch Management to identify and patch any critical VPR vulnerabilities on the asset, rsac-svr-2022” 

Tenable Hexa AI functions as the orchestration layer connecting your preferred LLM to your preferred patching tool, allowing you to trigger autonomous actions directly from your LLM.

Step 2: Prompt triggers agentic vulnerability prioritization

The prompt triggers the custom Tenable Hexa AI agent to immediately query Tenable, locate the specific asset, and filter the findings using Tenable’s Vulnerability Priority Rating (VPR). 

In contrast with other vulnerability scoring systems, like CVSS and EPSS, which score based on theoretical risk and probability of exploitation, the Vulnerability Priority Rating pinpoints the roughly 1.6% of vulnerabilities that actually pose an immediate risk to your organization based on real-world exploitability data and potential business impact.

By using the Tenable Vulnerability Priority Rating as a strict filtering criteria, custom agents can then trigger automated workflows exclusively for your most critical CVEs.

A simple prompt in Claude triggers a custom Tenable Hexa AI agent to carry out the command.

Step 3: Agent automates patch deployment 

Once the true priorities are identified, the Tenable Hexa AI agent directly triggers your patching tool of choice (in this example, Tenable Patch Management) to seamlessly deploy the fix to the asset, removing manual delays from the remediation cycle.

To deliver trusted execution alongside machine speed, the Tenable Hexa AI agent relies on Tenable’s Exposure Data Fabric, the industry’s richest repository of contextualized exposure data. The Exposure Data Fabric maps the interactions among vulnerabilities, identities, and assets to provide the deep environmental context that agents need to take safe, precise action. Limiting network changes strictly to material exposures earns the operational confidence from IT required to successfully scale automated VulnOps workflows.

With custom agents, you maintain total authority over the execution phase. You can build specific human-in-the-loop (HITL) checkpoints directly into the agent’s logic — choosing exactly when to unleash full automated execution and when to require a strategic manual sign-off — allowing you to confidently close the exploit window without risking operational disruption.

The custom Tenable Hexa AI agent automates patch deployment, eliminating manual delays.
 

Scaling vulnerability remediation efforts with agentic AI 

The economics of cyberattacks have fundamentally shifted. With high-level exploits now costing attackers under $2,000 and taking less than one day to develop, the accelerating volume of AI-discovered vulnerabilities will quickly overwhelm even the most well-resourced security teams. To survive, defenders must shift their economics, too. 

Tenable Hexa AI acts as the crucial force multiplier to make that shift possible. By integrating custom AI agents into your security workflows, you reduce the “cost per remediation.” This empowers a single analyst to automate repetitive tasks, efficiently triage patches, and manage exposures at a scale.

Ultimately, establishing these automated remediation pipelines allows defenders to operate at machine speed without burning out. You successfully transition your strategy from reactive tracking to proactive exposure management, permanently closing the gap between how fast vulnerabilities are found and how fast your organization can respond.

Ready to build your own custom automated workflows and beat the exploit clock?

Tenable Hexa AI is currently in private preview for select Tenable One customers. 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.

Stop managing risk in silos. VM-Native OT Discovery, now available in Tenable Vulnerability Management and Tenable Security Center provides unified visibility across IT and OT domains. See every asset and manage your total cyber exposure in a unified view.

Key takeaways

1. The air gap is dead. IT security teams are inheriting responsibility for operational technology (OT), but often lack visibility into these systems.
    
2. Security teams face significant barriers with OT security. Fear of disrupting fragile devices and the high cost of specialized hardware have created a dangerous "black box" in the attack surface.
    
3. The perfect “on-ramp” to OT security. A new OT Discovery engine embedded in Tenable Vulnerability Management and Tenable Security Center allows security teams to safely profile OT, IoT, and shadow IT assets using the tools they already own.

For decades, the concept of the "air gap" — a physical isolation between IT networks and critical operational technology (OT) — provided security leaders with a sense of comfort. The assumption was simple. Digital threats stay on the corporate network, while physical operations run safely in isolation.

In today's hyper-connected world, that assumption is often wrong and leaves your OT environment exposed to preventable cyber risk.

From modern data centers and smart hospitals to commercial real estate and universities, the line between the digital and the physical has blurred. IT security teams are increasingly inheriting responsibility for securing cyber-physical systems (CPS) — the HVAC controllers keeping servers cool, the badge readers securing facility entrances, and the power distribution units keeping the lights on.

Yet, for many organizations, these OT assets are a massive blind spot.

The "black box" problem

While vulnerability management programs have matured rapidly for IT assets, covering everything from cloud workloads to laptops, operational environments are often a "black box."

This visibility gap usually stems from two distinct barriers:

• There is a pervasive (and historically valid) fear that scanning OT/IoT assets with traditional IT security tools could knock fragile devices offline, disrupting critical business operations.
   
• Traditional OT security tools often require a massive undertaking. The complexity and cost of deploying expensive specialized hardware, managing long-term evaluations, architecting complex mirror ports, and navigating the political minefield of installing new appliances in sensitive production environments make these projects difficult to justify.

The result is a dangerous paradox. Security teams are responsible for the risk of interconnected systems, but don’t have the tools to see or secure them. Attackers, however, face no such barriers, frequently pivoting from compromised IT networks to poorly defended OT assets to maximize impact.

Rethinking converged OT/IT security

To secure the modern attack surface, organizations must stop managing IT and OT risk in silos. Security leaders need a unified view that treats a vulnerability on a programmable logic controller (PLC) with the same rigor and context as a vulnerability on a Windows server.

Achieving this requires a fundamental shift in how we approach asset discovery. Security teams need streamlined methods that provide the necessary depth of OT visibility for compliance and risk reduction, without the friction of deploying hardware across physical sites. They need a way to safely seeshadow OT assets using the infrastructure already in place.
 

Image: A segment of Tenable’s research and testing lab for operational technology (OT).

Introducing VM-Native OT Discovery

Our latest release fundamentally changes the economics and accessibility of OT security tools. We are excited to announce OT Discovery, a new capability embedded directly inside the Tenable One Exposure Management Platform that provides security teams with foundational visibility into OT and IoT environments. It’s the perfect on-ramp to OT security, so you can uncover hidden OT risks and deep asset-level details. 

Here is how it changes the game for your security program:

• Safe visibility for cyber-physical systems. OT Discovery uses the same Active Query engine found in our specialized Tenable OT Security solution—now natively integrated into Tenable Vulnerability Management and Tenable One. It performs "smart," protocol-aware handshakes to verify assets before querying them so you can safely profile PLCs, human-machine interfaces (HMIs), IoT devices, and shadow IT assets across your environment.
   
• Unified OT/IT exposure management. By integrating OT asset data, including vendor, model, and firmware details, directly into your existing dashboards, you can break down silos and view your organization's total risk exposure in a single pane of glass.
   
• Extend the value of your security investments. No need to rip and replace or install new hardware. This capability enables you to extend the value of your existing vulnerability management toolsets to uncover the OT risk hiding on your network.

Breaking down silos across IT and OT

Adopting a unified approach to OT/IT exposure management builds trust.

Historically, the relationship between IT security and facility operations teams has been strained. IT wants to scan and patch known vulnerabilities. Operations teams require uptime and stability. When IT security teams try to enter the OT space with aggressive scans or unfamiliar hardware, friction is inevitable.

VM-Native OT Discovery changes the conversation. Because Tenable relies on trusted, safe query methods through familiar infrastructure, the security team can approach the ops team with reliable data and real-time exposure intelligence.

Instead of asking, "Can we install a black box on your network?" you can say, "We noticed three unmanaged PLCs communicating on the subnet. Here is exactly what they are. Let’s work together to secure them now rather than waiting 6-12 months to patch during the next maintenance interval."

Get started with OT security today

OT security is no longer just for industrial giants and organizations managing critical national infrastructure. Every manufacturer, warehouse operator, and organizations smart building management systems face operational risk.

Ready to get visibility into your OT blind spots? You don't need a massive budget or a year-long deployment project to get started. Watch this quick demo to see how you can secure your most critical assets with the vulnerability management tools you already use.
 

Are you an existing Tenable customer? Explore the user guide documentation for Scan Templates and Discovery Settings to get started.

Learn more

• Dive deeper into the challenges and solutions for securing OT with our eBook, “Blackbox to blueprint: A security leader’s guide to managing OT and IT risk.”
• Explore our complete Tenable One exposure management platform, offering scalable security solutions for the entire attack surface.
• Request a demo to find out how Tenable exposure management solutions fit into your cybersecurity roadmap.

With the Federal Reserve Chairman meeting with bank CEOs to discuss the security implications of Claude Mythos, you can bet that your board of directors will ask you about the impact of the AI model on your cybersecurity strategy. Here’s how to prepare. 

Key takeaways

1. Anthropic announced Claude Mythos Preview, its most powerful general-purpose frontier model to date, and highlighted its exceptional ability to find software vulnerabilities that no human vulnerability research had previously discovered.
    
2. With Claude Mythos continuing to dominate traditional news and social media, your board of directors will have questions for you about the impact of the new AI model on your cybersecurity strategy and risk posture.
    
3. As the pace of vulnerability discovery accelerates with the use of frontier models like Claude Mythos, exposure management can help organizations quickly, continuously, and autonomously assess if they’re impacted by these vulnerabilities, evaluate the risk they pose, and orchestrate remediation. 

On April 7, 2026, Anthropic unveiled Claude Mythos Preview, its most powerful frontier model to date and one that excels at cybersecurity tasks, specifically, vulnerability discovery in code. (I previously wrote about Claude Opus 4.6 and its impact on cybersecurity.)

I’ll spare you the details of the decades-old, zero-day vulnerabilities that Claude Mythos proved capable of finding and exploiting in internal testing, as I’m sure you’re already aware. But suffice it to say the model was so powerful, Anthropic thought it prudent to assemble a group of technology partners in an initiative called Project Glasswing to apply Mythos’ capabilities to defensive security.

And now, with Federal Reserve Chairman Jerome Powell meeting with leaders of the largest U.S. banks to discuss the cybersecurity implications of this mythic new model, you can bet that your board of directors and executive management team will have questions for you about Claude Mythos at the next quarterly meeting — or sooner. 

We’re here to help you provide answers. 

The question every board will ask about Claude Mythos

When it’s time for your 15-minute cyber update, your board of directors will inevitably ask you, “What are you doing about Claude Mythos? How are you preparing for a world in which AI-assisted attackers can find and exploit vulnerabilities in minutes?”

Essentially, your board-friendly answer needs to be, “We’re fighting fire with fire. We’re transforming our security operations with agentic AI so that we can autonomously and preemptively find and fix our exposures at machine speed.” You can then report on the number of security workflows you’ve automated with AI and the increases in efficiency and effectiveness that you’re achieving as a result.

Depending on your board’s security savvy, you may need to address how you’re evolving your vulnerability management function to handle this new reality of AI-driven vulnerability discovery. 

One new approach that forward-leaning security leaders have begun implementing is exposure management, or CTEM. 

What is exposure management? 

Exposure management is a strategic approach to preemptive security designed to reduce cyber risk. It continuously assesses, prioritizes, and remediates your organization’s most critical cyber exposures. Cyber exposures are toxic combinations of preventable cyber risks (such as vulnerabilities, misconfigurations, and excessive permissions) that give threat actors a path to your most sensitive systems and data.

By continually and agentically assessing, prioritizing, and remediating risks, exposure management provides the answer to the question of how to build a “Mythos-ready” security program. It offers the solution to the single biggest challenge associated with AI-vulnerability discovery: how security and remediation teams will address the massive backlog of findings that AI-assisted vulnerability discovery will create. 

Exposure management is a “Mythos-ready” security program

To understand the role exposure management plays in a world flooded with AI-driven vulnerability discoveries, it’s important to understand the difference between frontier models and exposure management solutions. 

What frontier models do: Claude Code Security and Mythos Preview read and reason about source code. They identify logic flaws, memory corruption vulnerabilities, injection weaknesses, and authentication bypasses by tracing data flows and understanding how software components interact. Mythos does this with extraordinary autonomy and can chain vulnerabilities into working exploits. Fundamentally, this is application security: static and dynamic analysis of codebases operating at the source-code layer.

What exposure management does: Exposure management allows you to discover every asset across your environment (IT, cloud, identity, AI, and OT); determine whether they’re vulnerable; prioritize exposures based on business and technical context; orchestrate staged remediation; and validate that fixes are closed. An individual vulnerability may not appear dangerous until it forms an attack chain leading to a critical system. Exposure management helps you see individual vulnerabilities in context and how they combine to create high-risk attack paths.

Bottom line: Frontier models and exposure management operate in categorically different domains and solve fundamentally different problems. 

Exposure management and the preemptive security lifecycle

To put a finer point on the difference between frontier models and exposure management, let’s examine the complete preemptive security lifecycle that enterprises require. Frontier AI — even at Mythos-class capability — addresses only the first stage of this lifecycle. Exposure management addresses everything else.

Stage 1 — Software vulnerability discovery. Identifying that a flaw exists in software. This is where frontier models excel. Mythos has demonstrated extraordinary capability here, finding bugs that survived decades of human review and millions of automated test runs. This capability is genuine and consequential.

Stage 2 — Asset discovery. Employing multiple discovery methods, including scanners, agents, OT-specific sensors, and more, to identify every asset in an enterprise: endpoints, servers, cloud workloads, containers, network devices, OT/ICS assets, identity objects, AI applications, MCP servers. This is something Mythos can’t do.

Stage 3 — Assessment. Determining whether specific deployed assets are affected by specific vulnerabilities. This requires deep interrogation of the asset: connecting to live systems, parsing configurations, checking patch levels, inspecting running services across IT, cloud, OT, and identity environments at enterprise scale — and doing so without impairing the performance of the live asset. A model that found a Linux kernel vulnerability cannot determine which of an organization's 50,000 Linux hosts are running the affected version without sensor-level access.

Stage 4 — Prioritization. This stage becomes more critical, not less, in an AI-accelerated world. When frontier models can discover thousands of new vulnerabilities in weeks and generate working exploits on demand, the volume flowing into the remediation pipeline explodes, but the operational constraints don’t change. Enterprises still have finite maintenance windows, change management processes, compatibility dependencies, and business continuity requirements. Patching 40,000+ CVEs simultaneously across 100,000 assets is not operationally feasible. The math only works with the intelligent prioritization that exposure management provides.

4 steps to building a Mythos-ready security program: How Tenable can help

In a recent blog, Anthropic offered several recommendations to prepare your security program for an AI-accelerated offense. Here’s how Tenable can help you strengthen your organization’s cybersecurity posture and reduce your risk in the age of AI-driven attacks: 

1 - “Close your patch gap.” Anthropic says to patch everything in the CISA KEV immediately, use EPSS to prioritize the rest, and automate deployment. In theory, this advice makes sense. In practice, it’s a bit misguided. 

For one thing, even if you patched everything in the CISA KEV immediately, you’d still have gaps. The CISA KEV catalog operates off of strict inclusion criteria, so just because a CVE hasn’t landed in the KEV doesn’t mean it’s less critical. On the contrary, Tenable Research has tracked 201 CVEs that weren't part of the KEV, but that could impact customers due to the hardware or software they affect. The Citrix Session Recording Vulnerability (CVE-2024-8069) provides an example of a CVE that Tenable Research began watching nearly a full year (286 days) before it hit the KEV. (Editor's note: This paragraph was updated on April 24, 2026 to clarify that Tenable Research has tracked 201 CVEs that were not part of the KEV due to their potential impact to customers.) 

Then there’s the issue of prioritization. With the vulnerability discovery capabilities of Mythos falling into the wrong hands, the number of vulnerabilities could grow by 10X or more. As Tenable Co-CEO Steve Vintz pointed out in a recent LinkedIn post, “Prioritization is no longer optional. It’s survival.” 

But prioritizing based on EPSS alone will leave you chasing your tail. EPSS prioritizes based only on probability of exploitation. In contrast, Tenable One provides much finer-grained prioritization than both EPSS and CVSS. Through the proprietary Vulnerability Priority Rating (VPR), Tenable uses machine learning to narrow the 60% of CVEs flagged as critical or high by CVSS to the 1.6% that create actual risk for your organization. Tenable One additionally factors other criteria into its prioritization engine, including reachability (is this asset actually exposed through the network topology?), identity context (what permissions does a compromised asset inherit? does it create a path to domain admin?), business criticality (is this a revenue-generating system or a development sandbox?), and attack path analysis. Answering those questions requires cross-domain telemetry at a scale and specificity that no external model possesses and that only Tenable One can provide.

Finally, more vulnerabilities means more to patch, even as your patching constraints remain the same: you still have to sort through compatibility dependencies and business continuity requirements, among other things. Tenable One gives you the speed, scale, automation, and control to manage your entire update lifecycle. You can deploy autonomous patching across 20,000+ products and 250,000+ unique patches spanning Windows, Linux, and macOS while using customizable controls to test patches and prevent deployment of problematic updates. 

And our newly announced agentic AI engine, Tenable Hexa AI, will automate asset discovery, tagging, triage, prioritization, and remediation workflows so that your organization can keep pace as vulnerability discovery escalates. 

2 - “Prepare for much higher vulnerability volume.” Tenable has a proven track record when it comes to developing and releasing plugins to identify new vulnerabilities. We deliver over 100 new plugins each week and, because we use AI to accelerate the speed and scale of plugin development, in general, we can deliver fully automated plugin coverage within 12 to 24 hours. 

When a plugin assesses whether a server is missing a specific patch, it returns a clear, binary, deterministic answer (yes or no) with six-sigma accuracy (0.32 defects per million scans). This precision underpins every downstream decision: whether to open a remediation ticket, whether to take a production system offline, whether to report a finding to an auditor, whether to trigger a staged patch deployment.

In contrast, frontier AI models are probabilistic by design. Anthropic's own documentation for Mythos reveals the model occasionally attempts to conceal its methods, circumvent sandboxes, and produce inconsistent outputs. Running the same prompt twice can yield different results. For code-level security research, this variability is tolerable — a human researcher reviews and validates findings. But for operational vulnerability management at enterprise scale, where tens of thousands of assets are assessed continuously and findings flow directly into compliance reporting and remediation workflows, probabilistic output is not acceptable.

Compliance frameworks like SOC 2, FedRAMP, PCI-DSS, HIPAA, and FISMA require reproducible, auditable assessment results. Cyber insurance underwriters require them. Board-level risk reporting requires them. 

The deterministic scanning foundation that Tenable has built over 24 years — with more than 318,000 plugins — is not a legacy artifact. It’s a structural requirement of the market Tenable serves.

3 - “Reduce and inventory what you expose.” Tenable One sensors — scanners, endpoint agents, passive network monitors, web application scanners, OT-specific sensors, identity directory connectors, and cloud API integrations — are designed to discover every asset across live enterprise environments and deterministically assess whether deployed systems are vulnerable. The Tenable One platform then prioritizes exposures based on runtime exploitability context, orchestrates staged remediation, and validates that fixes are closed. Tenable's sensors continuously discover assets across environments that are heterogeneous, distributed, and often air-gapped. We can even assess your shadow AI footprint. A model cannot discover what it cannot reach.

4 - “Design for breach.” The attack path analysis capabilities of Tenable One provide visibility into how threat actors chain together vulnerabilities, misconfigurations, and excessive permissions to reach your critical assets. This attack path mapping enables you to proactively close those gaps and preemptively disrupt the attacker’s journey. 

Tenable One can also help you implement zero trust by mapping assets and identities across your environment, showing how they’re connected, and where trust boundaries are. It also adds governance for your fastest growing risk surface: AI agents with admin-level access. 

Navigating the new era of AI-driven risk

The arrival of Claude Mythos marks a fundamental shift in the cyber landscape, where the speed of vulnerability discovery is now measured in minutes rather than months. While this “mythic” new model provides attackers with an unprecedented ability to find and chain exploits, it also serves as a catalyst for organizations to modernize their defense.

To stay ahead, security leaders must move beyond traditional methods and embrace exposure management. By integrating the deterministic precision of Tenable One with the automated power of Tenable Hexa AI, your organization will be able to transform its security operations into an agentic, preemptive force capable of moving at machine speed.

Don't let the coming flood of AI-generated vulnerabilities overwhelm your team. By focusing on intelligent prioritization, closing your patch gaps, and gaining full visibility into your attack paths, you can confidently answer your board’s toughest questions and build a truly “Mythos-ready” security program.

Forward-Looking Statements

This blog post contains "forward-looking statements" within the meaning of the federal securities laws, including statements regarding the potential impact of LLMs like Mythos on the cybersecurity landscape and our expectations for the future of Exposure Management. These statements involve risks and uncertainties that could cause actual results to differ materially, including the risks and uncertainties described in our most recent Annual Report on Form 10-K and other SEC filings from time to time. All forward-looking statements in this blog post are based on information available to Tenable as of the date of this post. Tenable assumes no obligation to update any forward-looking statements contained in this post.

Learn more

• What is Exposure Management
• Attack Path Analysis
• Attack Surface Management
• Tenable Patch Management
• Cyber Hygiene Best Practices

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

Microsoft addresses 163 CVEs in the April 2026 Patch Tuesday release, including two zero-day vulnerabilities, one of which was exploited in the wild.

Microsoft patched 163 CVEs in its April 2026 Patch Tuesday release, with eight rated critical, 154 rated as important and one rated as moderate. This is the second largest Patch Tuesday release, nearing the record set by the October 2025 Patch Tuesday release with 167 CVEs. Our counts omitted two non-Microsoft CVEs from this month's release.

This month’s update includes patches for:

• .NET
• .NET and Visual Studio
• .NET Framework
• .NET,.NET Framework, Visual Studio
• Applocker Filter Driver (applockerfltr.sys)
• Azure Logic Apps
• Azure Monitor Agent
• Desktop Window Manager
• Function Discovery Service (fdwsd.dll)
• GitHub Copilot and Visual Studio Code
• Microsoft Brokering File System
• Microsoft Defender
• Microsoft Dynamics 365 (on-premises)
• Microsoft Edge (Chromium-based)
• Microsoft Graphics Component
• Microsoft High Performance Compute Pack (HPC)
• Microsoft Management Console
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office PowerPoint
• Microsoft Office SharePoint
• Microsoft Office Word
• Microsoft Power Apps
• Microsoft PowerShell
• Microsoft Windows
• Microsoft Windows Search Component
• Microsoft Windows Speech
• Remote Desktop Client
• Role: Windows Hyper-V
• SQL Server
• Universal Plug and Play (upnp.dll)
• Windows Active Directory
• Windows Admin Center
• Windows Advanced Rasterization Platform
• Windows Ancillary Function Driver for WinSock
• Windows Biometric Service
• Windows BitLocker
• Windows Boot Loader
• Windows Boot Manager
• Windows Client Side Caching driver (csc.sys)
• Windows Cloud Files Mini Filter Driver
• Windows COM
• Windows Common Log File System Driver
• Windows Container Isolation FS Filter Driver
• Windows Cryptographic Services
• Windows Encrypting File System (EFS)
• Windows File Explorer
• Windows GDI
• Windows Hello
• Windows HTTP.sys
• Windows IKE Extension
• Windows Installer
• Windows Kerberos
• Windows Kernel
• Windows Kernel Memory
• Windows Local Security Authority Subsystem Service (LSASS)
• Windows LUAFV
• Windows Management Services
• Windows OLE
• Windows Print Spooler Components
• Windows Projected File System
• Windows Push Notifications
• Windows Recovery Environment Agent
• Windows Redirected Drive Buffering
• Windows Remote Desktop
• Windows Remote Desktop Licensing Service
• Windows Remote Procedure Call
• Windows RPC API
• Windows Sensor Data Service
• Windows Server Update Service
• Windows Shell
• Windows Snipping Tool
• Windows Speech Brokered Api
• Windows SSDP Service
• Windows Storage Spaces Controller
• Windows TCP/IP
• Windows TDI Translation Driver (tdx.sys)
• Windows Universal Plug and Play (UPnP) Device Host
• Windows USB Print Driver
• Windows User Interface Core
• Windows Virtualization-Based Security (VBS) Enclave
• Windows WalletService
• Windows WFP NDIS Lightweight Filter Driver (wfplwfs.sys)
• Windows Win32K - GRFX
• Windows Win32K - ICOMP

Elevation of privilege (EoP) vulnerabilities accounted for 57.1% of the vulnerabilities patched this month, followed by information disclosure vulnerabilities and remote code execution (RCE) vulnerabilities at 12.3% each.

ImportantCVE-2026-20945 and CVE-2026-32201 | Microsoft SharePoint Server Spoofing Vulnerability

CVE-2026-20945 and CVE-2026-32201 are spoofing vulnerabilities affecting Microsoft SharePoint. CVE-2026-20945 received a CVSSv3 score of 4.6, while CVE-2026-32201 received a score of 6.5. According to Microsoft, CVE-2026-32201 was exploited in the wild as a zero-day. Microsoft has released updates for SharePoint 2016, 2019 and SharePoint Server Subscription Edition to address these flaws.

ImportantCVE-2026-33825 | Microsoft Defender Elevation of Privilege Vulnerability

CVE-2026-33825 is an EoP vulnerability in Microsoft Defender. It received a CVSSv3 score of 7.8 and was rated important. According to Microsoft, this flaw was publicly disclosed prior to a patch being made available. While Microsoft’s advisory made no mention of public exploit code, the description appears to match a zero-day exploit, known as BlueHammer, with code posted to GitHub on April 3rd. A researcher using the alias "Chaotic Eclipse" released the exploit and expressed concern about Microsoft’s handling of the vulnerability disclosure process.

CriticalCVE-2026-33826 | Windows Active Directory Remote Code Execution Vulnerability

CVE-2026-33826 is a RCE vulnerability affecting Windows Active Directory. It received a CVSSv3 score of 8, was rated as critical and was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index. Successful exploitation requires an authenticated attacker to send a specially crafted RPC call to a vulnerable RPC host, resulting in code execution with the same permissions as the RPC host. Despite the exploitation assessment and severity, the Microsoft advisory does note that an attacker would need to be in the “same restricted Active Directory domain as the target system” in order to exploit this flaw.

CriticalCVE-2026-33824 | Windows Internet Key Exchange (IKE) Service Extensions Remote Code Execution Vulnerability

CVE-2026-33824 is a RCE affecting Windows Internet Key Exchange (IKE) Service Extensions. It received a CVSSv3 score of 9.8 and was rated as critical. This vulnerability can be exploited by an unauthenticated attacker by sending crafted packets to a target with IKE version 2 enabled. Microsoft’s advisory includes some mitigations that can be applied in the event immediate patching cannot be performed. This includes firewall rules for UDP ports 500 and 4500.

ImportantCVE-2026-27913 | Windows BitLocker Security Feature Bypass Vulnerability

CVE-2026-27913 is a security feature bypass vulnerability affecting Windows BitLocker. It received a CVSSv3 score of 7.7 and was rated as important. Successful exploitation could allow an attacker to bypass Secure Boot, a UEFI firmware security feature used to allow only trusted and properly signed software runs during the startup process. While there’s no known exploitation of this vulnerability as of the time this blog was published, Microsoft assesses this vulnerability as “Exploitation More Likely.”

ImportantCVE-2026-26151 | Remote Desktop Spoofing Vulnerability

CVE-2026-26151 is a spoofing vulnerability in Remote Desktop. It was assigned a CVSS v3 score of 7.1 and rated important. Microsoft assesses this vulnerability as more likely to be exploited. An attacker could exploit this vulnerability by convincing a target to open a crafted file. This vulnerability was credited to the United Kingdom's National Cyber Security Centre (NCSC).

Previously, users would not receive any warning when attempting to open a Remote Desktop Protocol (RDP) file. However, starting with the April 2026 Security Update, users will now receive more sufficient warning dialogues when interacting with potentially malicious RDP files. For more information, visit this link.

Tenable Solutions

A list of all the plugins released for Microsoft’s April 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 April 2026 Security Updates
• Tenable plugins for Microsoft April 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.

See how you can use Tenable Hexa AI to determine in minutes if you’re impacted by the Axios npm supply chain attack. Learn how easy it is to automate configuration of scans, identify impacted assets, prioritize remediation, and more using agentic AI from Tenable.

Key takeaways: 

1. Tenable Hexa AI, the agentic engine of the Tenable One Exposure Management Platform, can tell you in minutes if your organization is running compromised versions of the Axios npm package following a recent discovery of a supply chain attack.
    
2. Tenable Hexa AI configures and launches scans; tags affected assets by severity, owner, or business unit to scope the blast radius of the threat; and automates remediation scans to verify remediation effectiveness.
    
3. The workflow that Tenable Hexa AI automates (targeted scan, tag, remediate, verify) applies to any emerging threat, whether the discovery of a new CVE, zero-day vulnerability, or supply chain compromise.
    

When a highly utilized code package like the Axios npm package is compromised in a supply chain attack, news of the compromise often sets off a mad scramble for security teams. Responding to the discovery can take days, and typically involves manually configuring different assessments to identify if vulnerable versions of the software are present in your environment, and if so, which assets are affected by them. Then, of course, you have to implement recommended remediations, which in the case of the Axios npm supply chain attack include:

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

Even if you can respond and remediate within hours, it’s still not fast enough for AI-assisted threat actors. These days, we need to answer three critical questions in minutes: 

• Are we exposed?
• Where are we exposed?
• How quickly can we mitigate the threat? 

In the first of a series of blogs on use cases for the Tenable Hexa AI agentic engine, we show you how Tenable Hexa AI accelerates this exact workflow to reduce your window of risk.

Using Tenable Hexa AI to discover the Axios threat and answer “Are we exposed?”

When researchers discover a new zero-day or supply chain compromise, the first question on security teams’ minds isn’t “How do we fix it?” It’s “Are we affected?” Answering that question shouldn’t be difficult, and with Tenable Hexa AI, it couldn’t be simpler. 

Open Tenable Hexa AI and type something like, “Show me all assets in my environment vulnerable to the Axios Supply Chain vulnerability.”

Tenable Hexa AI then queries the Tenable One Exposure Data Fabric, the data already collected from your existing scans, agents, and integrations. Within seconds, Tenable Hexa AI produces a clear picture of which assets are running the compromised Axios versions, where they sit in your network, and how critical they are to your business. 

No query language. No console-hopping. No waiting for a new scan to finish. Just ask the question and get the answer. 

Using Tenable Hexa AI to scope the blast radius with asset tagging

Now you know which assets are affected, but a flat list isn’t a response plan; it’s a starting point. The next step is to scope the blast radius and organize it for action. With Tenable Hexa AI, this is as simple as telling Tenable Hexa AI to “Tag this with the category Supply Chain and value Axios.” 

Tenable Hexa AI then bulk-applies the tag across every asset in one action. And just like that, you’ve turned a raw discovery into a structured, queryable incident surface. 

This matters because tagging is the bridge between exposure discovery and remediation by the right team. Once assets are tagged, you can slice them by business unit or owner to route remediation work. You can feed tagged assets into dashboards for executive visibility, and critically, the tag preserves a snapshot of the blast radius as the environment changes. 

Why this capability matters beyond Axios

Supply chain attacks have seen a staggering increase in recent years, with the Sonatype 2024 State of the Software Supply Chain report showing a 156% year-over-year surge in attacks targeting upstream repositories like npm and PyPI. So the question isn’t if another package will be poisoned, but how much of your weekend it will consume when it happens.

What we’ve shown here with the Axios response (i.e., scope, discover, prioritize) is more than just a fix for one npm package. It represents a fundamental shift in how security teams handle emergency response. 

By using Tenable Hexa AI, you are building agentic and operational muscle memory. You can deploy the exact same conversational workflow you used to hunt for malicious versions of Axios the moment the next Log4j, XZ Utils, or MoveIt-style vulnerability hits the news.

Tenable Hexa AI transforms high-pressure fire drills like the discovery of the Axios npm supply chain attack into a structured, repeatable, and sane workflow. Instead of writing custom scripts or manually configuring policies under duress, you simply tell Tenable Hexa AI what to do, and the agentic engine handles the grunt work for you. 

Use cases for agentic AI: Additional ways to use Tenable Hexa AI 

Stay tuned for more use cases demonstrating the agentic power of Tenable Hexa AI. Here’s what’s coming next: 

• Using Tenable Hexa AI to target remediation scans at tagged assets, schedule post-patch verification, and compare before/after results to confirm the threat is neutralized
• Using Tenable Hexa AI to automate the creation of risk dashboards and report on security KPIs
• Using Tenable Hexa AI to map vulnerabilities to asset owners (via Okta, CMDB, or custom mappings) and automatically notify the right teams.
• Using Tenable Hexa AI to trigger patching workflows and network isolation for compromised assets

Tenable Hexa AI is currently in private preview for select Tenable One customers. 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.

An Iran-affiliated threat group has evolved from defacing water utility displays to deploying custom ICS malware and exploiting Rockwell Automation PLCs across multiple U.S. critical infrastructure sectors.

Key takeaways:

1. CyberAv3ngers is a state-directed threat group operating under Iran's IRGC Cyber-Electronic Command. The U.S. Treasury sanctioned six named officials in February 2024 and the State Department has offered a $10 million bounty for information on the group's activities.
    
2. The group has escalated from exploiting default credentials on Israeli-made PLCs (2023) to deploying a custom ICS malware platform called IOCONTROL (2024) to actively exploiting CVE-2021-22681, a critical authentication bypass in Rockwell Automation controllers, across U.S. water, energy, and government facilities (2026). There is no vendor patch for this vulnerability; only defense-in-depth mitigations are available.
    
3. A six-agency joint advisory (CISA AA26-097A) issued on April 7, 2026, confirmed operational disruption and financial loss at multiple U.S. organizations. CyberAv3ngers' ICS exploitation techniques have proliferated to an estimated 60+ affiliated groups, meaning the threat persists even if the core group is degraded. Defenders operating internet-exposed PLCs should take immediate action.

Background

On April 7, 2026, the FBI, CISA, NSA, EPA, Department of Energy, and U.S. Cyber Command jointly warned that Iranian-affiliated advanced persistent threat actors are actively exploiting internet-facing programmable logic controllers across U.S. critical infrastructure. The advisory, designated AA26-097A, confirmed operational disruption and financial loss at multiple victim organizations in the Government Services, Water and Wastewater Systems, and Energy sectors. The authoring agencies linked this activity to the same threat ecosystem behind CyberAv3ngers, a group the U.S. government has formally attributed to Iran's Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC).

CyberAv3ngers is not a new actor, but its capabilities have matured significantly since it first drew international attention in late 2023. This FAQ provides defenders, vulnerability management teams, and security leadership with a comprehensive profile of the group: its history, technical capabilities, targeted sectors, and the specific steps organizations should take to reduce their exposure.

FAQWho is CyberAv3ngers?

CyberAv3ngers is an Iranian state-directed cyber threat group operating as a persona for the IRGC-CEC. The group has been active since at least 2020 and is tracked by the security community under multiple designations, including Storm-0784 (Microsoft), Bauxite (Dragos), Hydro Kitten, UNC5691 (Mandiant), and MITRE ATT&CK ID G1027.

Despite initially presenting itself as a hacktivist collective motivated by anti-Israel ideology, subsequent investigations by CISA, the U.S. Treasury Department, and multiple cybersecurity research organizations established that the group's funding, tooling, and operational sophistication far exceeded typical hacktivist capabilities. The group is a state-sponsored actor, not an independent activist collective.

Who is behind the group?

In February 2024, the U.S. Treasury Department's Office of Foreign Assets Control (OFAC) sanctioned six IRGC-CEC officials for directing CyberAv3ngers operations: Hamid Reza Lashgarian (head of IRGC-CEC and an IRGC-Qods Force commander), Hamid Homayunfal, Mahdi Lashgarian, Milad Mansuri, Mohammad Amin Saberian, and Mohammad Bagher Shirinkar. The State Department's Rewards for Justice program is currently offering up to $10 million for information on the "Mr. Soul" persona, which the State Department has linked to CyberAv3ngers and which is suspected to be an alias for one of the sanctioned officials.

In December 2025, leaked internal operational records exposed structured spreadsheets tracking domain registrations, European virtual private server hosting, and cryptocurrency payments routed through Bitcoin wallets. These records confirmed direct infrastructure and administrative overlap with the Moses Staff operation, formally connecting what had previously been treated as separate Iranian cyber personas into a single coordinated effort directed by the state.

The group has also demonstrated resilience through serial rebranding. When the "APT IRAN" Telegram channel, widely assessed as a CyberAv3ngers rebrand, was deleted, a new "Cyber4vengers" channel emerged in January 2026 to continue operations. Taking down individual channels and personas has not disrupted the underlying organizational capability.

Should CyberAv3ngers' public claims be taken at face value?

No. CyberAv3ngers operates a deliberate parallel influence campaign alongside its technical operations, and defenders should evaluate the group's public claims with skepticism.

DomainTools Investigations (DTI) characterized the group's strategy as "engineering beliefs" rather than merely breaching systems. CyberAv3ngers has refined its cyber activity into what DomainTools describes as a propaganda apparatus: each operation becomes a performance calibrated to sow fear and disrupt public trust, recycled data leaks are theatrically repackaged to simulate fresh compromises, and social media personas sustain the perception of threat even during operational pauses.

The October 2023 Dorad power station incident is the clearest example. CyberAv3ngers posted on Telegram claiming to have breached a major Israeli power plant, sharing what appeared to be screenshots of compromised control systems. DomainTools' forensic investigation demonstrated that the images were recycled from a 2022 Moses Staff data leak, cropped and rebranded with CyberAv3ngers logos. No indicators of compromise, malware samples, or valid forensic evidence were released. Despite this, the fabricated claim generated media coverage and threat intelligence discussion.

This dual-track strategy of blending genuine industrial control systems (ICS) operations with fabricated claims is not early-phase immaturity that the group outgrew. It is a standing operational doctrine that persists alongside the group's increasingly sophisticated technical campaigns. When CyberAv3ngers claim a new compromise, organizations should look for corroborating technical evidence before treating the claim as confirmed.

What does CyberAv3ngers target?

The group's primary focus is operational technology and ICS in critical infrastructure. Targeted sectors include:

• Water and wastewater systems, the group's most persistent target since 2023, with confirmed compromises at U.S. water utilities and a private water scheme in Ireland
• Energy, including fuel management systems (Orpak and Gasboy) and PLC-controlled energy infrastructure
• Government services and facilities, including local municipalities targeted in the current 2026 campaign
• Healthcare and food and beverage sectors, where Unitronics PLCs were deployed and compromised during the 2023 campaign

The targeting logic follows two principles: Israeli-manufactured technology, regardless of where it is deployed, and U.S. critical infrastructure as retaliatory targeting aligned with geopolitical hostilities between the United States and Iran.

Why do small utilities and municipal operators keep getting hit?

CyberAv3ngers has repeatedly compromised small water utilities, municipal facilities, and rural energy operators, and the reason is structural, not coincidental.

Many of these organizations manage their operational technology environments with consumer-grade remote access tools such as TeamViewer or AnyDesk, or by exposing PLC management interfaces directly to the public internet. These access methods bypass enterprise security controls entirely, creating an attack surface that is invisible to conventional security monitoring. The compromised Unitronics PLC at the Municipal Water Authority of Aliquippa, Pennsylvania was directly accessible from the internet with default credentials and no security gateway in between.

The problem is compounded by inadequate network segmentation between IT and OT environments. When a PLC is reachable from the same network as email servers and employee workstations, the blast radius of any compromise extends well beyond the initial point of entry. A 2024 CISA assessment found over 70% non-compliance with existing safety requirements at U.S. water utilities.

Organizations in these sectors typically lack dedicated OT security staff and operate under constrained budgets that make comprehensive security architecture difficult. The result is a persistent systemic exposure condition: the same type of misconfiguration that CyberAv3ngers exploited in 2023 remains available for the group and the 60+ affiliated hacktivist groups that have adopted its playbook to exploit today.

How has CyberAv3ngers evolved over time?

The group's operational history reveals a deliberate capability escalation across four distinct phases.

Phase 1: Propaganda (2020–2022): The "Cyber Avengers" persona first appeared in 2020, claiming responsibility for power outages and rail disruptions in Israel. These claims were dismissed by Israeli officials and no supporting evidence was identified. DomainTools Investigations later demonstrated that several of these claims reused imagery from a 2022 Moses Staff data leak, cropped and rebranded to simulate a fresh intrusion.

Phase 2: Default Credential Exploitation (October 2023 – January 2024): The group compromised at least 75 Unitronics Vision Series PLCs across the United States, Israel, the United Kingdom, and Ireland by exploiting default passwords on internet-exposed devices. The Municipal Water Authority of Aliquippa, Pennsylvania, was the highest-profile victim. In Ireland, an attack left residents without water for several days. CISA, the FBI, NSA, and other agencies issued joint advisory AA23-335A documenting the campaign.

Phase 3: Custom ICS Malware (Mid-2024): Claroty's Team82 identified and analyzed IOCONTROL, a custom-built Linux malware platform designed for IoT and OT environments. The malware targets routers, PLCs, HMIs, IP cameras, firewalls, and fuel management systems from multiple vendors. IOCONTROL uses the MQTT protocol over TLS for command-and-control communications, a standard IoT protocol that allows traffic to blend with legitimate network activity. Team82 characterized IOCONTROL as a cyberweapon used by a nation-state to attack civilian critical infrastructure. Separately, OpenAI disclosed in October 2024 that CyberAv3ngers had used ChatGPT to perform reconnaissance on targets and debug code, indicating the group incorporates commercially available AI tools into its operational workflow.

Phase 4: Authentication Bypass Exploitation (March 2026 – Present): The group pivoted to exploiting CVE-2021-22681, a critical authentication bypass vulnerability (CVSS 9.8) in Rockwell Automation Logix controllers. Actors used leased overseas infrastructure with Rockwell's Studio 5000 Logix Designer software to connect to internet-facing PLCs, bypassing authentication to manipulate project files and HMI/SCADA displays. This phase represents a platform shift from Israeli-made Unitronics devices to U.S.-made Rockwell Automation controllers, targeting a more widely deployed industrial platform.

This four-phase arc is not just a historical record, it is a capability escalation trajectory with a predictable direction. Dragos, which tracks the overlapping threat activity as BAUXITE, assessed in its 2026 OT/ICS Cybersecurity Year in Review that Iranian adversaries are moving beyond pre-positioning to actively mapping control loops and understanding how to manipulate physical processes. CyberAv3ngers' progression from default credentials to custom IoT malware to CVE exploitation against tier-1 ICS platforms tracks this maturation pattern. The group's next capability step is likely to involve additional ICS vendor platforms or deeper process manipulation, not a retreat to simpler techniques.

What is IOCONTROL?

IOCONTROL is a custom-built malware platform attributed to CyberAv3ngers by Claroty Team82. It is designed to run on a variety of Linux-based IoT and OT devices due to its modular architecture. Affected device types include IP cameras, routers, PLCs, HMIs, firewalls, and fuel management systems from vendors including D-Link, Hikvision, Baicells, Red Lion, Orpak, Phoenix Contact, Teltonika, and Unitronics.

Key technical characteristics include MQTT over TLS for C2 communications on port 8883, DNS-over-HTTPS to evade network monitoring when resolving C2 domains, AES-256-CBC encrypted configuration data, persistence through a systemd boot script, and capabilities including OS command execution, port scanning, and self-deletion. The malware was previously tracked under the names OrpraCab and QueueCat in 2023 before being identified under the IOCONTROL designation in 2024.

Has CyberAv3ngers used AI tools?

Yes. In October 2024, OpenAI published a threat intelligence report disclosing that CyberAv3ngers had used ChatGPT to assist with target reconnaissance and code debugging. The group used the platform to research ICS, explore exploitation techniques against specific device types, and troubleshoot code, incorporating a commercially available AI tool into the operational preparation phase of ICS-targeted campaigns.

This is consistent with a broader pattern across state-sponsored threat actors. AI tools lower the research and development overhead for operations that previously required more specialized expertise, and they are particularly useful for actors expanding into unfamiliar technology domains, such as CyberAv3ngers' pivot from Unitronics to Rockwell Automation controllers. The OpenAI disclosure does not suggest that AI fundamentally changed the group's capabilities, but it does indicate that AI-assisted reconnaissance is now part of the standard toolkit for state-directed ICS threat actors.

What is CVE-2021-22681 and why does it matter?

CVE-2021-22681 is a critical authentication bypass vulnerability (CVSS 9.8) in Rockwell Automation's Logix controller ecosystem. The flaw stems from an insufficiently protected cryptographic key used to verify communications between the Studio 5000 Logix Designer engineering software and Logix PLCs. A remote, unauthenticated attacker who obtains or intercepts this key can impersonate legitimate engineering software, bypass authentication, and establish a direct connection to affected controllers without valid credentials.

The vulnerability affects a wide range of Rockwell Automation products including RSLogix 5000 (versions 16–20), Studio 5000 Logix Designer (version 21 and later), and multiple Logix controller families: CompactLogix, ControlLogix, GuardLogix, DriveLogix, and SoftLogix. CVE-2021-22681 was originally disclosed in February 2021 and was added to the CISA Known Exploited Vulnerabilities catalog in March 2026 after active exploitation by Iranian-affiliated actors was confirmed.

A critical operational detail for vulnerability management teams: Rockwell Automation has stated that this vulnerability cannot be fully addressed with a patch. There is no software update to deploy and no patch cycle to wait for. Rockwell directs customers to apply defense-in-depth mitigations instead, including network segmentation, engineering workstation isolation, CIP Security enablement, and physical mode switch hardening. This means the exposure is permanent absent architectural controls, and organizations that rely on patch-based remediation workflows will not resolve this vulnerability through their standard processes.

How severe is the current threat?

The current threat level is critical. The convergence of three factors: a confirmed state-directed actor with demonstrated willingness to disrupt civilian infrastructure, a custom-built ICS malware capability alongside exploitation of a critical authentication bypass with no available patch, and active kinetic hostilities between the United States and Iran following Operation Epic Fury, creates the most acute Iranian cyber threat to U.S. critical infrastructure on record.

CISA Advisory AA26-097A confirmed that organizations from multiple U.S. critical infrastructure sectors experienced disruptions through malicious interactions with PLC project files and manipulation of data displayed on HMI and SCADA systems, resulting in operational disruption and financial loss. The FBI assessed that the actors' intent is to cause disruptive effects within the United States.

The threat does not depend on CyberAv3ngers remaining intact as an organization. Unverified reports have circulated that individuals linked to the group may have been killed in the Operation Epic Fury strikes, but these reports remain unconfirmed, and the continued exploitation activity documented in the April 7 advisory demonstrates that the operational capability persists regardless. More importantly, CyberAv3ngers' ICS exploitation techniques have proliferated to an estimated 60+ pro-Iranian hacktivist groups. This "swarm effect" creates a distributed threat surface with no single point of disruption, lowers the capability threshold so less experienced actors can attempt ICS attacks using shared knowledge, and increases the risk of unintended physical consequences from operators who lack the discipline or understanding to control the effects of PLC manipulation. The threat may actually become less predictable as it becomes more diffuse.

Finally, the systemic exposure condition that enables this threat–internet-exposed PLCs with weak or default authentication–is structural, not transient. It has persisted across every phase of CyberAv3ngers' operations despite repeated federal advisories. Until the foundational attack surface is eliminated, the same class of attack will remain viable for any group that adopts the playbook.

What should organizations do right now?

Organizations operating internet-exposed PLCs, particularly Rockwell Automation and Unitronics devices, should take the following actions immediately:

• Disconnect PLCs from the public internet. Any internet-accessible Rockwell Logix controller is exploitable via CVE-2021-22681 without authentication. There is no patch for this vulnerability. If remote access is operationally necessary, deploy a secure gateway with multifactor authentication.
• Set physical mode switches to "Run." This prevents remote modification of PLC logic and configurations.
• Back up all PLC logic and configurations offline. Store backups on secured physical media and test restore procedures.
• Ingest IOCs from CISA Advisory AA26-097A. Download the STIX-formatted indicators of compromise and deploy them in SIEM, IDS, and firewall platforms. Monitor for traffic on ports 44818, 2222, 102, 22, and 502 from overseas hosting providers.
• Implement IT/OT network segmentation. Isolate engineering workstations running Studio 5000 Logix Designer from untrusted network segments. Deploy allowlisting so only authorized workstations can communicate with controllers.
• Audit remote access to OT environments. Identify and replace any consumer-grade remote access tools (TeamViewer, AnyDesk, or similar) with enterprise VPN solutions that enforce multifactor authentication and centralized logging. Ensure all remote OT access is monitored.
• Audit Unitronics devices. Verify that all Unitronics Vision Series PLCs have had default passwords changed per VisiLogic version 9.9.00.
• Deploy behavioral detection for IOCONTROL indicators. Alert on MQTT over TLS (port 8883) and DNS-over-HTTPS traffic originating from OT network segments.

Has Tenable released product coverage for the vulnerabilities discussed?

A Tenable plugin is available for CVE-2021-22681, which was updated in March 2026. Tenable OT Security detects this vulnerability in Rockwell Automation Logix controller environments.

Organizations using the Tenable One Exposure Management Platform can leverage vulnerability intelligence capabilities to identify affected Rockwell Automation assets in their environment. The platform's exposure assessment capabilities can help prioritize remediation based on the active exploitation context documented in this post.

A list of Tenable plugins for this vulnerability can be found on the CVE-2021-22681 plugins page. These plugins will be updated as additional detection coverage is developed.

For the latest information on Tenable detection coverage and ongoing updates, visit the Tenable CVE page for CVE-2021-22681.

Conclusion

CyberAv3ngers has evolved from a propagandistic hacktivist persona into one of the most consequential Iranian threats to U.S. operational technology infrastructure. The group's trajectory from default credential exploitation in 2023, to custom ICS malware deployment in 2024, to active exploitation of Rockwell Automation controllers in 2026, demonstrates a deliberate capability escalation that tracks the broader maturation pattern Dragos identified across Iranian ICS-targeting groups–adversaries moving beyond pre-positioning to actively understanding and manipulating physical processes.

Three factors make this threat durable. First, the systemic exposure condition: internet-exposed PLCs with weak or absent authentication has persisted across every phase of the group's operations despite repeated federal advisories. Until the foundational attack surface is eliminated, the same class of attack will remain viable. Second, the exploitation playbook has proliferated to dozens of semi-autonomous groups, meaning the threat persists regardless of CyberAv3ngers' own organizational status. Third, CVE-2021-22681 has no vendor patch. Affected organizations cannot resolve this vulnerability through standard patch management workflows and must implement architectural controls instead.

Organizations operating Rockwell Automation or Unitronics devices should treat the recommendations in this post and CISA Advisory AA26-097A as urgent action items, not longer-term roadmap items. The threat is accelerating.

Tenable Research Special Operations will continue to track CyberAv3ngers and the broader Iranian ICS threat ecosystem. We will update this post as new intelligence becomes available.

Get more information

• CISA Advisory AA26-097A: Iranian-Affiliated Cyber Actors Exploit PLCs Across US Critical Infrastructure (April 7, 2026)
• CISA Advisory AA23-335A: IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors (Updated December 2024)
• Rewards for Justice — CyberAv3ngers
• Claroty Team82 — Inside a New OT/IoT Cyberweapon: IOCONTROL (December 2024)
• DomainTools — CyberAv3ngers Influence Operations Analysis (June 2025)
• Tenable CVE Page — CVE-2021-22681

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.

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