An attacker submitted a support ticket containing instructions addressed to an AI coding agent. The text was stored in the application's database as ordinary customer content.
When a developer later asked Cursor to summarize recent tickets, Cursor's agent retrieved that message through the Supabase MCP server, followed the embedded instructions, read a table of OAuth secrets using the service_role credential, and wrote the contents back into the attacker's own ticket thread. Row-Level Security was enabled and enforced throughout, and no access control was violated.
- CVE: None was assigned. This is a design and configuration failure rather than a code defect in Supabase, Cursor, or MCP itself.
- OWASP LLM Top 10 (2026): LLM01 Prompt Injection, where it appears as Scenario #9, trusted-backend indirect injection through MCP. It also maps to LLM03 Excessive Agency.
- Products: Supabase MCP server, self-hosted and accessed through Cursor. The pattern generalizes to any MCP server holding elevated database credentials.
- Discovered by: General Analysis (Rez Havaei, Rex Liu, and Maximilian Li), published July 2025. The page now carries a later review date following a site migration.
- Impact: Disclosure of any table reachable by the developer's agent, exfiltrated through the application's own data with no outbound network request.
- Status: Supabase disputed parts of the framing and confirmed no customer incident. Mitigations shipped, and Supabase's own position is that the underlying problem is not solved.
The setup
General Analysis built a fresh Supabase project modeling an ordinary multi-tenant support SaaS. Row-Level Security was enabled exactly as documented, the data was dummy data, and no custom extensions or policies were added. Every element the attack depends on is present in an out-of-the-box configuration.
There are four actors, and the privilege boundaries between them are the whole story:
| Actor | Interface | Credential | Reach |
|---|---|---|---|
| Customer / attacker | Public ticket form | anon |
Own rows only, RLS enforced |
| Support agent | Support dashboard | support |
support_* tables only, RLS enforced |
| Developer | Cursor plus Supabase MCP | service_role |
Every table, RLS bypassed by design |
| IDE assistant | LLM invoked by Cursor | Runs SQL as service_role |
Whatever the text tells it to run |
Three tables matter. support_tickets and support_messages hold the customer-facing conversation. integration_tokens holds OAuth secrets and session credentials. RLS is on for all three. The service_role credential sidesteps those policies, which is what service_role exists to do.
The weak link is the last row of that table. The IDE assistant reads untrusted customer text and simultaneously holds the credential that ignores every access control in the database.
The attack
The attacker opens a ticket. The body contains a bland question aimed at the human support bot, followed by a block of text addressed by name to the agent running inside Cursor. Those instructions tell it to read integration_tokens and insert the contents as a new message on this ticket, and to reply with nothing but an acknowledgment. The stated justifications are latency and token savings, which is social engineering aimed at suppressing the agent's narration of what it just did.
The message is plainly suspicious to a human reader. It nonetheless travels through the normal support flow, is stored like any other message in support_messages with sender_role = 'customer', and is never filtered or blocked.
A support agent opens the ticket and replies as usual. Nothing leaks at this stage, because the support role has no path to integration_tokens and a request for that data would be refused.
The breach happens later, and a developer doing their job triggers it. They type something like "show me the latest open support ticket." Cursor's agent runs its usual sequence: load the project schema, list tickets, filter for open ones, and fetch messages for the newest. That final step pulls the payload into the context window, and the agent treats it as instruction.
Two additional queries follow. One reads the full contents of integration_tokens. The other inserts the results into the same ticket thread as a new message. Both execute under service_role, so RLS never applies. In the Cursor interface they look like the tool calls that preceded them, and unless the developer manually expands each one they are indistinguishable from the legitimate queries.
The attacker refreshes the ticket page they already have open and reads the secrets in the reply.
No permission was violated at any point, and every query was authorized. The agent simply followed instructions it should never have trusted.
Why the exfiltration channel is the interesting part
Most writeups in this class end with data leaving over the network, whether through a Markdown image URL, a DNS query, or a webhook. This one never touches the network. The exfiltration channel is the application's own database, writing into a table the attacker is already permitted to read as part of normal operation.
That has direct consequences for defense. Egress filtering does not help. Allowlisting outbound domains does not help. There is no Content Security Policy involved. The data moved only because a single credential could read a secrets table and write to a customer-visible one, and the agent held that credential.
Simon Willison filed this under the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate outward. His sharper observation is that the Supabase MCP, like the GitHub MCP before it, supplies all three legs from a single server, so a user does not have to compose a dangerous setup out of several tools. One is sufficient. He also notes that read-only mode removes the third leg in this specific case, because the exfiltration was a database write, and that Supabase's documentation at the time understated how load-bearing that flag was.
Supabase's response
Bil Harmer's September 2025 post is worth reading in full, because it disputes some of the framing and then concedes the substance.
Three corrections are worth recording. There has been no reported customer data leak via MCP. Supabase has never offered a hosted MCP server, since the implementation is open source and intended to be self-hosted or hosted by a third party such as Cursor. MCP does not bypass RLS. That last point is a fair distinction: RLS was enforced throughout, and the MCP server was simply configured with a role that outranks it.
The concession is the part that matters. Supabase had already shipped read-only mode, project-scoped mode, and feature groups. Their engineers then tried the guardrails everyone tries. They wrapped query results with warnings telling the model not to follow embedded commands, and they tested against weaker models that are more susceptible to injection. They experimented with LLM classifiers to identify dangerous content. The specific published attacks stopped working. Their own summary is that these approaches reduced risk without eliminating it, and that guardrails alone are not enough.
Their recommended fix is not a filter but an environment boundary. Do not connect agents to production data. Use development, staging, branched, or anonymized databases instead. Keep per-tool-call approval enabled in the client, while remaining aware of approval fatigue and of actions rendered off screen. For teams running the full stack including the model, they point to CaMeL, which quarantines untrusted data in one model and keeps control flow in a separate privileged one.
Harmer is also blunt about why this keeps happening. The people wiring agents into live databases are frequently building alone, with no staging environment and no security review, directly against production.
The pattern
The generalization worth carrying away concerns neither Supabase nor MCP specifically. This is the confused deputy problem restated for agents. An attacker who cannot reach a resource finds a party who can and induces them to fetch it. Here the deputy is the developer's own assistant, running under the developer's credential, doing exactly what it was built to do.
The attacker needed no infrastructure access, no credential, and no exploit. They needed a text field that a privileged agent would eventually read. In any application with user-generated content, that field already exists.
Sources
- General Analysis, "Supabase MCP can leak your entire SQL database", the original writeup with the schema, the payload, and screenshots of the execution
- Supabase, "Defense in Depth for MCP Servers", the vendor response, including what their guardrail attempts did and did not achieve
- Simon Willison's analysis, placing it in the lethal trifecta frame
- The Lethal Trifecta, the original framing, published a few weeks earlier
- Invariant Labs on the GitHub MCP vulnerability, the same pattern against private repositories
- Hacker News discussion, including replies from Supabase engineers
Source: r/pwnhub · by /u/_cybersecurity_