I scanned 1,049 AI-built apps. 71 got flagged for the same mistake. Here's how many were actually real.

Vibe coding has a security problem. That's not news anymore. Wiz found it in Moltbook back in February. Forbes wrote about it in March. The Verge covered it in June. Security researchers have been scanning Supabase-backed apps at scale for most of 2026, and the numbers keep landing in the same place: somewhere between 1 in 10 and 1 in 15 apps built fast with AI tools ship a database that anyone can read without logging in.

I wanted to see it for myself, at a scale I could actually stand behind, and then do the part most of these reports skip: tell every single company, before publishing a word.

The check

I'm not going to walk through the exact method. Publishing a step-by-step guide to finding open databases is not something I'm willing to do, and it's not the point of this piece anyway. What I can say: it's a known, well-documented misconfiguration class (Row Level Security left disabled on a database that ships a public API key to the browser), the same root cause behind Moltbook and every report linked above. I built a small, read-only checker for it. It never authenticates as a user, never modifies anything, and never reads an actual row of real data, it only confirms whether a table is reachable at all, using nothing more than a count returned in a response header.

I ran it against 1,049 AI-built apps, sourced from public launch platforms, hackathon showcases, and build-tool galleries. Nothing behind a login, nothing I wasn't allowed to look at as a visitor.

The number

The automated check flagged 71 of the 1,049 apps, about 6.8%, for the same technical pattern: Row Level Security disabled on at least one table. That is not the real number, and publishing it as-is would have been the easy, dishonest version of this piece.

Every one of those 71 got a manual review, by hand, app by app. 40 of them turned out to be intentionally public content once I actually looked: blog posts, public leaderboards, a dictionary's own entries, demo data for a tool. Same technical pattern, same "RLS disabled" flag, but nothing private behind it. Flagging those as leaks would have been dishonest, and would have wasted the time of 40 teams who did nothing wrong. Telling the difference between "this table shouldn't be readable" and "this table is a public leaderboard and that's fine" took more work than the automated scan itself.

That leaves 31 apps, about 3% of the total, with real, private data reachable by anyone, no login required. That is the number I stand behind, not the raw 71.

To be specific about what "reachable" means for those 31: not a hypothetical risk, not a theoretical misconfiguration. An unauthenticated request, with the same public key already sitting in the app's own JavaScript, returning the actual contents of the table. Account profiles. Private messages. Paid usage history. In one case, a full database master key exposed client-side, meaning read, write, and delete access to everything, not just one table.

What actually matters: what happened after

Every research report I read this year stops at the number. Here's what happened when I didn't.

I looked up a real contact for every one of the 31, individually, not a contact form blast. For most of them I found one and emailed the company directly, no mass disclosure post, no countdown timer, no "fix this or I go public." Just: here's exactly what's exposed, here's how I confirmed it without reading your actual data, here's what it means in practice for your specific app, and here's the fix. I offered to help implement it for free, no obligation either way. A handful I couldn't find a real contact for at all, no public email, no working contact form, nothing, and I'm not going to pretend that gap doesn't exist either.

That's not a compliance checkbox. It's the actual point. A vulnerability count without a disclosure process is just a scoreboard. The number 31 doesn't help anyone by itself, the emails might.

I'll publish an update on the response rate once there's enough of one to be meaningful. Not before. A handful of replies eleven hours after sending isn't a result, it's noise, and I'd rather wait and report something real than pad a follow-up post with a number that looks good today and means nothing.

What this means if you shipped something fast

If you used Bolt, Lovable, v0, Replit, or built directly on Supabase without thinking hard about access control: it takes ten minutes to check. Open your Supabase dashboard, go to each table, and confirm Row Level Security is enabled with a policy that scopes rows to the authenticated owner. If you don't know whether it is, that's the answer.

This isn't a criticism of AI coding tools. It's a gap between how fast they let you ship and how much security thinking gets skipped in that speed. That gap isn't going to close on its own, and the count of apps shipping with it open is not shrinking, it's what every researcher looking at this in 2026 keeps finding, independently, on different samples.

If you want a second pair of eyes on your own setup, or you got one of these emails and want a hand with the fix, reach out.

Abdellah
MergeFix, github.com/holistis