Sixteen thousand open doors, found by one audit
Security firm UpGuard scanned for publicly exposed Supabase-hosted databases and found roughly 16,000 of them reachable without authentication, exposing names, addresses, phone numbers, and passwords. TechCrunch's Zack Whittaker first reported the findings on September 25, 2026. The scale is the headline. Sixteen thousand exposed databases describe a systemic pattern across a popular hosting platform, far beyond a handful of careless side projects, and the figure was surfaced by one third party audit using straightforward, publicly available scanning techniques rather than any privileged access to Supabase's own systems.
The exposure is a configuration issue on the application side, not a reported flaw in Supabase's core infrastructure. Supabase provides the database, the authentication layer, and the access control primitives. What this audit found is that a large number of the applications built on top of those primitives left them wide open, whether through default settings left unchanged, access rules never configured, or security steps skipped entirely during a fast build.
The vibe-coding connection
The reporting on this exposure ties it specifically to vibe-coded apps, the now-common practice of using AI coding assistants to generate a working application, including its backend, from natural language prompts with minimal manual review of the resulting code or configuration. Supabase has marketed itself heavily to exactly this audience: developers and non-developers alike who want a production-ready Postgres backend without standing up infrastructure themselves, now increasingly orchestrated by an AI agent rather than typed by hand.
That accessibility is the product's core value, and it is also the mechanism behind this exposure. An experienced backend engineer configuring a Supabase project by hand is reasonably likely to notice an access control setting left wide open. An AI agent generating an application end to end, optimizing for a working demo rather than a secure default, has no equivalent instinct to flag it, and the human reviewing the output often lacks the security background to catch it either.
This is not a new mistake, just a faster one
Publicly exposed backend databases are not a new category of security failure. Misconfigured Firebase projects produced strikingly similar headlines for years, exposing comparable categories of personal data through the same root cause: a backend-as-a-service platform that made it trivially easy to build an app, paired with access control defaults that required a deliberate, informed step to lock down. The lesson from that era was supposed to be that platforms and developers would get better at defaulting to secure configurations.
What has changed is the speed at which new, unreviewed backends get created. When a human developer had to manually wire up a database and its access rules, the population of potentially misconfigured projects grew at the pace of human development cycles. When an AI agent can generate the same backend from a prompt in minutes, that population grows at the pace of however many people are willing to type a sentence into a chat window, which is an entirely different order of scale.
Why this lands harder on Supabase specifically
Supabase's own disclosed growth numbers make this exposure more than a one-time embarrassment. The company has said it adds more than 4 million databases a month, and that roughly 70 percent of new databases are now created by agents or AI-driven tools rather than by a developer directly. If a meaningful fraction of that agent-driven creation carries the same configuration risk UpGuard found in its sample, the 16,000 exposed databases identified in this audit are a snapshot, not a ceiling.
That does not make Supabase uniquely culpable. Any backend-as-a-service platform riding the same AI coding wave faces an equivalent exposure curve, and Supabase deserves some credit simply for being popular enough, and transparent enough about its own usage data, to be the platform where this pattern became visible first. The structural risk is in the combination of easy backend provisioning and AI-generated configuration, not in any single vendor's product choices.
What responsibility actually falls where
There is a real debate buried in this story about where responsibility should sit. Platform vendors can and arguably should push harder toward secure-by-default configurations that require an explicit, informed opt-out rather than an explicit opt-in to basic access controls. AI coding tool vendors have a parallel responsibility to flag, not just generate, security-relevant configuration choices when they scaffold a backend on a user's behalf, since the whole appeal of the category is that the person prompting it may never read the code those tools produce.
Neither of those fixes arrives fast enough to help the people whose names, addresses, phone numbers, and passwords are sitting in one of those 16,000 databases today. For enterprise buyers, the practical takeaway is narrower and more immediate: if any team inside your organization has used an AI coding assistant to stand up a Supabase-backed, Firebase-backed, or similar backend-as-a-service application, even for an internal tool, that configuration needs a security review now, not after the next audit cycle surfaces it.
Putting this on the roadmap
For CTOs and CIOs at PE-backed SaaS and retail businesses, the actionable response is to add backend-as-a-service configuration review to whatever governance process already covers AI coding tool adoption. If your organization has encouraged or tolerated AI-assisted development for internal tools, prototypes, or customer-facing features, inventory which of those projects touch a hosted database platform and verify, explicitly, that access controls were configured rather than assumed, treating every AI-generated backend as unreviewed until someone with security judgment actually looks at it.
The broader implication for the data organization is that the attack surface created by AI-assisted development is growing faster than most security review processes were designed to absorb. A review cadence built for human-paced development, where a handful of new backends go live per quarter, will not catch a vibe-coded app shipped on a Tuesday afternoon and forgotten by Friday. That gap, more than any single exposed database, is the real story in this audit.
.png)
