We review and update this article regularly as new information becomes available.
TL;DR: Security firm UpGuard scanned the open web and found roughly 16,000 Supabase-hosted databases with tables anyone could read, no login required. The exposed data ranges from names and phone numbers to private messages from an adult streaming site and thousands of valet-parked license plates. Supabase says its defaults are secure and that security is a shared job. The scale of what UpGuard found suggests a lot of customers never got that memo.
If you have spent any time building with Supabase, Firebase, or any backend-as-a-service tool over the last two years, you already know how fast a weekend project can go from empty repo to live database. That speed is the entire pitch. It is also, according to a new report from security firm UpGuard, exactly how a huge number of these projects end up leaking real people’s information to anyone who bothers to look.
UpGuard’s researchers scanned publicly reachable Supabase instances and found around 16,000 databases with tables that were readable without any authentication at all. Not misconfigured in some subtle way. Just open. The contents varied wildly in sensitivity, which is almost worse than if it had all been the same kind of low-stakes data. Researchers found names, home addresses, phone numbers, and in some cases plaintext passwords sitting in plain view.
Some of the specific examples are the kind of thing that makes a privacy story land differently than a dry statistic. One exposed database held private conversations pulled from an adult streaming platform. Another contained thousands of license plate numbers from a valet parking service in the United States. A third belonged to an African government’s consulate operating in France, and researchers said one exposed setup appeared to have been used to intercept text messages as part of a SIM farming scheme. Most of the affected projects trace back to the US, but UpGuard was clear that this is not a regional problem. It is a pattern showing up everywhere backend-as-a-service tools get adopted quickly.
Supabase’s chief information security officer, Bil Harmer, pushed back on the idea that this points to a flaw in the platform itself.
“Security at Supabase is never finished. We care deeply about getting it right,” said Bil Harmer, Supabase’s CISO, adding that projects ship “secure by default” and that protecting data is a shared responsibility between the platform and whoever configures it.
That framing is not wrong, exactly. Supabase does ship row-level security controls that, when turned on, lock down exactly this kind of exposure. The problem is that turning them on is a step, and steps get skipped, especially by developers who are moving fast, often with AI coding tools generating large chunks of the backend logic for them. This is not the first time UpGuard has flagged that combination. Earlier research from the firm already pointed to security gaps specifically in AI-generated apps built on Supabase, and this latest scan reads like a much bigger version of the same story.
None of this requires malicious intent from Supabase or from the developers who built these apps. It mostly requires a checkbox nobody remembered to check, multiplied across thousands of projects. Supabase says it notifies customers when it discovers exposed data, which is the right move but also a reactive one. By the time a company like UpGuard is scanning the open internet and finding your consulate’s contact database, the damage calculus has already changed.
For anyone running a Supabase project right now, the actionable takeaway is boring but important. Row-level security is not optional if a table holds anything close to personal data, and “it worked in testing” is not the same thing as “it is safe in production.” That is not a knock on Supabase specifically. It is true of every fast backend platform that lets a solo developer stand up a database before lunch.
Bottom Line: Sixteen thousand exposed databases is not a story about one bad actor or one bug. It is a story about how much trust gets extended to default settings when speed is the whole point of the product. Supabase is right that security is shared. The uncomfortable part is how many people did not realize they had a share to hold up.
