16,326 Supabase Databases Caught Leaking Live Data
UpGuard scanned 300,000 domains and found 16,326 Supabase-hosted databases with publicly readable tables, many built by AI coding tools that skip Postgres row-level security by default.
6 min read
Of roughly 300,000 domains scanned for Supabase usage, 16,326 came back with a database anyone on the internet could query directly - no login, no API key, just a URL.
That's the headline number from a new UpGuard study, and the scale is what makes it different from the usual "startup left an S3 bucket open" story. This isn't one misconfigured company. It's a five-figure sample of apps built on the same open-source backend platform, and more than half of them are handing out real personal data to anyone who asks.
TL;DR
- UpGuard scanned ~300,000 domains for Supabase fingerprints and found 16,326 databases with publicly readable tables
- More than half showed indicators of personally identifiable information; a smaller share exposed passwords or auth tokens; a very small number had plausible credit card data
- Root cause: misconfigured Postgres row-level security (RLS), a protection that's off by default for any table created outside Supabase's dashboard editor - including tables AI coding tools create via SQL
- Named victims include a US valet service (78,000 license plates, 100,000 phone numbers), an immigration coaching service (884 plaintext passwords), and an African consulate exposing migrants' emergency housing locations
- Supabase's position: security is "shared responsibility" - the platform is secure by default in its own editor, but developers using the SQL editor or AI-created migrations can still ship with RLS off
How UpGuard Found 16,326 Open Databases
The methodology is more interesting than it sounds, because it's replicable by anyone with the same tools. UpGuard didn't scan Supabase's infrastructure directly - it fingerprinted the open web. Researchers pulled technographic data from BuiltWith and raw JavaScript files from the Chrome UX Report dataset on BigQuery, both of which reveal when a site's frontend is calling a Supabase project URL and public API key.
From there, the process was mechanical: for every domain flagged as a Supabase user, query the database for a table named "users" (or whatever the app's own client code was already calling), and see what comes back. UpGuard says it used an AI model to classify the schema of each returned table into a business category, rather than manually reading through personal records - a nod to the ethics problem of a study that could otherwise itself become a data-scraping incident.
Supabase's Table Editor interface, the same dashboard view UpGuard says renders row-level security on by default - unlike tables created through the SQL editor or AI-generated migrations.
Source: supabase.com
What Counted as "Exposed"
Not every one of the 16,326 databases is equally bad. UpGuard's own summary put it bluntly: "data leaks are the multiplicative product of a technology's ease of misconfiguration and the size of its user base." A table with a handful of test rows and one with 100,000 real customer records both count toward the headline number, which is why the report breaks severity into tiers rather than treating all 16,326 as equivalent disasters.
The Scoreboard
| Exposure category | Share of the 16,326 databases | What that means |
|---|---|---|
| Contains PII indicators (names, emails, addresses, phones) | More than 50% | The largest bucket - basic personal data, publicly queryable |
| Contains passwords or auth tokens | Smaller minority | Credential exposure, often plaintext |
| Contains plausible credit card data | Very small number | Rare, but present in a five-figure sample |
| Payment system indicators present | Common | Stripe/payment keys or references found, not inherently sensitive alone |
The pattern UpGuard describes lines up with what's already on this site: Lovable-built apps have hit this exact failure mode before, and a 2026 audit of AI coding tools found zero of five major tools shipped security headers or CSRF protection by default. This is the same root problem showing up at platform scale instead of tool-by-tool.
Worst Offenders
UpGuard names specific incidents, and they read less like abstract statistics and more like a list of people who had no idea their data was public:
A US valet parking service - 78,000 license plate records, 100,000 customer phone numbers, 43,000 names and emails, and a staff table with 665 employee records including 4,560 corporate domain email addresses and push-notification tokens.
An immigration coaching service in Canada - nearly 5,000 user records with full names, emails, phone numbers, and dates of birth. 884 of those records stored passwords in plain text.
An African consulate operating in France - 25,000 records containing personal information and physical addresses, including emergency housing locations for vulnerable migrant populations.
A Philippines-based virtual SIM farm - over 2,000 users exposed with 100,000+ SMS messages, including one-time passcodes used for account verification - infrastructure normally tied to bulk account-creation fraud.
An Indian adult streaming platform - private conversations between users and performers, fully readable.
A rack of backend infrastructure. UpGuard's scan targeted the databases behind consumer-facing apps, not Supabase's own servers - the exposure sits in how customers configured their projects.
Source: Wikimedia Commons
Where Supabase's Defaults Actually Stand
Supabase CISO Bil Harmer's response frames this as a shared-responsibility problem, and there's a real technical basis for that framing - it's just incomplete. Supabase's own 2025 security retrospective confirms that tables created through the dashboard's Table Editor get RLS turned on automatically, and the platform now emails project owners and flags a warning banner when it detects a table with RLS disabled.
That fix traces directly back to CVE-2025-48757, the vulnerability class that made Lovable a repeat offender last year. But per Supabase's own documentation, any table created via the SQL editor, a migration file, or - critically - the SQL an AI coding assistant generates and executes directly, still defaults to RLS off. Claude Code and OpenAI Codex were both cited as tools that created some of the exposed schemas in UpGuard's sample. The warning banner only helps if a developer is looking at the dashboard in the first place, and vibe-coded projects are built specifically so that developers don't have to.
What This Says About the Ecosystem
None of the individual failures here are novel. Misconfigured RLS has been Supabase's known weak point since the Lovable disclosure over a year ago, and "AI writes insecure backend code" is by now a well-documented pattern, not a surprise finding. What UpGuard adds is scale: this isn't five vibe-coded apps with bad defaults, it's a five-figure population sample where the majority-PII-exposure rate held steady across wildly different kinds of businesses, from a French consulate to a Philippine OTP farm.
That consistency is the actual warning. Supabase's own tooling improvements since the Lovable incident clearly reduced risk for anyone using the dashboard as intended - but they didn't touch the SQL-editor and AI-migration path, which is exactly the path vibe-coding platforms funnel developers through by design. Until RLS defaults to on regardless of how a table gets created, this number goes back up the next time someone runs the same scan.
Sources:
