Supabase Data Exposure: 16,326 Databases Left Readable

No zero day. No stolen admin password. UpGuard's researchers took the database address and public key that thousands of websites already publish in their JavaScript, asked each database for a table called "users", and 16,326 of them handed back data.

Key Takeaways

• UpGuard identified 16,326 Supabase databases exposing readable tables out of about 300,000 domains with signs of Supabase usage, according to research published September 25, 2026.
• Over half of those databases showed indicators of personal information, and a smaller share held passwords or authentication tokens.
• A Canadian immigration coaching service stored 884 passwords in plain text, and a US valet service exposed more than 100,000 customer phone numbers and about 78,000 license plates.
• Supabase enables Row Level Security by default for tables made in its dashboard, but UpGuard notes that tables created programmatically through the API, the route AI coding agents use, do not get it by default.
• Supabase CISO Bil Harmer told TechCrunch that projects are "secure by default" and called security a shared responsibility between Supabase and its customers.

What Did UpGuard Find in Exposed Supabase Databases?

UpGuard found 16,326 Supabase hosted Postgres databases that anyone on the internet could read, and more than half of them contained signs of personal data. Greg Pollock, UpGuard's Director of Research and Insights, calls it "the largest study of its kind." A smaller percentage included passwords or authentication tokens, and a very small number held plausible credit card data.

Put the headline number in proportion: 16,326 out of roughly 300,000 candidate domains is about one Supabase site in 18. To confirm the schemas pointed at real data, UpGuard examined a handful of databases in depth and notified the owners where it found a significant exposure:

• An Indian adult content platform: 65,467 users with names, emails, dates of birth, driver's license and passport details, PAN card numbers and the last 4 digits of Aadhar numbers, plus payout accounts and a messages table holding over 100,000 private messages to and from creators.
• A Philippines OTP service tied to a SIM farm: over 2,000 users and over 100,000 SMS messages. About 95% were one time passcodes, but 2,000 to 2,400 were real texts between rideshare drivers and passengers who had nothing to do with the operation.
• A US Northeast valet service: over 100,000 customers with phone numbers, about 43,000 with full names and emails, about 78,000 with license plates, plus tip history, free text notes and 665 staff records with push tokens.
• An African government consulate: 25,000 people with physical addresses and a field recording which emergency housing location each person currently lives in. TechCrunch reports the consulate operates in France.
• A Canadian immigration and relocation coach: nearly 5,000 records with names, emails, phone numbers and birth dates, 884 of them with a plain text password.

How Did UpGuard Find 16,326 Exposed Databases?

UpGuard fingerprinted Supabase sites by searching public JavaScript files for Supabase key names and database addresses, then queried each database for a "users" table. The raw material came from BuiltWith's technology fingerprints and Google's Chrome UX Report dataset on BigQuery, which together yielded about 300,000 unique domains.

This works because of how Supabase is designed. Every project gets a PostgREST API at https://<project_ref>.supabase.co/rest/v1/ that, per Supabase's own docs, is "automatically reflected from your database's schema." Browser code talks to it directly with a public key. Each query returned one of three outcomes: nothing (the security policy blocked it or the project was dead), no "users" table but a hint naming a table that was readable, or a page of actual rows.

That hint behavior matters. A developer who named the table customers instead of users gained nothing from obscurity, because the API pointed the researchers to it. UpGuard's own write up says the techniques "could likely be re-run or expanded to find even more," so treat 16,326 as a floor. Earlier, smaller scans found the same pattern: Modern Pentest reported 28% of 107 Y Combinator startups exposing PII, and Escape counted 175 leaking databases across about 1,400 vibe coded apps.

Why Does Missing Row Level Security Expose Everything?

Without Row Level Security, any role holding a grant on a table can read it, and Supabase's anonymous role starts with broad grants. The Supabase RLS guide puts it bluntly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." On existing projects, a new table in public starts with select, insert, update and delete granted to anon, authenticated and service_role.

The public key is not the bug. Supabase's API key docs describe the publishable key as "taped to the front door, and it only opens the lobby." RLS is what builds the lobby walls. Skip it and the lobby is the whole building, with the guest list, the passports and the private messages on display.

Here is where AI coding comes in. Supabase says in its 2025 security retro that RLS is enabled by default for tables created via the dashboard. UpGuard points out the gap: "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default." UpGuard also describes Supabase as the database product most recommended by Claude Code, a position that helped carry the company to a $10 billion valuation in June 2026.

