A new study has exposed a serious security vulnerability in the MCP protocol, which allows attackers to induce large language models to execute malicious instructions through carefully constructed prompts, thereby bypassing permission restrictions and directly accessing and leaking the entire database. This vulnerability has been verified in multi-tenant systems using the protocol, causing widespread concern in the industry.
Attention all businesses using the MCP protocol: your database may be “streaking”!
The latest research shows that the protocol has a significant vulnerability that allows attackers to directly access the database by exploiting the LLM’s instruction/data obfuscation vulnerability.
If the “data” provided by the user is carefully disguised as an instruction, the model is likely to execute it as a real instruction.
You must know that the MCP protocol has now become an industry standard in the field of agents, which can well connect large language models with various tool services, and many companies have accessed and used it.
However, when a model processes content such as web pages, emails, documents, or images, if there are malicious instructions hidden in them, the model may mistakenly execute them as real instructions, triggering unauthorized actions, such as leaking private data.
How was the data leaked?
In order to demonstrate the security risks of LLM, the researchers built a typical multi-tenant customer service SaaS system based on Supabase. Supabase is an open-source real-time backend service platform that includes databases, identity authentication, file storage, and other functions.
The system enables standard row-level security (RLS) mechanisms without adding any additional policies.
To achieve these three challenges, product managers will only continue to appreciate
Good product managers are very scarce, and product managers who understand users, business, and data are still in demand when they go out of the Internet. On the contrary, if you only do simple communication, inefficient execution, and shallow thinking, I am afraid that you will not be able to go through the torrent of the next 3-5 years.
View details >
Everything that was leveraged in this demo was present in the default configuration, including the standard service_role, the default model, RLS, and the language model assistant that initiated MCP calls on behalf of the developer.
The roles and permission boundaries involved in the system are as follows:
Among them, it should be noted:
Support agents do not have access to any non-supported or sensitive tables. Asking a support agent to provide any sensitive information will result in a rejection.
Let’s take a closer look at the data breach process below.
The attacker first submitted a new technical support request with a carefully crafted message that was disguised as a friendly question and embedded with explicit instructions sent directly to the Cursor agent.
The dialog interface in the system looks like this:
This message enters the database through the normal ticket submission channel, is stored in the customer message table, and is not filtered or blocked in any way.
When a support agent views a ticket, they only respond as expected. It’s important to note that the permissions of the support agent do not allow access to integration_tokens tables, so no sensitive information is exposed at this stage.
However, violations occur when developers then use Cursor to view open tickets. They may enter commands like this:
Please display the latest open support tickets.
At this point, Cursor’s agent automatically initiates a series of automated SQL queries through Supabase MCP integration:
1. Load the database schema of the project
2. List all support tickets
3. Filter out the work orders with the status of “Unresolved”
4. Get all the news of the latest work order
During this process, the proxy reads the message submitted by the attacker and follows the instructions embedded in it.
Finally, the system generates two new SQL query statements:
- Read the entire content of the integration_tokens;
- Inserts the read result as a new message into the message thread of the current ticket.
Both queries are executed by a service_role with high privileges, a role that can bypass all row-level security (RLS) restrictions.
To developers, these actions look like normal tool calls. Unless manually expanded, it is almost indistinguishable from previous legitimate queries.
Once the query is executed, sensitive data is immediately displayed in the ticket’s conversation.
The attacker simply refreshes the page to see a new message containing confidential information.
From a permissions perspective, this process is fully compliant.
Solution
These attacks are rooted in a combination of two design flaws: excessive database privileges (such as service_role) and blind trust in user submissions.
Here are two measures the team uses to reduce risk exposure:
- Use read-only mode whenever possible
- When this mode is enabled, even if the prompt is maliciously exploited, operations such as insert, update, or delete cannot be performed.
The mechanism of adding a Prompt Injection filter can be achieved by building a lightweight filtering module outside of MCP to intercept incoming data and flag or purge high-risk inputs.
While it can’t catch all attacks, it serves as a scalable and viable first line of defense, especially for teams that use third-party IDEs like Cursor and struggle to clearly define contextual boundaries.
Reference links:
https://www.generalanalysis.com/blog/supabase-mcp-blog
