Model context protocol (MCP) gives IT teams a standardized way to connect large language models (LLMs) to tools and data sources when developing AI-based workflows.
But security researchers warn that MCP-based AI workflows can be vulnerable to malicious prompt injection attacks if session ID management was implemented insecurely on the MCP servers facilitating the connection.
“Although Session Hijacking is a well-known vulnerability in web applications, Prompt Hijacking is a new spin on this vulnerability and a dangerous attack vector enabled by MCP’s interaction patterns, as seen in MCP servers that generate predictable session IDs,” researchers from security firm JFrog wrote in a new report.
An example of how this issue can impact AI workflows and agents is a recent vulnerability that JFrog found in oatpp-mcp, the MCP implementation for Oat++ (oatpp), a popular framework for developing web applications in C++. Tracked as CVE-2025-6515, the flaw stems from the fact that oatpp-mcp generates guessable session IDs for use in its communication with MCP clients, an issue that other MCP servers might have as well.
How MCP servers secure communication
The Model Context Protocol was developed by AI company Anthropic to allow communication between LLMs and external data sources or applications to improve workflow context. MCP has been widely adopted and is a key component in developing AI agents that automate tasks by leveraging external tools.
MCP uses a client-server model and supports multiple communication methods. An application or data source that wants to expose its contents or functionality to an LLM does so to its own MCP server, and the AI agent, AI chatbot application, or IDE that is the interface for interacting with an LLM through prompts can pull in context data from MCP servers through an MCP client implementation.
Let’s say a developer working in an IDE that has their favorite model plugged in tells the model to find the best Python package for a particular task. The model can use the IDE’s MCP client to connect to an MCP server designed to search for the Python Index (PyPI) and return a package name for that query.
MCP servers and clients support several types of communication, including HTTP with Server-Sent Events (SSE). In this transport mechanism, which is used by oatpp-mcp, the client initiates a connection to the server with a GET request and the server generates and responds with a session ID. Then the client can use that session ID to send POST requests to the endpoints exposed by the MCP server and the server will return the results in JSON format.
Session IDs must be unique and secure
The session IDs are a way for the MCP server to differentiate between simultaneous connections from different clients, which is why it’s important for them to be unique and generated in a cryptographically secure manner — meaning they can’t be guessed. This is a requirement in the new Streamable HTTP specification of the MCP protocol, but it wasn’t a requirement in the original SSE transport specification, meaning that many MCP servers might not have implemented session ID uniqueness.
“Since the session ID determines where the server sends its responses, leaking it opens the door to abuse,” JFrog’s researchers warn. “An attacker that obtains a valid session ID can send malicious requests to the MCP server. These requests are processed by the server as if they came from the legitimate client, and the responses are sent back to the original client session.”
For oatpp-mcp, the JFrog researchers demonstrated how attackers could open a large number of connections to the MCP server to generate session IDs and then close the connections so those session IDs can be freed and reassigned to legitimate clients. The attackers can then reuse those IDs to trick the server into generating malicious responses to those clients.
“MCP supports structured requests, including prompts,” the researchers noted. “For example, a client may request a prompt from the server — but during that time, an attacker can inject their own malicious prompt. The client will then receive and potentially act on the attacker’s poisoned response instead of its own legitimate response.”
Mitigations
First, MCP server developers must review their implementations and use cryptographically secure random number generators with at least 128 bits of entropy in order to generate unique session IDs that are not reused.
If servers don’t do this, the MCP client side can use event IDs for its requests to mitigate this issue by only accepting responses with the same event ID. Like with sessions, these event IDs need to be unpredictable. Unfortunately, the researchers found that many MCP clients use incremental event IDs that can be brute-forced.
“As AI models become increasingly embedded in workflows via protocols like MCP, they inherit new risks — this session-level exploit shows how the model itself remains untouched while the ecosystem around it is compromised,” the researchers said.