Was Supabase hacked? No — why 16,326 databases were exposed

Was Supabase hacked? No — there's no reported breach of Supabase's own platform. The "Supabase breach" headlines, most recently UpGuard's September 2026 count of 16,326 Supabase databases with publicly readable tables, are about apps built on Supabase leaking their own users' data. The cause is almost always a table with Row Level Security turned off, or a service_role key exposed to the browser, either of which turns Supabase's auto-generated API into an open door for anyone holding the public anon key. To see if your project is one of them, run the SQL check below: it lists every public table with RLS off. Here are the documented incidents, the single pattern behind them, and that 60-second check.

Has Supabase itself been hacked?

No. There's no publicly reported breach of Supabase's infrastructure, and none of the incidents below involved one. The closest thing on record is SupaPwn: in October 2025, researchers at Hacktron reported a privilege-escalation chain that could reach other database instances in the same region. Per Supabase, it only affected instances on a deprecated infrastructure version (0.000625% of database instances, by its CISO's count); the access path was closed the day after the report and the researchers were paid a bounty. That was a responsibly disclosed vulnerability, not a data breach anyone has reported.

When people search "Supabase breach" or "Supabase hacked," what they're actually finding are application-level exposures — projects where the developer never enabled RLS, so every row was readable (and often writable) through the documented REST API using the anon key that ships in every browser bundle.

That distinction matters, because it also means the fix is entirely in your hands. Supabase gives you the lock; these incidents are cases where it was left unlocked.

The documented incidents

CVE-2025-48757 — the Lovable exposure (May 2025). The flagship case. Security researcher Matt Palmer analyzed a large sample of apps generated by the AI builder Lovable and found 303 endpoints across 170 projects with Supabase tables readable by anyone sending the public anon key — exposing emails, addresses, and in some cases API keys — because RLS was never enabled on the generated tables. It was assigned CVE-2025-48757 (CVSS 9.3 on the CVE record), though Lovable disputes the framing, arguing the misconfiguration is the developer's responsibility rather than a platform flaw. Either way, the data was reachable. We broke down the mechanics in the Lovable RLS vulnerability, explained.

Exposure at scale. The Lovable finding wasn't isolated. Multiple security researchers have since demonstrated that thousands of Supabase-backed apps are queryable with nothing more than a curl command and the public anon key, dumping entire tables of user data. At least one open-source Supabase leak-scanner was built after its author caught a live database exposing roughly 13,000 users. The common thread every time: RLS off, or a service-role key that shipped to the client.

UpGuard's 16,326 open databases (September 2026). Far larger than earlier scans, and the story behind the latest round of headlines. UpGuard's researchers collected about 300,000 domains showing signs of Supabase, queried each one for a users table (where there was none, the database's reply named another table it could read), and found 16,326 databases exposing readable tables. Over half showed indicators of personal data; a smaller share held password or auth-token fields. Nobody broke into Supabase. UpGuard points at tables created programmatically through the API (the way coding agents create them), which don't get RLS switched on by default. It isn't a full census either: UpGuard says its method could be expanded to find more.

Supabase's own response. Supabase has treated this as a real problem rather than blaming users. Its 2025 security retrospective documents the push toward safer defaults, and since May 30, 2026, new projects no longer expose new public tables to the Data API automatically: each table needs an explicit GRANT before the API can see it. On October 30, 2026 the same rule reaches all existing projects, but only for tables created from then on. Existing tables keep their current grants and stay reachable, so a table that's exposed today stays exposed until you fix it. (What the change means for your queries: table not exposed to the Data API.)

The one pattern behind almost all of it

Strip away the app names and it's the same mistake every time:

• Every public table created under the old defaults is reachable through Supabase's auto-generated PostgREST API.
• That API accepts the anon key, which is public by design and lives in your client bundle.
• The only thing standing between an anonymous request and your rows is Row Level Security.
• RLS is still opt-in for tables created in SQL. Only tables made in the dashboard's Table Editor get it switched on by default (unless you've added Supabase's auto-enable event trigger), and AI code generators happily produce create table statements with no policy attached.

So the "breach" is usually one missing line per table. No exploit, no zero-day — just the documented API doing exactly what it was told, against a table nobody locked. (This is also why disabling RLS to "fix" a blocked query is so dangerous: it re-opens the exact hole.)

Check your own project in 60 seconds

Before you assume you're fine, confirm it. First, ask Postgres which public tables currently have RLS off (run in the SQL editor):

select tablename
from pg_tables
where schemaname = 'public'
  and not rowsecurity;

Anything that query returns is reachable by anon right now if the table still has the default Data API grants, which every table created under the old defaults has unless someone revoked them. If you didn't intend that table to be public, it's exposed. Then scan your migrations for the statement that turns the lock off:

grep -rniE 'disable[[:space:]]+row[[:space:]]+level[[:space:]]+security' supabase/migrations

And make sure no service_role key ever reached the browser — see how a leaked service-role key exposes everything and whether the anon key is safe to ship (it is; the service-role key is not).

The fix for an exposed table is never to leave it open: enable RLS and add a policy that grants exactly the access you intended. The complete guide to Supabase RLS walks through the policies, and every table needs RLS covers the "one I forgot" case that causes most of these.

Where GuardLayer fits

Almost every incident above is statically visible before it ships: a disable row level security in a migration, a table created with no policy, a service_role key behind a NEXT_PUBLIC_ variable. GuardLayer scans a Next.js + Supabase repo for exactly those on every push and flags them with the fix — so the "RLS off" table gets caught in review instead of by a stranger with curl. It's the same class of mistake that produced the AI-built app leaks; the point is to catch it in the diff.

FAQ

Has Supabase been hacked or breached? Not the platform itself — there's no publicly reported breach of Supabase's infrastructure (the 2025 SupaPwn bug was found by researchers, limited to deprecated infrastructure, and closed within a day). The incidents people call "Supabase breaches", including UpGuard's 2026 count of 16,326 databases with readable tables, are apps built on Supabase that left Row Level Security off, exposing their own users' data through the public anon key.

What was CVE-2025-48757? A May 2025 disclosure that 303 endpoints across 170 Lovable-generated apps had Supabase tables readable via the public anon key because RLS was never enabled. It carries a CVSS 9.3 on the CVE record; Lovable disputes attributing it to the platform rather than developer configuration.

Is my Supabase app exposed? Run select tablename from pg_tables where schemaname = 'public' and not rowsecurity; — anything returned is reachable by the anon key as long as it still has the default Data API grants. If you didn't intend that table to be public, enable RLS and add a policy immediately.

Does enabling RLS fix it? Yes — enable RLS and add a policy granting the access you actually need (usually using ( (select auth.uid()) = user_id )). Never "fix" a blocked query by disabling RLS; that re-opens the table to everyone.

Are newer Supabase projects safer by default? Somewhat. Since May 30, 2026, new projects don't expose new public tables to the Data API until you grant access, and from October 30, 2026 the same applies to new tables in existing projects. Existing tables keep their grants, so anything exposed today stays exposed, and any table you grant to the API still needs RLS checked by hand.