The honest answer, for most organizations today, is “nothing your existing stack was designed to do.”

This is not a critique of the security tools enterprises have spent years deploying. WAFs, EDRs, network firewalls, API gateways, identity platforms; these have evolved into a layered defense that genuinely works against the threats they were built for. But GenAI applications introduce a new attack surface that operates outside the boundary every one of those tools defends.

The problem is not that AI threats are more dangerous than traditional threats. The problem is that they are categorically different.

What is generative AI security?

Traditional security tools all share a common assumption: attacks come in the form of malformed inputs, malicious payloads, suspicious traffic patterns, or unauthorized access attempts. A WAF inspects HTTP headers, query strings, and request bodies for known patterns. An EDR watches for binaries behaving badly. An API gateway enforces schema and authentication.

An LLM-based application turns all of those assumptions on their head.

The payload in a prompt injection attack is grammatically correct English. The malicious code in a data leakage attack is a polite question. The denial of service pattern in an unbounded consumption attack is a perfectly legitimate looking conversation. The threats that matter to a GenAI application live at the level of the model’s logic, not at the level of the network or the HTTP request.

Even more critically, the security tools that protect the application surrounding the model have no visibility into what happens at the interface. The WAF sees the request to your AI endpoint. It does not see what the model does with that request. The API gateway authenticates the user. It does not understand whether the user is trying to convince the model to reveal its system prompt.

This is the gap that has emerged across enterprise security architectures over the last 18 months. It is not a minor blind spot. It is a category-level gap. Traditional security tools do not speak AI.

What AI-native security actually means?

When we talk about AI-native security at Imperva, we are not talking about adding AI features to a traditional security product. We are talking about a purpose-built control plane that understands prompts, model responses, conversation context, and usage patterns the way our WAF understands HTTP.

That distinction matters because AI security has to inspect the interaction itself. It has to understand what the user is asking for, how the model is likely to respond, whether sensitive data is being exposed, whether instructions are being manipulated, and whether usage patterns suggest abuse. This is inspection at the AI interaction layer rather than the network layer.

Thales’s Imperva AI Application Security is engineered specifically for the architecture of AI and agentic applications. It sits between your applications and the models they call, giving teams flexible deployment options rather than forcing a single architecture. Every input and every output is analyzed in real time, against multiple security guardrails, with adaptive risk scoring that distinguishes legitimate use from manipulation attempts.

Concretely, it addresses five of the OWASP Top 10 LLM threats:

• Prompt injection and jailbreaking attempts
• Sensitive information disclosure through model outputs
• System prompt leakage
• Improper output handling
• Unbounded consumption attacks that drive cost runaway and denial of service

And critically, it does not replace your existing WAAP. It extends it. AI Application Security plugs into the same unified Imperva platform that handles your WAF, API security, bot management, and DDoS protection. The same console, the same policy model, the same role-based access controls

The AI threat surface becomes one more dimension of the security posture your team already manages, rather than a new tool, a new vendor, and a new operational silo.

What generative AI security means for the next 12 months?

According to McKinsey’s State of AI survey (November 2025), 88% of organizations now use AI in at least one business function, up from 78% a year earlier. And in the 2026 Thales Data Threat Report, 61% of organizations named AI as their top data security risk, while the share carrying a dedicated AI security budget rose from 20% to 30%. As organizations move from simple chat experiences toward autonomous agents capable of taking actions, the need for AI-specific security controls becomes even more critical. The teams that get this right will not be the ones who deploy more security tools. They will be the ones who recognize that AI applications are a new class of asset and treat them with a control layer designed for what they actually are.

A WAF was the answer when applications moved from desktop to web. An API gateway was the answer when monoliths gave way to microservices. An AI Application Security layer is the answer for applications that no longer execute only predictable code, but interpret, generate, and increasingly act on language.

That is the new kind of security your AI deserves.

Frequently asked questions about generative AI security

What is the difference between AI security and generative AI security?
AI security is the broad category, covering everything from model theft to training-data poisoning. Generative AI security is the runtime subset: protecting live LLM and agentic applications from prompt injection, sensitive data disclosure, system prompt leakage, improper output handling and unbounded consumption.


Can a WAF stop prompt injection?
No. A WAF inspects HTTP headers, query strings and request bodies for known malicious patterns. A prompt injection payload is grammatically valid English inside a legitimate request, so it passes every WAF check. Stopping it requires inspection at the AI interaction layer, which is what an AI application security layer adds alongside the WAF.


Do I need to replace my existing security stack to secure AI?
No. AI application security extends the stack rather than replacing it. Imperva AI Application Security plugs into the same platform as the WAF, API security, bot management and DDoS protection, using the same console, policy model and role-based access controls.


Which OWASP LLM Top 10 risks does Imperva AI Application Security address?
Five of the ten out of the box: prompt injection and jailbreaking, sensitive information disclosure, system prompt leakage, improper output handling, and unbounded consumption.


Is generative AI security different for AI agents?
Yes. Agents take actions rather than only returning text, so a successful manipulation becomes an operational incident rather than a bad answer. See the companion post on agentic AI security below.

Ready to see what AI-native security looks like in practice? Talk to your Thales representative or visit imperva.com to explore AI Application Security.

The post Why Generative AI Needs a New Kind of Security appeared first on Blog.

The conversation that the user sees may therefore represent only a small part of what the agent is actually doing. Many of its actions take place quietly in the background, without being clearly presented to the user or the security team. 

This creates a significant visibility challenge for security teams. Organizations may not know which AI-powered applications are active on developer machines, what those applications are doing, or whether their behavior aligns with company policies.  

An agent does not need to be malicious to create risk. While trying to complete a task, it may interpret instructions too broadly and access information the user did not intend to expose or perform actions that extend beyond the original request. 

The Endpoint Visibility Gap 

Traditional endpoint security controls may capture individual parts of an agent’s activity without revealing their significance. An IDE or terminal process accessing a sensitive file, such as an .env file, may appear to be routine development activity. But if the process is controlled by an AI agent that has already communicated with an LLM provider, the same event has a very different security meaning. The developer may not have chosen to open the file at all. The agent may have accessed it autonomously while trying to complete a task.  

Without connecting these events to the agent responsible for them, security teams may interpret autonomous agent behavior as ordinary user activity. This challenge is amplified by the fact that AI capabilities are not limited to a fixed set of recognizable applications. Traditional security controls can often map, classify, or restrict known software, but almost any Python script, IDE extension, command-line tool, or internal application can gain agentic capabilities by connecting to an LLM and acting on its responses. This makes application-based detection difficult. Blocking the underlying application or interpreter is usually not practical because the same software is also used for legitimate work.  

As a result, application-based allowlists and blocklists cannot provide sufficient visibility or control on their own.  

