What Upguard found
Cybersecurity firm Upguard scanned the public internet and turned up roughly 16,000 Supabase hosted databases sitting open with no authentication in front of them, according to reporting picked up in Privacy Guides' September 25 to October 1 breach roundup, which cites TechCrunch's original coverage. The data inside ranged from names and addresses to phone numbers and, in a meaningful share of cases, plaintext or weakly hashed passwords. Supabase is a managed Postgres platform that has become the default backend for a wave of AI assisted app builders, and the roundup describes it plainly as a hosting platform popular with what the industry now calls vibe coded apps.
Sixteen thousand is not a rounding error. It is a signal that an entire category of software is shipping with its data layer facing the public internet by default, and that nobody along the chain, not the AI tool, not the developer, not the platform, caught it before launch. For a reader who runs engineering at scale, the number matters less than the mechanism behind it, because that mechanism is sitting inside your organization's shadow IT right now, built by a product manager or a contractor who had a working demo by lunchtime.
Why vibe coded backends fail this specific way
Supabase's core pitch is direct client side access to a real Postgres database, which is exactly what makes it fast to build on and exactly what makes it dangerous to build on carelessly. Traditional web apps put an application server between the browser and the database, and every query passes through code a human wrote and, ideally, reviewed. Supabase lets the frontend talk to Postgres directly through its API, which only stays safe if row level security policies are written and enabled for every table that holds anything sensitive.
AI coding assistants are very good at generating a schema, an API layer and a working UI in minutes. They are inconsistent about generating row level security policies, and even when they do, a developer moving fast will often disable them to stop getting permission errors while testing, then ship without turning them back on. The result is a database that behaves exactly as designed, open by default until someone locks it down, except nobody did the locking down.
This is bigger than one platform
Supabase is the name in this report, but the pattern is not specific to Supabase. Every backend as a service platform that trades an application layer for developer speed carries the same structural risk, and the AI app builder wave is pointed squarely at all of them. Firebase went through its own version of this problem years ago with open Realtime Database instances, and the lesson did not fully transfer because the underlying incentive never changed: tools that get you to a working product fastest will keep winning developer attention, and security configuration will keep losing the race against that speed.
What is different this time is scale and intent. A developer hand rolling a Firebase backend in 2018 was still a developer. Today's vibe coded app can be built by someone with no backend experience at all, prompted into existence over a weekend, and pointed at real users before any technical reviewer has seen the schema. That compresses the window between idea and production exposure to roughly zero, and it means the population of people capable of standing up a leaky database just expanded by an order of magnitude.
The governance gap this exposes
Most enterprises have a vendor review process for any SaaS tool that touches customer data, and most of those processes assume someone files a request before the tool goes live. Vibe coded prototypes skip that step by design. They start as an internal demo, a marketing microsite, or a side project that a business unit spins up without IT in the room, and they accumulate real user data long before anyone asks whether the backend was ever hardened. By the time security or procurement notices the tool exists, it may already be indexed, scraped, or sitting in a database with a public endpoint.
This is a governance problem before it is a technology problem. The fix is not telling teams to stop using fast app builders, because that fight is already lost and the productivity case for these tools is real. The fix is extending whatever inventory and review process already governs third party SaaS to catch AI generated backends the moment they start holding anything resembling customer data, rather than waiting for a researcher like Upguard to find them first.
What to do about it now
Start with discovery. Most organizations cannot currently answer the question of how many Supabase, Firebase, or similar backend as a service projects exist inside the company, and that blind spot is the actual vulnerability, not any single misconfigured table. A basic inventory pass across engineering, marketing, growth, and any team with access to a coding assistant will surface more of these projects than anyone expects, and it tends to surface them faster than a formal security audit would, because the people who built them usually remember building them.
Then set a default posture rather than relying on individual developers to remember a setting under deadline pressure. Row level security on by default, a pre production checklist that explicitly checks for open database endpoints, and a standing rule that no AI generated prototype touches real customer data until a human with security context has looked at the schema. None of this is expensive to implement. All of it is currently optional at most companies, which is exactly how 16,000 databases ended up exposed at once without a single novel exploit involved.
The roadmap implication
Every CTO pushing AI coding tools into their organization this year is making an implicit bet that speed gains outweigh the new failure modes those tools introduce. That bet can still be right, but only if governance scales alongside adoption instead of trailing it by months, and the Supabase numbers are a preview of what happens when governance loses that race. Sixteen thousand exposed databases did not require a sophisticated attacker, just an open endpoint and enough time for someone to go looking for one.
The practical move is to fold backend as a service and AI app builder usage into the same risk framework that already covers shadow SaaS, with an explicit owner and a recurring scan rather than a one time audit before launch. Treat the next vibe coded prototype that reaches production the same way you would treat a new vendor touching customer data, because structurally, that is exactly what it is, and your existing vendor risk playbook already knows how to handle that case if you point it at the right targets.
