Supabase MCP: A Support Ticket Made Cursor Leak the Integration Tokens Table

What happened

In July 2025, researchers at General Analysis showed how a developer's coding assistant could be turned against the developer's own database. The setup was a demo customer-support app on a fresh Supabase project, filled with dummy data and with row-level security (RLS) switched on. A developer used Cursor with the Supabase MCP server, which lets the assistant run SQL against the project. An anonymous customer filed a support ticket containing instructions written for that assistant. When the developer later asked Cursor to show the latest open ticket, the assistant read the private integration_tokens table and posted its contents back into the ticket thread, where the customer could read them. This was a research demonstration on test data. In September 2025, Supabase said no customer had reported a data leak through MCP.

How the attack worked

The app kept tickets in support_tickets, the conversation on each ticket in support_messages, and provider secrets in integration_tokens. Customers wrote through a public form under the restricted anon role. Support staff used a role limited to the support tables, so when a human agent opened the attacker's ticket and replied, nothing leaked.

The developer's session was different. Cursor's queries ran under service_role, a role that bypasses RLS by design. Asked for the latest open ticket, the assistant loaded the schema, listed tickets, filtered for open ones and fetched the messages on the newest. One of those messages was the attacker's. The assistant treated its embedded instructions as part of the task and issued two more queries: one to read every row of the tokens table, and one to insert the result as a new message on the same ticket. In Cursor these looked like routine tool calls unless the developer expanded them. The attacker refreshed the ticket page and read the secrets.

Root cause

No permission was broken. Every query ran with privileges the developer had granted. The flaw was that text from the least trusted party in the system, an anonymous customer, reached a model running under the most privileged role in the app, and nothing kept the two apart. The tool that read the ticket could also write to it, so the channel that delivered the instructions also carried the data back. RLS could not help, because the assistant's role was built to skip it.

What a test would have caught

One planted ticket would have found it. Write a customer message that asks the assistant to read a table the request does not need, have a developer ask a routine question about tickets, and watch two things: whether the assistant queries a table outside the task, and whether any value from a private table is written somewhere a customer can read. Either result fails the test; the second is the leak itself.

How to prevent it

• Keep privileged roles and production data away from agents. In its September 2025 response, Supabase told developers to keep agents off production data and to give them development or anonymised data instead.
• Run read-only and project-scoped. Read-only mode blocks the write that carried the tokens back. General Analysis warns that data read this way can still leave through other tools or outputs, so check those paths too.
• Keep manual approval on. A request to view a ticket gives no reason to query a tokens table, and a reviewer who expands the call can see that.
• Track where values came from. Data read from a private table should never reach a sink the public can read, whatever the instructions say. Supabase's server now wraps query results in a warning not to follow embedded commands, and its own documentation says that is not a complete defence.