The real challenge is therefore not just detecting a process, file access event, command execution, or network connection. It’s determining whether that activity was initiated by the developer or autonomously by an AI agent. 

From AI Discovery to Behavioral Understanding 

Identifying an AI-enabled process is only the first step. Security teams must also understand how its behavior develops throughout the session. 

After receiving instructions or model output, an agent may create child processes, execute shell commands, inspect local files, access sensitive directories, or initiate additional network connections. The sequence of these actions can reveal how the agent interpreted its task and whether its behavior moved beyond what the user expected. 

This behavioral context becomes especially important during an investigation. A single command, file access event, or outbound connection may appear legitimate when viewed alone. When these events are connected chronologically, however, they may reveal a very different story: the agent encountered new input, changed its behavior, accessed a sensitive resource, and then attempted to communicate with an external destination. 

The goal is not only to identify that an AI agent was active, but to reconstruct its activity and understand the relationship between the agent, its subprocesses, the resources it accessed, and the destinations it contacted.

Introducing ShadowAI-Watch 

This is why we created ShadowAI-Watch, an open-source runtime discovery and behavioral monitoring tool for AI-powered applications and agents. 

ShadowAI-Watch runs independently on the user’s machine and does not require changes to the monitored application. It provides a host-level view of AI agent activity by correlating processes with outbound LLM connections and tracing the actions that follow. 

The tool is designed to identify custom AI agents, coding agents, browser agents, LLM-powered applications, and locally hosted models, including applications that may not have an obvious AI-related process name. 

ShadowAI-Watch supports multiple privilege levels, ranging from a low-privileged user to full administrative access. With limited privileges, it inspects process information available through /proc to discover agentic applications. With elevated privileges, it enables its full eBPF-based monitoring mechanism, providing deeper and more precise visibility into process and system activity. 

ShadowAI-Watch Workflow 

ShadowAI-Watch runs locally on the user’s machine and continuously monitors outbound network activity across running processes. When a process connects to a known large language model provider, the tool identifies it as AI-related and traces the process tree to determine which application initiated the connection. 

It then continues observing the session and correlates subsequent commands, child processes, file access, and network activity with the identified application.  

Together, these events create a chronological record of the agent’s runtime activity and the sequence that led to each action. 

These events are written to a JSON Lines audit file and displayed live in the terminal using color-coded output. The audit data can also be sent to a remote dashboard for visualization and risk analysis. This gives security teams both immediate visibility while the agent is operating and a structured audit trail that can be examined after the session. 

The released repository includes the components responsible for generating logs and structured audit records. Organizations can use this data to build their own dashboards, monitoring workflows, or integrations based on their specific requirements. 

ShadowAI-Watch workflow 

Watching a Browser Agent Get Hijacked 

The demo begins with a simple request: summarize a website by opening a URL and following the links it contains. 

To the user, this looks like an ordinary browsing task. The BrowserUse agent opens the site, moves between pages, and gathers the information it needs. In the background, ShadowAI-Watch discovers the agent, identifies it as BrowserUse, and begins tracing its activity in real time. 

At first, everything proceeds as expected. 

Then the agent reaches a page containing an instruction that did not come from the user. It was placed there by an attacker and attempts to convince the agent to open an external URL and transmit session data to an attacker-controlled endpoint. 

The agent follows the instruction. 

From the developer’s perspective, the agent still appears to be navigating the website as requested. The malicious request is hidden within the normal browsing flow and could easily go unnoticed. 

ShadowAI-Watch sees a different story. 

It sees the agent reach the page containing the indirect prompt injection. It then observes the agent’s behavior change and detects its attempt to connect to a destination unrelated to the original task. Instead of treating the request as isolated browser traffic, ShadowAI-Watch links it to the active BrowserUse session and to the attacker-controlled content that preceded it. 

What appeared to be routine browsing is revealed as an agent hijacking sequence: a legitimate task, exposure to a malicious instruction, a change in behavior, and an attempted transmission of sensitive data. 

The video below shows that sequence unfolding in real time, from the discovery of the BrowserUse agent to the detection of the malicious outbound connection. 

See ShadowAI-Watch at DEF CON 34 

Our team will present ShadowAI-Watch in the AppSec Village Arsenal at DEF CON 34 during the session, “The Agent Asked. We Allowed. Now What?” 

ShadowAI-Watch is available as an open-source project for Linux, with macOS support coming soon. Access the repository and learn how to get started here: https://github.com/ThalesGroup/shadowai-watch 

The post ShadowAI-Watch: Bringing AI Agent Activity Out of the Shadows appeared first on Blog.

Understanding HTTP Desync Attacks 

Modern web applications rarely receive requests directly from users. Traffic commonly passes through several components, such as a CDN, load balancer, reverse proxy, or WAF, before reaching the application server. 

An HTTP desync vulnerability occurs when two of these components disagree about where one request ends and the next begins. A front-end system may treat a sequence of data as one complete request, while the back-end interprets part of the same data as the beginning of another request. This parsing difference can allow an attacker to smuggle traffic past front-end security controls. 

Depending on the affected architecture, successful exploitation can lead to security-control bypasses, cache poisoning, access to restricted functionality, or response queue poisoning. In a response queue poisoning attack, a response intended for one user may be delivered to another, potentially exposing sensitive information. 

HTTP/1.1 is particularly exposed to this class of problem because request boundaries can be represented in multiple ways, and products do not always handle malformed or unusual combinations consistently. 

What’s HTTP Terminator? 

The HTTP Terminator is an autonomous research system designed to generate, evaluate, and refine potential protocol attacks. Using small fragments of protocol specifications as inspiration, it generated about 30,000 unique desync vectors in testing and evaluated them against websites where testing was authorized through vulnerability disclosure or bug bounty programs. 

The research ultimately demonstrated many novel desync triggers, one new desync pattern, and one new weaponization technique. It also introduced Shared-Parser Confusion, a broader attack concept that may extend beyond request smuggling. 

New and Unexpected Desync Triggers 

Traditional request-smuggling testing often focuses on conflicts involving the Content-Length and Transfer-Encoding headers. The new research shows that parsing differences can also be triggered by less obvious HTTP features, including unusual request methods, unexpected method-and-body combinations, uncommon transfer encodings, duplicate headers, and content types normally associated with responses.  

One notable example involved the multipart/byteranges content type. According to the research, this behavior affected more than 200 websites in the authorized target set and appeared across multiple server implementations. The lesson for defenders is clear: protection cannot rely only on a short list of well-known request-smuggling payloads.  

Dual Matching Content-Length Headers 

Security controls commonly look for requests containing conflicting Content-Length values. The research showed that some systems can also behave unexpectedly when a request contains two matching Content-Length headers. Although the values appear consistent, components in the request chain may still process the duplicate headers differently and disagree about whether the request has a body or where it ends. 

