Incident file · Security
A support ticket reads your whole Supabase database (2025)
stored prompt injection leaking PII via SQL, self-reported
The system
A Supabase-backed support-ticket application: customers submit ticket text, developers use Cursor's IDE agent (connected to the database through Supabase's default MCP server) to triage and summarize tickets. The MCP server authenticates as the service_role key, a privileged Postgres role that bypasses Row Level Security (RLS), the mechanism Supabase normally relies on to scope what each application user can see.
What was observed
General Analysis demonstrated in July 2025 that a customer could embed an instruction inside the text of their own support ticket. When a developer later asked their Cursor agent to summarize "the latest ticket," the agent's response, posted back into the customer-visible ticket thread, contained other users' private data.
Stop and think
- Supabase's marketing and documentation describe RLS as enforced at the database level for all API access. Given that, how did private data from other users end up in this one customer's ticket thread?
- The injected text lived inside data the developer asked the agent to summarize, not inside anything the developer typed. What does that imply about which inputs you need to treat as untrusted?
- The leaked data came back out through the same ticket thread the attacker created. What made that an effective exfiltration channel, as opposed to, say, an internal log the attacker could never see?
Answer the questions above before you read on: what failed, why, and what would have stopped it.