Is Security Really a Shared Responsibility?

Supabase says yes. CISO Bil Harmer told TechCrunch the company had not seen the research, that projects are "secure by default," and that "We provide secure defaults and tooling, and customers control how their own projects are configured." He added: "Security at Supabase is never finished. We care deeply about getting it right, and we'll keep making it easier for every developer to ship securely."

This argument has a paper trail. When the same misconfiguration pattern was reported in apps built on Lovable in March 2025, it was assigned CVE-2025-48757, which carries a 9.3 Critical CVSS score in its NVD entry. The CVE record carries a dispute note from the supplier: "each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." Eighteen months later the platform has changed and the defense has not.

Most coverage stops at "developers misconfigured their databases." The more uncomfortable reading is that shared responsibility assumes a customer who reads the configuration. UpGuard found that exposure rates were the same whether a site sold to businesses or consumers, because "the humans, who know what kind of business they are advertising, do not understand their database's configuration." When an agent writes the migration and the human only reads the landing page, the customer half of the shared model is empty. The secure default protects the dashboard, which is the one path an agent never takes.

UpGuard compares Supabase to Amazon S3 and GitHub, two platforms whose convenient defaults produced years of leaks before they rebalanced. Gblock covered the long tail of that history when researchers found 9,300 leaked AWS keys that still worked, 88 percent of them still live years after exposure.

How Do You Check Your Own Supabase Project?

Run Supabase's Security Advisor, enable RLS on every table in an exposed schema, and revoke the default grants you don't need. The database advisors docs list every check. In order:

• Run the advisor. Use Security Advisor in Studio, supabase db advisors in the CLI, or get_advisors with type security over MCP. Treat lints 0013 (rls disabled in public), 0007 (policy exists rls disabled), 0008 (rls enabled no policy), 0023 (sensitive columns exposed) and 0024 (permissive rls policy) as blockers.
• Enable RLS and revoke grants. Run alter table public.your_table enable row level security; then revoke all on table public.your_table from anon, authenticated; and grant back only what each role needs. Supabase warns: "Adding policies doesn't remove them."
• Catch tables your agent creates. Supabase supports Postgres event triggers to enable RLS automatically on every new table, which covers migrations and agent generated SQL that skip the dashboard.
• Probe it like an outsider. Send a request to your /rest/v1/ endpoint with only the publishable key on the apikey header. If rows come back for a table signed out visitors shouldn't see, so will they for anyone else.
• Keep secret keys on the server. The service_role and sb_secret_ keys bypass RLS entirely. Supabase is deprecating the legacy anon and service_role keys by the end of 2026, but the new publishable key still resolves to the same anon role, so migrating keys alone fixes nothing.
• Read the alerts. Supabase emails project owners when a table is created with RLS disabled and sends organization owners weekly security summaries. Those emails only help if someone opens them.

What This Means for Your Inbox

If your data sat in one of these databases, the likeliest follow on is a targeted email or text that knows your name, your phone number and the business you used. The FTC warns that scammers use email and text messages to steal passwords, and that with them "they could get access to your email, bank, or other accounts."

The valet data shows how a small leak spreads. About 11% of its exposed email addresses, 4,560 of them, belonged to third party corporate domains, including universities and Fortune 500 companies. A consumer app leak became a list of employees at regional employers, which is exactly the raw material for convincing work email lures. We tracked how quickly those lures are improving in our look at AI written phishing emails.

Plain text passwords raise the stakes further. More than one in six records at the Canadian immigration service had one, and people reuse passwords on email. If you used a small, recently launched app with an account, change any password you shared with it, turn on multifactor authentication for your email, and treat unexpected messages that cite a recent booking or application as suspect. Forward scam texts to 7726 (SPAM), as the FTC recommends.

Looking Ahead

UpGuard found exposures all over the world, with Europe's data protection rules producing better practices and developing regions leaking more, while TechCrunch notes most of the exposed datasets appear to sit in the United States. It is the same pattern Gblock has seen in open storage stories from S3 buckets to the ClarityCheck face photo leak: the fix is a setting, and the setting stays off until the defaults change.

Two things are worth watching. First, whether Supabase extends RLS by default to tables created through the API, the path agents actually use. Second, whether AI coding tools start running the security advisor before they tell a user the app is done. Until then, if you shipped a Supabase app this year, the most useful thing you can do tonight is run supabase db advisors and read every warning.