This pattern was exploitable in real deployments, including an environment where response queue poisoning exposed a long-lived API key. The underlying issue was later linked to a server misconfiguration. 

The Dangling-Byte Technique 

Response queue poisoning has often been unreliable because the front end may notice an unexpected extra response and close the connection before the attack succeeds. The dangling-byte technique improves reliability by sending an incomplete smuggled request that is missing one byte. The next legitimate request supplies that byte, completing the attacker’s request only after the victim’s traffic arrives. 

In the tested scenarios, this removed a significant timing race and made response theft substantially more reliable on affected architectures. 

Shared-Parser Confusion 

The research also introduced Shared-Parser Confusion. Some implementations reuse parsing logic for both HTTP requests and HTTP responses. As a result, functionality intended for processing responses may accidentally be activated by attacker-controlled data inside a request. 

This expands the potential attack surface beyond ordinary request-processing behavior. Response-specific headers, content types, and parser rules may also influence how a malicious request is interpreted.  

How Imperva Protects Customers 

Imperva’s AI powered security engine is designed to help protect customers against the next generation of AI-assisted attacks, including systems like HTTP Terminator that can generate and test large volumes of novel protocol variations. Rather than relying only on known payloads or static signatures, Imperva combines strict protocol validation, behavioral analysis, anomaly detection, and continuous threat intelligence to identify malicious or ambiguous traffic patterns at scale. This approach allows Imperva to respond quickly when attackers or AI-driven research tools uncover new ways to abuse protocol edge cases, helping ensure that customers remain protected even as attack discovery becomes more automated and faster-moving.

Imperva’s protection against HTTP desync attacks does not depend on one vulnerability-specific signature. Cloud WAF and On-Prem WAF use dedicated security rules and protocol-validation controls designed to identify malformed, conflicting, and ambiguous HTTP requests before they reach protected applications. 

These protections cover behavior commonly associated with desync and request-smuggling attacks, including: 

• Invalid or ambiguous HTTP message framing 
• Redundant, duplicated, or conflicting request headers 
• Malformed protocol elements and abnormal request structure 
• Suspicious combinations of methods, headers, and message bodies 
• Attempts to embed an additional HTTP request within an existing request 
• Known request-smuggling and response queue poisoning patterns 

Imperva’s analysis determined that existing protections were already blocking the primary practical attack patterns described in the HTTP Terminator research. Following a detailed review of the newly published vectors, Imperva also fortified its mitigation to provide additional coverage for the newly documented parsing variations. 

Imperva telemetry shows that these protections are actively blocking real-world exploitation attempts, especially using desync techniques. Observed POST bodies include payloads characteristic of the HTTP Smuggler Burp Suite extension, with embedded or malformed request lines, randomized paths, and synthetic headers intended to reveal parsing discrepancies between front-end and back-end systems. Examples of blocked payloads include: 

TRACE /?x=yz HTTP/1.1 
TRACE / HTTP/1.1 X-YzBqv: = 
GET / HTTP/2.2 X-YzBqv: 
TRACE /wrtzllsk1005516x1x6 HTTP/1.1 
GET /tRmNtR1g00ir3d HTTP/1.1 

These requests are not normal application traffic. They are crafted probes designed to test whether components in an HTTP request chain disagree about request boundaries or interpret an embedded request differently. Imperva blocked these attempts before they reached protected applications, demonstrating that the threat is already being explored in the wild and that existing desync protections are providing practical coverage. 

Cloud WAF customers receive managed protection updates as part of the service. On-Prem WAF customers should enable dedicated available controls such as Response Forking – HTTP Desync policy (if not enabled) to mitigate these attacks. 

Recommended Best Practices 

Imperva provides protection against the practical attack techniques described in the research, but organizations should also reduce the underlying risk within their application delivery architecture. 

1. Keep infrastructure components updated. Apply vendor patches to web servers, reverse proxies, application delivery controllers, API gateways, CDNs, and load balancers. 
2. Reject ambiguous HTTP requests. Do not forward requests containing duplicate framing headers, invalid transfer encodings, or malformed protocol syntax to backend systems. 
3. Restrict unnecessary HTTP methods. Allow only the methods required by the application, and define which methods may legitimately contain a request body. 
4. Prefer HTTP/2 or newer protocols upstream. Imperva Cloud WAF allows clients-to-WAF HTTP/2 support and also WAF-to-origin server HTTP/2 support. 

 On Prem WAF also supports HTTP/2 traffic inspection. 

Conclusion 

The HTTP Terminator research demonstrates both the continuing security challenges of HTTP/1.1 and the growing ability of AI-assisted systems to discover unexpected protocol behavior at scale. 

It also highlights why defense against HTTP desync attacks must be based on strict protocol validation and broad behavioral coverage, not only signatures for previously published payloads. 

Imperva Cloud WAF and WAF Gateway customers are protected against the practical desync techniques described in the research. Existing dedicated security rules were already blocking the associated malicious request patterns, and Imperva has further fortified these protections in response to the newly published findings. 

Imperva Threat Research will continue monitoring this area and emerging HTTP parsing techniques to protect customers as the threat landscape evolves. 

The post Imperva Customers Protected Against Novel HTTP Desync Attacks appeared first on Blog.

That diagram was accurate for about eighteen months. It is not accurate anymore.

Look inside a modern AI application and the chatbot is the least interesting thing in it. There are agents living inside the application, making decisions and calling functions without a human typing anything. There are MCP servers sitting outside the application, connecting models to real systems and live data. There are tools (scripts, APIs, plugins) that the model can invoke, retrieved documents flowing into context windows, and orchestration layers deciding which agent hands work to which. The application is no longer app-plus-LLM. It is an ecosystem.

What is agentic AI security?

Agentic AI security is the practice of securing AI applications that take actions, not just applications that answer questions. It covers the whole AI execution path: the agents making decisions, the tools and APIs they invoke, the MCP servers connecting them to live systems, the documents retrieved into context, and the orchestration layer routing work between agents. Prompt inspection alone covers only the first hop.

That matters for one uncomfortable reason: security architectures inherit their assumptions from the diagrams they were designed against. If your AI protection assumes a single conversation crossing a single boundary, it is defending an architecture nobody runs anymore.

What changed in the AI attack surface

Three things, in quick succession.

First, agents started taking actions. A chatbot that gives a wrong answer is embarrassing. An agent that acts on a manipulated instruction is an operational incident. It can query a database, call an API, or trigger a workflow before any human notices. The blast radius of a successful prompt injection grew from “bad reply” to “bad transaction.”

