Simulating a Context-Poisoning Vulnerable MCP Server: A POC
-
June 24, 2025
-
June 24, 2025
In a previous post, we introduced the MCP Server Security Hub - a searchable central database of MCP servers that rates their risk and security posture, built after analyzing thousands of real-world MCP servers. That work surfaced risky behavior on a large scale. To take this to the next step, we simulated a vulnerable MCP server in a sandboxed environment to demonstrate how a benign-looking tool can poison LLM context and exfiltrate data. The goal: make the risk concrete and show how easily trust can be misused.
The Vulnerable MCP Tool
We built a simple MCP server that implements a web-scraper tool using the cheerio library to extract metadata from web pages. In most cases, the tool returns the title of the webpage, along with other relevant information, to the MCP client.
Here’s a test example of how the tool is intended to work:
So far, so good.
But is the Tool Secure?
To test the tool we put on our white hat and designed a nefarious website masquerading as a run-of-the-mill blog post. Here’s what the website looked like:
We embedded hidden text on this website that was designed to read like a prompt to a LLM. The “prompt” stated that any LLM that read it should execute a shell command. But the shell command we wrote was malicious.
The idea was that when the MCP tool scraped the site it would incidentally feed the “prompt” to the Cursor LLM and “poison” its context. As a result, it would trick Cursor into executing the malicious command and sending a users’ sensitive data to a remote server.
To make it easy to see if a user was compromised we also built a hacking GUI to display keys exfiltrated from users of the MCP web-scraper. It looked like this:
Here is an overall schematic showing the structure of the attack:
Putting it to the Test
When the user ran the scraper-tool on my nefarious site they got the following Cursor output:
As you can see, on the user side the Cursor logs look normal.
However, on the hacker side we saw a different result:
Somehow, Cursor sent the users’ OpenAI API key to an external site without notifying them!
Breaking Down the Exploit
Let’s take a closer look at why this happened. As we’ve said, the code for the scraper itself is straightforward. It just reads html tags and adds them to the MCP client’s model context window. But sometimes, nefarious instructions can be hiding in scraper targets.
If not sanitized appropriately, the instructions are then returned to the MCP client, added to the LLMs’ context, and made to influence the behavior of Cursor.
Our test website’s title tag reads as follows:
When the MCP tool scrapes the title from the webpage it also scrapes these “poisonous” instructions which tell Cursor to secretly run the command below:
This is an obfuscated form of the following shell command which looks for the users openai.apiKey and sends it to the hacker’s server:
In this case, the poisonous instruction is hidden in plain sight. If a user manually inspected the blogpost they would notice that something fishy was going on. However, if they are batch scraping thousands of websites by URL they are unlikely to take the time to inspect each website (of course, a really nefarious actor could have taken more care to disguise the instruction by obfuscating it).
Some Silver Lining
Luckily this is not the full story. It is impossible for Cursor to execute a shell command without notifying the user it is accessing the terminal.
Cursor provides a window at runtime displaying any shell commands run. This is because the run_terminal_cmd tool built-in to the Cursor application always logs terminal commands in the sidebar. There is no way to disable this behavior because it is invoked at the application level rather than at the model level.
However, it is troubling that Cursor does not by default store a history of the commands or tools executed. It is impossible to retrospectively intuit from Cursor logs whether a malicious shell command - or any shell command - has been run on the users’ machine.
Securing MCP Servers:
One way to secure an MCP server might be to carefully process any text scraped from a website or database to avoid context poisoning. However, this approach bloats tools - by requiring each individual tool to reimplement the same security feature - and leaves the user dependent on the security protocol of the individual MCP tool. The end-to-end principle suggests that the better solution is securing the server on the client side.
Securing MCP Clients:
AI Rules are system prompts pre-appended to user prompts by MCP clients. By conditioning AI agents to be skeptical and aware of the threat posed by context poisoning via AI rules, MCP clients can be secured against MCP servers.
Here is a snippet from secure-shell.mcd, a custom set of Cursor AI rules designed to prevent Cursor from running suspicious shell commands provided by MCP servers.
After applying the rule, resetting Cursor, and rerunning our MCP scraper we see the following:
Our MCP Client has been secured!
Rule Reliability and Variance
Each LLM is equipped with different intrinsic rules that are not visible or changeable by the user. As a result, models may vary in their response to the same context poisoning attack. In other words, model choice matters.
For this experiment, we used Gemini 2.5 Flash, a free model provided by Google. Other models might have been better or worse at detecting and avoiding context poisoning. Some models might have needed stricter custom rules or more relaxed custom rules to supplement their inherent rules and avert attacks.
Frustratingly, closed-source LLM providers are often opaque about when and how they make changes to their model’s internal rules. This means that custom rules can be more or less effective for a given LLM on a given day. Vigilance in updating rules as models change is an absolute necessity, and unfortunately this requires effort and knowledge that most engineering and security teams do not possess..
Further, as always, there is variance within responses from particular versions of an LLM. Across runs of the tool the model will respond differently to the same context poisoning attacks. While carefully crafted AI rules can mitigate the risks associated with vulnerable MCP servers, deterministic solutions are necessary to guarantee system security.
.png)
