The app your team built with AI may be leaking its users table. Check Supabase today

Somebody in marketing built a sign-up page over a weekend. A contractor shipped a customer portal in two sprints with a coding assistant. A founder launched a waitlist. A lot of those projects sit on Supabase, and a new study says thousands of them are leaving their tables readable by anyone who knows where to look.

The app shipped in a weekend. The row level security never shipped at all.

What happened

UpGuard researchers collected about 300,000 domains that showed signs of using Supabase, the hosted PostgreSQL platform popular with AI coding tools, and asked each database for a users table. They found 16,326 databases exposing readable tables. Based on table schemas, more than half had indicators of personal information, a smaller share appeared to hold passwords or authentication tokens, and a very small number had plausible payment card data. BleepingComputer covered the findings on September 28.

UpGuard checked a handful of cases by hand. They included a U.S. valet service exposing more than 100,000 customer records with phone numbers, license plates, and visit history; a Canadian immigration and relocation service with nearly 5,000 user records, 884 of them with plaintext passwords; an African government consulate with records on 25,000 people, including emergency housing locations; and a Philippines OTP service exposing over 100,000 SMS messages. UpGuard says it notified owners where it found significant exposure.

The cause is configuration, not a Supabase software flaw: missing or ineffective row level security (RLS) policies and public keys used as if they were secret. UpGuard notes Supabase now enables RLS by default for tables created in its Table Editor, but tables created programmatically through the API, which is how coding agents usually work, do not get RLS by default. UpGuard also stresses that its scan does not prove every affected site was built with an AI agent.

Why it matters

Security teams rarely know these projects exist. They start as experiments outside the normal review path, then quietly start collecting real customer data. The exposure also cuts both ways: about 11% of the email addresses in the valet dataset belonged to corporate domains, so your employees’ data can leak from someone else’s side project.

What to do first

• Ask around, out loud: who has a Supabase project connected to anything with real users? Check expense reports and SSO logs for Supabase sign-ups too.
• For each project, run Supabase’s security advisors and fix every table flagged without RLS.
• Enable RLS on every table in an exposed schema, revoke the default anon and authenticated grants you do not need, and write one explicit policy per operation. Supabase’s docs warn that a policy reading to anon using (true) gives every signed-out visitor read access.
• Make sure only the publishable (anon) key appears in client-side code. Secret keys, and the legacy service_role key, bypass RLS and must never ship to a browser.
• Rotate any keys that were exposed, and reset user passwords if a table with credentials was readable. Stop storing plaintext passwords; use Supabase Auth or proper hashing.

Details

• Research: UpGuard, “Everything Everywhere: Systemic Data Exposure in Supabase Apps” (published September 25, 2026)
• Scope: about 300,000 domains with Supabase indicators; 16,326 databases with readable tables
• Data types (schema-based): PII in more than half; passwords or auth tokens in a smaller subset; plausible card data in a very small number
• Root causes: missing or ineffective RLS policies; misuse of public keys
• Earlier related issue: CVE-2025-48757 (Lovable-generated Supabase databases missing access controls, reported March 2025)
• Not a Supabase product vulnerability: customer configuration issue

Hunt / verify

• Search your public JavaScript bundles and repos for supabase.co URLs and keys to find projects nobody registered.
• With only the publishable key, try reading each table through the REST endpoint from outside your network. If rows come back that should be private, the policy is wrong.
• Grep code and CI variables for secret or service_role keys and move them server-side.

Slack paste: Supabase: list every project with real users, run the security advisors, RLS on for every table with real policies, publishable key only in the browser, rotate exposed keys, no plaintext passwords.

Sources

• UpGuard: Everything Everywhere, systemic data exposure in Supabase apps (Sep 25, 2026)
• BleepingComputer: Over 16,000 Supabase databases expose PII, passwords, auth tokens (Sep 28, 2026)
• Supabase docs: Row Level Security

George Bailey

George Bailey is a cybersecurity researcher and writer at CyberExperts, covering cyber threats, AI, cloud security, vulnerabilities, and defensive strategies. His goal is to help security professionals quickly understand what matters most and how it impacts their organizations.