Second, the Model Context Protocol and similar tool-integration patterns arrived. MCP is useful: a standard bridge between AI assistants and real systems. It is also, by definition, an expansion of the attack surface. Every tool a model can reach is something an attacker can try to reach through the model. We unpack those exposures in detail in MCP Server Security: The Blind Spot in Your AI Stack (https://www.imperva.com/blog/mcp-server-security-blind-spot-ai-stack/).

Third, the interactions multiplied. It is no longer one train rolling through one tunnel, one prompt in and one response out. It is internal communication between sub-agents, external calls to MCP servers, retrieval from knowledge stores: traffic that never touches the chat window at all.

The honest question: would you know what your agents just did?

The challenge isn’t simply preventing prompt injection attacks anymore. It’s understanding everything the application is capable of doing.

So here is the question worth asking your team this week: if an agent inside one of your applications called a tool it had never called before, would anyone know?

For most organizations, the honest answer is no. Not because the security team is behind, but because the visibility layer for this architecture is only now being built. You cannot govern what you cannot see, and most of what modern AI applications do is currently unseen.

That is where AI application security is heading as a discipline: away from inspecting a single conversation, toward securing the entire AI execution path: discovering every AI asset in the environment, understanding how agents, models, and tools actually relate to each other, and enforcing policy on the interactions that matter.

The chatbot era gave us a clean diagram and a comforting inspection point. The agent era gives us an ecosystem. Security is moving with it. The teams that update their mental diagram first will be the ones that are not surprised later.

Frequently asked questions about agentic AI security

What is the difference between LLM security and agentic AI security?

LLM security protects the conversation: what goes into the model and what comes back out. Agentic AI security protects what happens next – the tools the agent calls, the systems it reaches through MCP, the data it retrieves, and the handoffs between agents. The blast radius of a successful attack grows from a bad reply to a bad transaction.

Why isn’t prompt inspection enough for AI agents?

Because most agentic traffic never touches the chat window. Sub-agent communication, MCP tool calls and retrieval from knowledge stores all happen behind the prompt. An inspection point placed on the user conversation sees none of it.

What are the main agentic AI security risks?

The OWASP Top 10 for Agentic Applications (2026) names agent goal hijack, tool misuse and exploitation, identity and privilege abuse, agentic supply chain vulnerabilities, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading failures, human-agent trust exploitation, and rogue agents.

How do you get visibility into what AI agents are doing?

Start with discovery: inventory every AI asset in the environment – models, agents, tools and MCP servers – then map how they relate to each other, then enforce policy on the interactions that matter. You cannot govern what you cannot see.

Does Imperva secure AI agents and MCP servers?

Imperva AI Application Security protects LLM-backed applications today. Thales announced the AI Security Fabric in December 2025, with an MCP security gateway and end-to-end runtime access control for agentic AI interactions on the 2026 roadmap.

Thales’s Imperva AI Application Security protects the AI powering your business applications, from LLM-backed chatbots to agents, RAG pipelines, and MCP-connected tools. Thales announced the AI Security Fabric in December 2025, adding an MCP security gateway and runtime access control for agentic AI interactions to the 2026 roadmap. See how it works here or read more in our white paper: Beyond the LLM Top 10 (Coming Soon)

The post Agentic AI Security: The Chatbot Era Is Already Over appeared first on Blog.

Not since the dot-com boom in the late 1990s has the world seen a more highly talked-about and sought-after tech revolution. Artificial Intelligence has entered every aspect of our lives – from building large scalable applications to your Monday morning Macchiato.

With this spread of wildly varying use cases, one thing became abundantly clear. Large Language Models have isolated context, which is limited to the training data and the inputs provided by a user. To expand this knowledge, we need to provide AI Agents with appropriate tooling to retrieve such information. A curl tool to view a webpage, a directory listing tool to retrieve files from a folder, or a git CLI tool to commit changes to a repo.

Humans need tools as well. We don’t sift through HTML code, read JSON responses or query API endpoints via the command line. Rather we rely on well-thought-out and structured UX components – icons, text fields, buttons, and checkboxes – all of which are wired into various functions and APIs in the backend.

AI Agents, however? They rely on different types of tools. Given that every single one of the billions of websites and applications on the Internet today works and operates differently, these tools need to cater to them. Sites have been built on everything ranging from PHP and ASP to Node and Express. The question becomes – how can I ensure my agent reliably interacts with each of these sites? You could argue that these days, most applications expose a lot of their functionality via APIs. And you would be right. While AI Agents can easily consume these APIs, it involves a few different steps –

• read the API reference documentation
• build a small handler to call this API, with appropriate context
• build a small handler to parse the response

All these steps, every single time. Every site, every application, requiring its own “code” built by the AI Agent. With limited context windows and larger thinking models, this can get out of hand quickly – both in terms of token count and time taken – for every single user prompt.

What is an MCP Server?

Enter the MCP Server. An MCP server is a standardized service that exposes a defined set of tools, resources and prompts to an AI agent over the Model Context Protocol, so the agent can act on an external system without hand-written glue code for every API. Developed by Anthropic, the Model Context Protocol was built as an open-source standard for connecting AI Applications to external systems. It was released in November 2024 and contributed to the Linux Foundation’s Agentic AI Foundation in December 2025; by that point more than 10,000 MCP servers had been published. In essence, providing the AI Agent the right tools and resources, for each of these applications, to help abstract away the complexity of each of these interactions. Think of it as a USB-C port for your AI Agent – one connector, and every application on the other side just works!
What can MCP Servers allow your agent to do? The use cases are endless and constantly expanding every day – from searching and booking flights to reviewing stock prices and executing trades (this is not financial advice!). MCP Servers give your AI Agent the tools it needs to do more than just be your information chatbot.

MCP Server Security Risks: Where the Exposure Actually Is

But all this functionality exposes a glaringly obvious security blind spot. Who is protecting your MCP Server, which now has tools exposed to action any of these tasks? Who is governing what can be asked of your AI Agent which now has access to these tools? The security implications are massive.
This is not theoretical. Imperva’s threat research team documented a critical remote code execution flaw (CVE-2025-53967) in the widely used Framelink Figma MCP server — an open-source project with more than 10,000 GitHub stars — and OWASP’s Gen AI Security Project published A Practical Guide for Secure MCP Server Development in February 2026 because the same weaknesses keep recurring. The MCP specification’s own security guidance now names token passthrough, session hijacking, the confused deputy problem and SSRF as first-class MCP risks.

Local vs. remote MCP servers: two different risk profiles

Now, not every MCP Server carries the same exposure. Plenty of them run locally – a process on your laptop, talking to your agent over stdio, never touching a network. The risk there is real, but it’s a different conversation: credentials sitting in a config file, and how much that server is allowed to reach on your behalf. The moment an MCP Server goes remote though – hosted, over HTTP, serving agents across the Internet – it stops being a local utility and becomes what it always really was underneath: an API endpoint. Exposed, authenticated, and waiting to be probed. That’s the one you can put controls in front of.
This is where Thales’s focus has been for the past several months. For decades, Thales Imperva has been at the forefront of securing sites and applications, and with the evolution of applications and their users, we’ve enabled our solutions to cover these use cases and the complex threat landscape.

Automated traffic is the baseline condition here, not the exception. Imperva’s 2026 Bad Bot Report found that bots accounted for more than 53% of all web traffic in 2025, up from 51% the year before — and that 27% of bot attacks targeted API endpoints. A remote MCP server is an API endpoint, so it inherits that traffic profile the moment it goes live. Knowing which AI bots to allow and which to block is the first control, not the last.
The Thales Imperva Cloud WAF and Advanced Bot Protection provide visibility into automated traffic heading towards the MCP Server, preventing generally malicious bot traffic and more exploitative OWASP Top 10 attack classes like command injection and SQL injection.

Thales Imperva API Security ensures your MCP Server has its own endpoints secured against everything from simple schema exploitation to complex business logic attacks. (For the wider picture of agents as API consumers, see API security for AI agents.)
Finally, our AI Application Security puts in place guardrails that sit between the AI Agent and the model behind it, securing the workflow against LLM-specific attacks like prompt injection, system prompt leakage and jailbreak attempts. And critically for MCP – it inspects what comes back from the tools, not just what goes in. Today, most people worry about user prompts. Far fewer are watching the tool response. Because an instruction buried in a log entry or an incident description can quietly make its way into your Agent’s context and get read as a command rather than data. Your MCP Server is a perfect delivery mechanism for exactly that.

Thales Imperva MCP Server for Cloud WAF

At Thales, we have also been working on our own MCP Server behind the scenes.

What does this mean for you? Imagine a world where you no longer have to log into a console to analyze where last week’s attack traffic came from. No more manually putting together a monthly executive presentation on the state of your security posture.

The Thales Imperva MCP Server for Cloud WAF is in beta today, and for now, it’s read-only by design. Your agent can query, analyze and report across your estate. Need to see which sites have your “Block requests from South Africa” ACL policy enabled? Or what security rules are enabled for your production site? Just ask your Agent! No prior knowledge strictly necessary.

It’s open source and available on GitHub – pull the container, add your API credentials, and point your agent at it.

Having trouble remembering regex for your custom rules? Or finding yourself constantly making individual site changes? Tell us! Beta feedback is what shapes where this goes.

Frequently asked questions about MCP server security

What is MCP server security?
MCP server security is the set of controls that protect a Model Context Protocol server — and the AI agent calling it — from abuse. Because a remote MCP server is an authenticated HTTP endpoint that exposes tools capable of real actions, it needs the same protections as any production API, plus AI-specific guardrails on the prompts and tool responses flowing through it.

What are the main MCP server security risks?
The recurring ones are prompt injection delivered through tool responses rather than user input, tool poisoning, over-broad OAuth scopes and token passthrough, session hijacking, SSRF during metadata discovery, the confused deputy problem in MCP proxy servers, and ordinary application flaws such as the command-injection RCE found in the Framelink Figma MCP server. Excessive tool permissions amplify all of them.

Are local MCP servers safer than remote ones?
They carry a different risk profile, not a smaller one. A local MCP server talking to the agent over stdio never touches the network, so the exposure is credentials in a config file and how far that server can reach on your behalf. A remote MCP server served over HTTP is Internet-facing, which makes it probeable — and also makes it something you can put network and API controls in front of.

Can a WAF protect an MCP server?
Yes, for the endpoint layer. Once an MCP server is remote it is an HTTP API, so a WAF and bot protection stop automated probing and injection-class attacks before they reach it, and API security covers schema abuse and business-logic attacks on its endpoints. What a WAF cannot do alone is judge intent inside the model workflow — that needs AI guardrails inspecting prompts and tool responses.

What are MCP server security best practices?
Treat the server as a production API: authenticate every inbound request and never accept tokens that were not issued for your server, use least-privilege scopes and non-deterministic session IDs bound to the user, validate and allowlist outbound URLs, start read-only before enabling write operations, log every tool call, and inspect tool responses as untrusted input. OWASP’s secure MCP development guide and the MCP specification’s security best practices are the reference baselines.

Secure your MCP server with Thales Imperva

MCP is now an open standard under the Linux Foundation, and the number of exposed servers is only going up. The controls are the ones you already know — web application and API protection in front of the endpoint, API security on its schemas and business logic, and AI application security on the prompts and tool responses moving through it. See how Thales Imperva secures applications and APIs, and try the read-only Cloud WAF MCP Server beta on GitHub.

The post MCP Server Security: The Blind Spot in Your AI Stack appeared first on Blog.

As evidenced by the Thales 2026 Data Threat Report, attackers increasingly target web applications and APIs with sophisticated methods that outpace the traditional protection built into cloud platforms. Security teams face intense pressure to deliver control and risk reduction, but this mandate creates frustration with DevOps teams, who push for speed and scale while leveraging the benefits of cloud-native tools.

The gap is best addressed by bringing the Thales enterprise-grade Imperva Web Application and API Protection (WAAP) solution directly into Australia’s Google Cloud infrastructure through a native integration. For Australian organisations running critical workloads in Google Cloud, this creates some important opportunities.

Data Sovereignty Is No Longer Just A Compliance Discussion

Organisations need confidence in where their data is stored, how it is processed, and who can access it.
For operators of critical infrastructure, the data itself is strategically significant. Data such ass traffic patterns, transaction flows, and operational telemetry from energy, financial, and health systems can reveal how essential services function, where dependencies lie, and how disruptions might be engineered. Losing visibility and control over where that data is processed and who can access it is a different order of risk. For businesses subject to SOCI Act, APRA CPS 234, or other government security mandates, controlling where data is stored and how it travels is essential for complying with Australian data sovereignty requirements.

Performance Matters When Security Becomes Part Of The Application Path

Security controls should not become a performance bottleneck. The conflict is tangible

While security teams want to ensure applications and APIs are protected with consistent security controls, visibility, compliance, and governance, DevSecOps teams want security that can be deployed quickly and integrated seamlessly into existing development workflows without creating operational overhead or slowing down application delivery.

This is one of the key reasons many organisations are showing strong interest in CI/CD-based onboarding models. Security teams prefer having the ability to deploy security controls without changing DNS records, modifying application architectures, or handing operational control of applications to another team or third-party provider.

Applications And APIs Have Become Primary Targets

A focus on websites is no longer enough for modern applications, as they depend on APIs, automation, third-party services, and machine-to-machine interactions that happen out of view of conventional monitoring. The threat actors understand this dependency and focus on the interfaces that run today’s digital services.

That is why WAAP has become such an important security category. Organisations need protection that addresses web application attacks, API abuse, automated bot activity, and Layer 7 denial-of-service attacks within a single security approach.

Imperva for Google Cloud delivers the same Imperva capabilities available through the broader cloud service, including Web Application Firewall (WAF) for cloud applications, API security, bot management, Layer 7 DDoS protection, and threat intelligence informed by global attack activity.

This is not a pared-down instance; Imperva for Google Cloud delivers the full WAAP stack locally, feature-for-feature, with the global service.

Built For Google Cloud Environments

Pressure on security teams to cut complexity is high. According to the Thales 2026 Data Threat Report, companies use 7 distinct data protection and monitoring solutions, yet visibility, staffing, and complexity remain major concerns for security teams.

As Imperva WAAP now operates within Google Cloud Australia, it makes perfect sense for solutions such as Google Cloud Load Balancing, Google Kubernetes Engine (GKE), Compute Engine, and other networking tools to work together with API security.

For cloud and platform teams, security can be deployed alongside applications rather than treated as a separate environment that requires its own operational model.

Security That Scales With Cloud Native Workloads

One of the reasons organisations move to cloud platforms is the ability to scale up or down. Security infrastructure should be able to do the same.

Regardless of whether a business is dealing with seasonal demand challenges, big public-facing platforms, high-volume APIs, or expanding digital services, the security layer must evolve with the applications and not require continuous redesign.

As more Australian organisations build cloud-native services, that expectation will become standard.
Organisations increasingly want security controls that operate where their applications operate. For businesses building on Google Cloud, keeping workloads within Australia is becoming a practical architectural decision rather than a future aspiration. By unifying Imperva’s proven application security leadership with Google Cloud’s high-performance infrastructure, organisations can eliminate the need to compromise between security and speed.

Get in contact with the local team and see how Imperva WAAP works in Google Cloud Australia.

The post Google Australia Customers Now Benefit From Imperva Cloud-Native WAAP Security appeared first on Blog.

APIs Changed Faster Than Security Architectures

Organizations have invested heavily in discovering APIs, classifying sensitive data, and understanding API risk. That’s progress.

But visibility alone doesn’t stop attacks.

Attackers don’t wait for analysts to review dashboards. They exploit broken authorization, enumerate objects, abuse business logic, and exfiltrate data in minutes.

Knowing an attack happened is useful.

Stopping it is what matters.

How Has Sovereignty Introduced a New Challenge?

For organizations operating in finance, government, healthcare, defense, and critical infrastructure, API security has always carried another requirement.

Data cannot leave the environment.

API payloads often contain customer records, financial information, healthcare data, or classified information. Regulations and increasingly internal governance policies require that this information stays under organizational control.

That’s why many organizations choose self-managed API security.

Not because they dislike cloud. Because they cannot compromise sovereignty.

Digital sovereignty means retaining control over where sensitive data is processed, where security decisions are made, and who ultimately governs the infrastructure, protecting critical services.

That’s why Thales’s Self-Managed Imperva API Security was built, to give organizations the flexibility to deploy API security wherever their business, operational, or regulatory requirements demand, while keeping sensitive inspection and enforcement under their control.

Yet sovereignty has historically introduced an unintended compromise.

The Missing Piece: Detection Without Enforcement

Historically, this created an operational gap.

Security teams could discover APIs.

They could identify risky endpoints.

They could detect sophisticated attacks such as Broken Object Level Authorization (BOLA), one of the most critical risks identified in the OWASP API Security Top 10.

But detection alone doesn’t interrupt an attack.

When enforcement exists outside the API security workflow, response becomes another investigation, another ticket, another operational handoff. Every delay gives attackers more time to exploit vulnerable APIs and access sensitive information.

Security teams weren’t lacking visibility.

They were lacking immediate action.

For organizations operating entirely within sovereign environments, this challenge was even greater. Protecting sensitive data meant keeping security operations local—but that shouldn’t mean sacrificing the ability to actively stop attacks.

Modern security should never force organizations to choose between operational control and effective protection.

This isn’t simply feature parity. It’s an architectural parity.

Detection and enforcement can now operate together where the data already resides.

Closing the Last Mile of Sovereign API Security

Today, that trade-off disappeared.

With the latest enhancement to Thales’ Self-Managed Imperva API Security, organizations can now extend active API enforcement into self-managed deployments while maintaining complete control over where inspection, detection, and enforcement take place.

This is more than a new capability.

It represents an important step toward a sovereign-by-design security architecture—one where security adapts to the customer’s operational model instead of requiring the customer to adapt to the security platform.

Organizations no longer have to choose between maintaining sovereign control over sensitive API traffic and deploying modern API protection capable of responding to attacks in real time.

Detection and enforcement now work together, exactly where the data already resides.

One Protection Model. Any Deployment.

Modern enterprises rarely operate in a single environment.

Applications span public cloud, private cloud, Kubernetes clusters, on-premises data centers, and increasingly hybrid infrastructures.

Security shouldn’t become fragmented simply because deployments are.

Whether organizations deploy Imperva API Security through a cloud-managed service or a self-managed environment, they should expect the same security intelligence, consistent policy model, and comparable protection outcomes.

The deployment model changes.

The protection model doesn’t.

For organizations embracing digital sovereignty, that’s an important distinction. They can adopt the architecture that best aligns with their regulatory obligations and operational requirements while maintaining a consistent security posture across every environment.

Digital Sovereignty Requires Security That Adapts

The future of cybersecurity isn’t simply about moving more workloads to the cloud.

It’s about giving organizations the freedom to choose where their data lives, where security operates, and how trust is established.

That is the essence of digital sovereignty.

Modern security platforms must deliver the same level of protection regardless of deployment model, enabling organizations to protect critical assets without compromising regulatory compliance, operational resilience, or customer trust.

API security should be no exception.

With Self-Managed Imperva API Security enforcement, organizations can now:

• Detect and stop critical API threats such as BOLA within the same sovereign environment.
• Maintain complete control over sensitive API traffic and enforcement policies.
• Apply a consistent protection model across cloud, hybrid, and self-managed deployments.
• Reduce operational complexity while strengthening resilience against modern API threats.

The Future Is Sovereign by Design

Digital sovereignty is no longer simply a regulatory discussion.

It’s becoming a defining principle of modern cybersecurity architecture.

As organizations continue to modernize applications, embrace AI, and expand digital services, they need security platforms that protect innovation without requiring sensitive data to leave their control.

That’s the direction Thales has long championed: security that enables trust, resilience, and customer choice.

The latest Self-Managed Imperva API Security enhancement is another step toward that vision, bringing active API protection to organizations that require complete operational control, without compromising the security outcomes they expect.

Because the future of API security won’t be defined by where it runs.

It will be defined by where trust resides.

And increasingly, trust begins with keeping control of exactly where it belongs.

Download this guide to discover how Imperva protects production APIs without compromising data sovereignty.

The post Closing the Sovereignty Gap: Bringing Active API Protection to Self-Managed Environments appeared first on Blog.

Imperva customers are protected against exploitation attempts associated with this vulnerability. Organizations using FastJson 1.x should enable SafeMode immediately and prioritize migration to FastJson 2.x. 

About the FastJson Vulnerability 

On July 21, 2026, the FastJson maintainers published a security advisory for a critical remote code execution vulnerability discovered by FearsOff Cybersecurity. FastJson is an open-source Java library originally developed by Alibaba for serializing Java objects into JSON and deserializing JSON into Java objects. 

The vulnerability affects FastJson versions 1.2.68 through 1.2.83, including 1.2.83, the final release in the FastJson 1.x branch. It’s been assigned CVE-2026-16723, with a CVSS score of 9.0, or Critical. According to the official FastJson advisory, exploitation has been verified in Spring Boot applications deployed as executable fat JARs across Spring Boot 2.x, 3.x, and 4.x and JDK versions 8, 11, 17, and 21. 

The issue is particularly dangerous because it is exploitable under FastJson’s default configuration. AutoType does not need to be enabled, and attackers do not need a suitable third-party gadget class to be present in the application’s classpath. Applications are potentially exposed when they process attacker-controlled JSON using common methods including JSON.parse, JSON.parseObject(String), and JSON.parseObject(String, Class). 

Specifying a target class during deserialization does not fully mitigate the vulnerability. An attacker may still be able to place a malicious payload inside a field typed as an Object or Map. 

How the Vulnerability Works 

FastJson supports polymorphic deserialization through the @type field, which identifies the Java class that should be instantiated from supplied JSON. Although FastJson 1.x disables AutoType by default and applies checks intended to prevent untrusted classes from being instantiated, the newly disclosed vulnerability exposes an alternate path through its internal type-resolution logic. 

An attacker can submit specially crafted JSON containing a malicious @type value. During processing, FastJson may perform resource lookups based on the attacker-controlled class name. In affected Spring Boot fat-JAR deployments, an attacker can manipulate this behavior using nested JAR URLs, bypass FastJson’s normal type restrictions, and reach a code-execution path without supplying a conventional deserialization gadget. 

This bypass is possible because FastJson 1.x can treat the presence of a @JSONType annotation as a trust signal during type resolution. The attacker-controlled resource lookup and annotation-based trust behavior combine to circumvent the protections normally associated with disabling AutoType. 

Successful exploitation can allow an unauthenticated remote attacker to execute arbitrary code with the privileges of the affected Java application. This could lead to data theft, malware or webshell deployment, credential compromise, lateral movement, or complete takeover of the underlying server. Public proof-of-concept information is available, substantially increasing the likelihood of rapid exploitation. 

FastJson 2.x is not affected. Its type-resolution architecture does not perform equivalent resource probing on user-controlled class names, does not use @JSONType as a trust signal, and uses an allowlist-first model for polymorphic type handling. 

What We’re Seeing 

So far, attacks exploiting this vulnerability are targeting a wide range of organizations, across Financial Services, Healthcare, Computing, Retail, Business, and other industries.

Attacks are currently almost entirely targeting US-based organizations, with a few attacks in Singapore and Canada, although this will likely continue to expand globally.  

Most attacks are coming from browser impersonators, although tools written in Ruby and Go account for about 30% of all attacks collectively.  

Mitigation and Protection 

Imperva customers are protected against exploitation attempts associated with CVE-2026-16723. Imperva Cloud WAF and WAF Gateway inspect incoming HTTP requests and identify malicious JSON payloads, suspicious @type values, nested JAR URL patterns, and remote code execution techniques before they reach vulnerable applications. 

Organizations should not rely on perimeter protection as a substitute for remediation. FastJson 1.x is no longer actively maintained, and no patched 1.x version has been released for this vulnerability. Organizations using an affected release should take the following actions: 

• Enable FastJson SafeMode immediately using the JVM option -DFastJson.parser.safeMode=true, the FastJson.parser.safeMode=true property, or ParserConfig.getGlobalInstance().setSafeMode(true).  

• Alternatively, use a FastJson noneautotype build, which removes the vulnerable AutoType-related code at compile time.  

• Inventory Java and Spring Boot applications for FastJson dependencies, including transitive dependencies.  

• Prioritize migration to FastJson 2.x after appropriate compatibility testing.  

• Review application and WAF logs for suspicious JSON requests containing @type fields or jar:http and jar:file URL patterns.  

• Investigate potentially affected systems for unexpected process execution, outbound connections, unauthorized file changes, webshells, or other indications of compromise.  

Because exploitation requires no authentication, no user interaction, and no external gadget library, exposed applications running affected configurations should be treated as high-priority remediation targets. Imperva customers remain protected while organizations identify vulnerable deployments, enable SafeMode, and migrate away from FastJson 1.x. 

The post Imperva Customers Protected Against CVE-2026-16723: Critical FastJson 1.x Zero-Day RCE appeared first on Blog.

Vulnerability Overview  

The vulnerability exists within the WordPress REST API, specifically affecting the /wp-json/batch/v1 and ?rest_route=/batch/v1 endpoints. An unauthenticated attacker can exploit this endpoint to achieve RCE.

Affected WordPress Versions: 

• 6.9.0 – 6.9.4 (Fixed in 6.9.5) 

• 7.0.0 – 7.0.1 (Fixed in 7.0.2) 

(Note: WordPress versions older than 6.9.0 are not affected by this specific vulnerability.)

Mitigation and Protection 

Imperva customers with both Cloud WAF and WAF-GW deployments are protected against exploitation attempts associated with the “wp2shell” vulnerability. Cloud WAF automatically inspects and blocks requests targeting the vulnerable REST API endpoints at the edge, mitigating the risk before it reaches your backend services. 

For organizations utilizing WAF-GW, we are providing policy updates to further harden protection. Administrators should apply the latest security policy updates to their WAF-GW environments to ensure these enhanced inspection capabilities are active. These updates provide another layer of defense, blocking the specific patterns associated with unauthorized batch API access before they can be processed by the WordPress core.

Recommended Best Practices 

While Imperva provides protection at the edge, we strongly recommend that all WordPress administrators take the following steps: 

1. Update Immediately: Ensure your WordPress installation is updated to the latest secure versions (6.9.5 or 7.0.2) as soon as possible. This is the only definitive way to resolve the underlying vulnerability. 
2. Emergency Mitigation: If an immediate upgrade is not possible, you can temporarily mitigate the risk by blocking access to the affected REST API endpoints:
   • Block requests to the path: /wp-json/batch/v1
   • Block requests containing the query parameter: rest_route=/batch/v1 

Note: These mitigation measures may impact legitimate site functionality and should only be used as a temporary stopgap until you are able to perform the necessary software updates. For more technical details regarding the vulnerability discovery, please refer to the official research advisory from Searchlight Cyber. 

The post Imperva Customers Protected Against “wp2shell” Pre-Authentication RCE in WordPress Core appeared first on Blog.

In this article, we disclose our latest findings we made on Perforce protocol P4 (Helix Core) between command line client and server, and reveal how a threat actor could leverage it to conduct attacks. 

This security issue affects P4 (Helix Core)  before P4 (Helix Core) 2025.2 Patch 2, was patched and was attributed a CVSS score of 7.7 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L). See our recommendation section and the Perforce advisory for more information. 

