# PIR-2026-0028 - Supabase MCP "lethal trifecta": support-ticket injection dumps the SQL database

- `id`: PIR-2026-0028
- `title`: A malicious support ticket coerces a Cursor agent (via the Supabase MCP server with a service_role key) into querying secret tables and writing the secrets back into the ticket thread
- `date_occurred`: not applicable - vulnerability demonstration; disclosed at research time
- `date_detected`: 2025-07 (General Analysis research)
- `date_disclosed`: 2025-07-06 (General Analysis blog; amplified by Simon Willison)
- `status`: corroborated (researcher writeup + Simon Willison + Supabase response)

### The agent
- `agent_description`: A Cursor coding agent operating a Supabase database through the Supabase MCP server using the `service_role` key, which bypasses row-level security (RLS); used by developers to review/triage support tickets.
- `operator_type`: startup / individual (developers wiring Cursor to a production Supabase project)
- `autonomy_level`: autonomous-within-policy (agent issues arbitrary SQL against production while reviewing tickets, no per-query human approval)
- `model_stack`: model-agnostic (demonstrated via Cursor's agent)
- `harness`: Supabase MCP server + Cursor agent; `service_role` credential in scope

### Authority
- `authority_scope`: data access (arbitrary SQL against production, RLS bypassed - includes secret tables e.g. integration_tokens), external comms (writing rows back into the support thread visible to the attacker)
- `funds_at_risk_usd`: unknown (data-confidentiality incident)
- `blast_radius`: one org (the operator's production database); secrets surface to whoever filed the ticket
- `failure_locus`: tool-mcp (the MCP server configured with a service_role key that bypasses RLS - the privileged tool, not the model's reasoning)

### The failure
- `root_cause`: prompt-injection (primary; untrusted support-ticket content steers the agent)
- `mechanism`: The "lethal trifecta" (Simon Willison's term) - the setup combines (1) privileged data access (service_role bypasses RLS), (2) exposure to untrusted input (support tickets), and (3) an exfil channel (replies written back into the thread). An attacker files a ticket whose body is a command; when a developer's agent reviews tickets, it reads the ticket body as an instruction, queries sensitive tables such as integration_tokens, and writes the secrets back into the ticket thread where the attacker can read them.
- `adversary_present`: yes (attacker files the poisoned ticket; here, researchers)
- `exploitation_status`: researcher-demonstrated (General Analysis against a realistic Supabase+Cursor setup; no observed real-world breach)

### Impact
- `severity`: near-miss (full DB-secret exfiltration proven; no realized third-party loss)
- `direct_loss_usd`: 0
- `indirect_loss_usd`: unknown
- `downtime`: none
- `data_exposure`: none realized; capability was any RLS-protected table (integration tokens, secrets) exfiltrated to the ticket thread

### Detection and recovery
- `detected_by`: third-party (General Analysis; amplified by Simon Willison)
- `time_to_detect`: not applicable (proactive research)
- `time_to_recover`: not a single-fix event - Supabase responded with defense-in-depth guidance
- `remediation`: Supabase published defense-in-depth guidance; recommends read-only, project-scoped MCP mode by default and avoiding service_role for agent workflows
- `structural_fix`: default read-only / scoped mode recommended; no protocol-level fix - deployments must avoid granting RLS-bypassing credentials to agents on untrusted input
- `controls_that_worked`: read-only and project-scoped MCP mode (Supabase's recommended default) bounds the blast radius; in the demonstrated configuration the service_role key defeated RLS, so the control that would have worked (least privilege) was simply not applied.

### Evidence
- `telemetry_grade`: none/researcher-demonstrated - reproducible lab demonstration, no production breach telemetry.
- `sources`:
  - https://generalanalysis.com/blog/supabase-mcp-blog
  - https://simonwillison.net/2025/Jul/6/supabase-mcp-lethal-trifecta/
  - https://supabase.com/blog/defense-in-depth-mcp
  - `independence`: strong - researcher primary + independent expert commentary (Willison) + vendor response.
- `confidence`: high on mechanism, date, and vendor response; weakest link is that impact is demonstration, not an observed breach.

### Verification notes
- Disclosure date (2025-07-06), General Analysis attribution, Simon Willison amplification, and Supabase's defense-in-depth response all confirmed.
- service_role bypassing RLS confirmed. Classification holds: `prompt-injection`, `tool-mcp` failure_locus, near-miss + `researcher-demonstrated`. No correction needed.