Leaked Supabase service-role key — worst-case exposure

The Supabase service-role key bypasses every Row-Level-Security policy you wrote. If yours was committed or exposed client-side, every row in every table is readable and writable. This is the most damaging leak in the AI-built-app era.

The next 60 seconds matter

The attacker loads the key into a Supabase client configured with server-role privileges. Every RLS policy is ignored. Every table is open for read, write, and delete. The attacker typically exfiltrates users, rotates them into the attacker's control, and drops destruction evidence on the way out.

  • Full read on every table including PII, tokens, and secrets
  • Full write on every table — set admin flags, alter account ownership
  • Drop tables or truncate rows to hide activity
  • Modify RLS policies for long-term persistence

Rotation playbook

  1. Go to app.supabase.com → Project Settings → API → Roll service_role secret
  2. The rolled key invalidates the old one within seconds
  3. Update every server environment (Vercel, GitHub Actions, worker queues)
  4. Review the audit log: app.supabase.com → Reports → Audit Log (last 30 days)
  5. If uncertain what the attacker touched: restore from your most recent backup predating the leak

Prevent the next one

  • NEVER use service-role key in any client-side code — anon key only
  • Never commit service-role key to git, even in .env.example
  • Store it in a secrets manager (Vercel env vars marked 'Sensitive', Doppler, 1Password)
  • Enable Supabase Audit Log reviews monthly
Pattern we scan for
eyJhbG... JWT with `role: 'service_role'` payload