Perforce Helix Client  

Perforce Helix Client is a version control system often used for large projects and teams that work with many files or large assets. 

While Git and SVN are great for many projects, Perforce shines in environments with massive codebases or large binary files, like game development or VFX. It handles millions of files efficiently, lets teams lock files to prevent merge conflicts on non-text assets, and supports partial checkouts so developers don’t need the entire repository locally. 

Architecture 

Perforce operates on a centralized client-server architecture model, where the command-line client (p4) communicates directly with a centralized Perforce server responsible for managing the repository, metadata, and access controls. This communication can be established through Perforce’s native protocol (default port 1666) or wrapped into HTTPS to ensure encrypted data transmission.  

Fig. 1: Basic single server architecture  

• p4 info: typically one of the first commands executed to verify server connectivity and retrieve essential information, including server version, root directory…  
• The p4 client command creates and manages workspace specifications, defining the local root directory, depot paths, and the client view mapping that determines file accessibility.
• The p4 login command establishes authenticated sessions with the server, generating temporary tickets that allow subsequent commands to execute without re-entering credentials.
• The p4 sync, add, submit, revert … commands enable developers to manage the lifecycle of files in their workspace (synchronization, modification, addition, submission, and undoing changes). 

Eventually, whenever the P4CONFIG variable is set (usually .p4config), the client automatically loads configuration variables such as P4USER, P4PORT, P4CLIENT and P4PASSWD from the designated config file discovered in the current directory or home directory. This hierarchical configuration resolution applies within the scope of P4CLIENTPATH, allowing workspace-specific configurations to override global system settings. 

