Tools / News / UpGuard Finds 16,326 Supabase Databases With Tables Readable by Anyone
Press

UpGuard Finds 16,326 Supabase Databases With Tables Readable by Anyone

· VaultTools

UpGuard analyzed roughly 300,000 domains using Supabase and identified 16,326 databases exposing readable tables, more than half with signs of personal data. TechCrunch reported the research on September 25, 2026. The cause is missing row-level security, often in apps built with AI coding agents.

VaultTools · October 2, 2026

A computer screen filled with source code, the kind of generated application code that can ship with a database left readable by anyone. Photo on Unsplash

Table of Contents

What Happened

Security firm UpGuard studied web apps built on Supabase, a hosted database service popular with small teams and AI-generated apps, and found thousands of them leaking user data to the open web. According to BleepingComputer, the researchers analyzed roughly 300,000 domains for signs of Supabase usage. UpGuard’s write-up states the result plainly: “Across the candidate set we identified 16,326 databases exposing readable tables.”

TechCrunch, which reported on the research on September 25, 2026, described about 16,000 databases with some degree of personal data exposure. No one broke in. The tables answered ordinary web requests, because nothing told the database to refuse them.

What Was Exposed

“Over half of the databases had indicators of some PII,” UpGuard wrote, with a smaller share containing passwords or authentication tokens and a very small number holding what looked like credit card data. The individual cases show what that means in practice:

  • An adult streaming platform in India: 65,467 user records, with fields for driver’s license and passport details according to UpGuard, plus more than 100,000 private messages.
  • A US valet parking service: more than 100,000 customer records with contact details, license plates, and visit history.
  • A consulate operated by an African national government: about 25,000 user records with personal details and addresses, including emergency housing locations.
  • A Canadian immigration service: nearly 5,000 user records, 884 of them with plaintext passwords.
  • An OTP service based in the Philippines: data on more than 2,000 users and 100,000 SMS messages, including one-time passcodes.

The businesses have nothing in common except the stack. As UpGuard put it, “The security settings are invariant to business type because the humans, who know what kind of business they are advertising, do not understand their database’s configuration.”

How It Happened

Supabase lets a web app talk to its database directly from the browser, using a public key embedded in the page. What keeps one user from reading everyone else’s rows is a set of row-level security (RLS) policies. If those are missing, the public key is enough to read the table.

UpGuard pinpoints where the gap opens: “Supabase has made product changes to implement RLS by default for tables created in the Table Editor UI. Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default.” BleepingComputer listed the root causes as missing or ineffective row-level security policies, misuse of public keys, and poor application security configurations.

The AI angle needs care. BleepingComputer noted that more than 60% of newly created Supabase databases are attributed to AI-assisted development, and also that the researchers stressed their scans “do not establish that every affected site was built using an AI coding agent.” UpGuard’s broader point is about incentives. It argues that “data leaks are the multiplicative product of a technology’s ease of misconfiguration and the size of its user base.”

Supabase told TechCrunch that projects are secure by default and that security is a shared responsibility with customers. Its CISO, Bil Harmer, said: “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.”

The Disclosure Timeline

  • March 2025: developer Matt Turner reports widespread misconfiguration in Supabase databases created by the vibe-coding platform Lovable, according to UpGuard.
  • September 25, 2026: TechCrunch reports on UpGuard’s findings.
  • September 28, 2026: BleepingComputer details the methodology and the individual cases.
  • October 1, 2026: date shown on UpGuard’s full write-up.

UpGuard says it notified the application owners “in the cases where we determined a significant exposure.” It does not say when, or how many of the 16,326 databases have been locked down since.

Why This Matters for Browser-Based File Tools

This research is about database tables, not uploaded files. UpGuard’s report does not describe exposed documents or storage buckets, and it would be wrong to claim otherwise. The relevance is one step back: these are small web apps, quickly built, where users entered personal data and trusted a backend they could not inspect. A visitor has no way to tell whether the site in front of them is one of the 16,326.

That is the same position anyone is in when they upload a passport scan or a contract to an unfamiliar online converter. The file lands in someone’s storage, governed by settings the user will never see, written by a developer (or a coding agent) who may not understand them either.

Processing a file entirely in the browser removes that dependency. When a PDF is merged or an image is compressed locally via WebAssembly, there is no upload, no row in a table, and no access policy that someone has to get right. A tool that never receives the data cannot expose it through a misconfigured backend.

Sources

← Back to all news