16,000 Apps Built With AI Left Your Personal Data Wide Open

The Tool That Built Your App May Have Left the Front Door Unlocked

If you used an AI assistant to build your app, there is a real chance your users' data is sitting on the open internet right now. Not because you made a careless mistake. Because the tool that wrote your code quietly skipped a single security setting, and nobody told you.

That is not a hypothetical. It happened at scale, and researchers found the proof.

How Does This Happen?

Supabase is a popular backend platform. It gives you a database, user authentication, and a simple API, all in one place. Tens of thousands of founders and solo builders use it to launch products fast.

The platform ships with a feature called Row Level Security, or RLS. When you turn it on, your database tables are locked down by default. Users can only see data that belongs to them. Nobody else can read your tables, even if they know the URL.

When you turn it off, or when you never turn it on at all, every table in your database becomes publicly readable. Anyone with an internet connection and the right API URL can query it.

AI coding tools, the kind used in "vibe coding" workflows where you describe what you want and the AI writes the code, generate Supabase integrations automatically. They connect the database, write the queries, wire up the API calls. What they routinely skip is enabling RLS. The feature that keeps your users safe never gets switched on, and the AI does not warn you.

What Did Researchers Actually Find?

Security research firm UpGuard disclosed its findings on September 25 and 26, 2026. The numbers are not small.

• 16,326 Supabase databases were publicly readable on the open internet
• Over half of them exposed personal information: names, email addresses, phone numbers, and home addresses
• A smaller number exposed plaintext passwords, authentication tokens, and in some cases credit card numbers

Those are not abstract data points. UpGuard confirmed real examples.

A U.S. valet service had more than 100,000 customers' license-plate records sitting in an open database. A Canadian immigration firm had 884 plaintext passwords fully visible to anyone who looked. An Indian adult streaming platform had private user messages exposed.

Every one of those users trusted a builder with their information. The builder trusted an AI assistant to handle the details. The AI missed the one setting that mattered most.

Supabase told TechCrunch that its platform is "secure by default." That is technically accurate. The exposures come from how apps are configured on top of Supabase, not from any flaw in Supabase itself. The responsibility lands on the builder.

Who Should Be Worried?

If you built something with Supabase and used an AI tool to help write the backend code, you need to check your configuration today. Not next week.

This is not limited to a specific tool or a specific framework. Any AI-assisted workflow that generates Supabase code can produce this misconfiguration. The AI is optimizing for getting your app to work. Security configuration is a separate step that requires deliberate human intent, and most builders never realize it was skipped.

What Do You Do Right Now?

If you are a builder:

1. Log into your Supabase project and open the Authentication settings
2. Check every table in your database under the Table Editor. Look for the RLS indicator. If it shows as disabled, your table is open to the public
3. Enable RLS on every table that contains user data, personal information, or anything sensitive
4. Add policies that explicitly grant access only to the right users. Supabase has templates for common patterns, "users can only read their own rows" is a one-click policy
5. Test it. Create a test account, query your tables from outside your app, and confirm that a logged-out request returns nothing
6. If you are unsure whether your app has ever been exposed, check your Supabase logs for unusual read patterns

If you are a user of an app built on Supabase (or really any web app):

• If you receive a data breach notification, take it seriously and change your password on every service where you reused that same password
• Enable two-factor authentication on any account that holds sensitive information
• Use a password manager to generate unique passwords for every site. Reuse is how a single breach becomes ten breaches
• Consider a credit freeze with the major bureaus if financial information was involved. It is free and it is the single most effective thing you can do to block identity theft
• Services like data-removal tools can help reduce your exposure across data broker sites, though none are perfect

The Deeper Problem With Letting AI Drive

Here is what this breach pattern reveals about the current moment in software development. AI tools are extraordinarily good at making things work. They are not yet reliable at making things safe. Those are two different problems, and conflating them costs real people real harm.

The builders who shipped these exposed apps were not reckless. Most of them probably believed their tool had handled the security setup. The AI produced functional code. The app launched. Users signed up. Everything looked fine.

"It works" and "it is secure" are not the same thing. They never have been. The difference is that an AI assistant has no incentive structure that rewards finding that out.

Vibe coding is not going away. Neither is Supabase. The expectation that AI-generated code handles security by default needs to change, both in the tools themselves and in how builders review what the tools produce.

Until that changes, the responsibility sits with you.

Do this now:

• Open your Supabase dashboard and check every table for RLS status
• Enable RLS and add access policies before your next deploy
• If you use any AI coding tool, treat security configuration as a manual review step, every time
• If you are a user, freeze your credit and enable 2FA on accounts that matter

Sources

• bleepingcomputer.com
• cybernews.com