Details 

The Perforce client-server communication relies on a custom binary protocol, in which each message carries a set of parameters and a handler name designating the operation to be executed by the receiver. Multiple messages can be chained within a single exchange. 

Fig. 2: Extract from a clear traffic dump of a p4 info request 

This communication can be secured by SSL while the fingerprint of the server is added into a trust local file located at P4TRUST (itself defined in the p4 config file). 

During our investigation, we recorded the server traffic of several sensitive responses (triggering SSO response, writing files with arbitrary content to arbitrary location, etc. ) and observed that no validation of server response exists in the client side: 

1. No expiration timeout exists, as our recorded responses could work even days after they were generated. 
2. No session id is used during a connection. Therefore, we recorded the traffic between our client and server; and used the exact same response bytes in the dockerized POC that we shared with Perforce security team.  
3. The client doesn’t verify if the server response matches the request it initiated. 

Beyond the risk of replay attacks, the last point makes the following scenario possible:  

1. A threat actor shares the details of an unknown server to the victim. 
2. Upon initial connection to the server, it immediately responds with an instruction to write a malicious line into a configuration file ( ~/.p4enviro or .p4config for instance). The expression, P4LOGINSSO=<malicious shell command>, will be executed by any new p4 command. 

Indeed, the P4LOGINSSO environment variable is designed for SSO integrations: when set, the p4 client executes its value as a shell command to obtain authentication credentials.  

