VibeUpGuard research: 16,326 Supabase databases had tables anyone could read
Summary
Supabase's CISO, Bil Harmer, told TechCrunch the company had not seen the research, that Supabase projects are 'secure by default', and that security is shared: Supabase provides defaults and tooling, customers control their own configuration. The research itself: UpGuard collected about 300,000 domains showing signs of Supabase use and found 16,326 databases with tables readable from the public internet. This is a scan of misconfigured customer projects, not a breach of Supabase. More than half of those databases had schema signs of personal data. UpGuard links the problem to tables that AI coding agents create through the API, where Row Level Security is not switched on by default.
Severity
Timeline
CVE-2025-48757: misconfigured Supabase databases behind Lovable apps reported (see our separate entry).
TechCrunch and Unite.AI report UpGuard's findings. TechCrunch includes Supabase's response.
Publish date shown on UpGuard's own blog post.
How it happened
Supabase apps talk to the database from the browser with a public (anon) key. Row Level Security policies decide what that key may read. According to UpGuard, Supabase now turns RLS on by default for tables made in the Table Editor, but tables created programmatically through the API, the route coding agents use, do not get it by default. UpGuard found Supabase projects through BuiltWith and Chrome UX Report data, asked each database for a 'users' table, and classified exposed data from table schemas rather than reading every row. Where it confirmed a significant exposure, UpGuard says it notified the app owners. We do not name any of the exposed apps.
How to check your app
- In the Supabase dashboard, confirm Row Level Security is enabled on every table in exposed schemas, including tables your AI agent created through migrations or the API.
- Enabling RLS is not enough: read each policy and make sure it limits rows to the signed-in user (for example auth.uid() = user_id), not 'true'.
- Test with only your public anon key, as an outsider would: query your tables through the REST API and confirm nothing private comes back.
- Keep the service_role key out of any front-end code or public repo.
Sources
- UpGuard: Everything Everywhere: Systemic Data Exposure in Supabase Apps
- TechCrunch: Some Supabase customers are publicly exposing reams of people's data to the web
- Unite.AI: UpGuard study finds 16,326 Supabase databases exposing readable tables
Corrections and updates
Source notes: UpGuard's blog shows a publish date of Oct 13, 2026, while TechCrunch covered the research on Sep 25, 2026; we list both. UpGuard credits CVE-2025-48757 to 'Matt Turner'; the CVE's other sources, including our own entry, name researcher Matt Palmer.