Fig. 3: Illustration of the first attack scenario 

Another scenario we presented was the following: 

• A threat actor shares a project including a hidden .p4config file with specially crafted P4PORT and P4LOGINSSO variables. 
• The victim executes any legitimate p4 command. 
• This command is sent to the malicious server defined in P4PORT that returns a “client-sso” instruction, immediately executed on the client side. 

Fig. 4: Illustration of the second scenario 

Post Exploitation 

Once exploited, this flaw enables attackers to achieve arbitrary code execution under the victim’s user account: the same context in which the p4 command runs.  

This grants full local control, allowing theft of sensitive data (e.g., source code, intellectual property, credentials), modification of files or configurations for persistence or further compromise, and disruption of workflows through file deletion or system resource exhaustion.  

In environments handling high-value assets, such as game development studios, VFX pipelines, or large-scale software projects, the business impact can be substantial, including IP loss, production delays, and potential downstream effects on team collaboration or supply chain integrity. 

Mitigation 

Following the reception of our report, Perforce security team requested an embargo until the release of v2026.1 (May 2026) to give them time to patch this issue.  

The fix introduced a built-in protection in the client that prevents syncing or submitting files matching Perforce configuration file names (.p4enviro, .p4config, etc.), regardless of workspace settings. The P4_SYSTEMIGNORE variable can be used to extend this list. However, this does not address the lack of binding between client requests and server responses, nor the absence of a replay timeout or session id. 

Recommendations  

Update your system to the latest available version. 

Organizations using Perforce command line client should treat this issue seriously and adopt the following guidelines: 

• Prevent exchange of configuration files from unvetted sources. 
• Educate users on the dangers of connecting to unknown or shared Perforce endpoints and encourage verification of server authenticity before executing any commands. 
• Enforce encrypted connections to reduce exposure to man in the middle attacks. 
• Monitor for unusual p4 activity, including unexpected server connections or configuration sourcing. 

Conclusion 

This vulnerability in the Perforce Helix Client highlights how widely used version control systems can contain overlooked risks in their core client-server communication, assumptions that the server is always trustworthy or responses are inherently safe. 

In environments with massive, distributed asset pipelines, such protocol-level gaps can quietly expose teams to compromise through everyday interactions like querying server info or loading shared configurations. 

As development tools evolve toward greater automation, integration, and reliance on external or unvetted endpoints, these subtle trust boundaries deserve renewed scrutiny. This finding is a reminder that supply chain attacks do not require compromising a central registry: embedding a malicious configuration file in a shared project artifact could be sufficient to achieve code execution across an entire team. 

Timeline 

October 20 2025 – Disclosure sent to Perforce security team.

October 21 2025 – Report acknowledged by the Perforce security team.

March 9 2026 – Patch released for 2025.2 and backported to prior supported versions. 

May 18 2026 – Release of 2026.1 and publication of the security advisory.  

The post Code Injection in Perforce Helix Core (CVE-2026-6902) appeared first on Blog.