Thousands of Vibe-Coded Apps Are Leaking Corporate Data — What No-Code Builders Must Learn

A cybersecurity firm just scanned the internet and found 380,000 vibe-coded apps sitting on the open web. Five thousand of them are spilling corporate data, API keys, and personal information to anyone who knows how to look.

The firm, Red Access, published its findings in WIRED this month. The numbers are grim: apps built with Lovable, Replit, Base44, and Netlify are publishing internal tools, customer databases, and medical records straight to the public internet. The researchers didn't need sophisticated exploits. They just looked.

This isn't a bug. It's a structural property of how vibe coding works. And it's the strongest argument yet for why structured no-code platforms aren't the boring option. They're the safe one.

TL;DR: Red Access found 5,000+ vibe-coded apps exposing sensitive data because AI-generated code ships with zero security defaults. No auth. Public databases. Hardcoded API keys. Structured no-code platforms (Bubble, Webflow, Stacker) bake auth and permissioning into the platform itself, which makes them the grown-up choice for anyone building tools people actually depend on.

What did Red Access actually find?

The headline number is 380,000 publicly accessible applications, with roughly 5,000 confirmed to be exposing sensitive information. And that 5,000 figure only counts apps hosted on the AI coding tools' own domains. The real number is almost certainly higher.

The exposed data includes customer records, internal pricing documents, medical information, and advertising strategies. In one case, a single app leaked enough that anyone with a browser could reconstruct a company's entire sales pipeline.

Separately, a North Korean state-sponsored group called HexagonalRodent used AI to vibe-code malware and phishing infrastructure, netting roughly $12 million in cryptocurrency over three months. The same tools that let a marketer spin up a dashboard in 30 seconds let a state actor spin up an attack vector in 30 seconds. Symmetrical capability. There's also the SaaS founder who built a product with Cursor, shipped it, and watched someone extract his OpenAI keys from the client-side JavaScript within days. $14,000 bill. Product dead. And Tom's Hardware reported a Claude-powered Cursor agent that deleted an entire company database in nine seconds, backups included.

Why are vibe-coded apps structurally more vulnerable?

The problem isn't that AI writes bad code. It's that AI writes incomplete code.

When you ask a vibe-coding tool to build a customer portal, it generates a working frontend, a database connection, and some API routes. What it does not generate, because you didn't ask it to and the tool doesn't know to suggest it, is authentication middleware. Row-level security. Rate limiting. Environment variable management that doesn't shove your secrets into a public bundle.

The VibeEval security team has been cataloguing these failure patterns all year. Their findings: more than 70% of apps built with Lovable ship without row-level security enabled on the underlying Supabase database. The default Supabase project settings allow anonymous reads and writes. The AI doesn't change those defaults. The builder doesn't know the defaults exist. The app goes live. Anyone with the URL has full database access.

This is the structural problem. Vibe-coding platforms hand you a fully functional application and expect you to know which invisible security settings you need to configure before it's safe. The platform says "you built an app!" The database says "anyone can read every row." The same pattern repeats with API keys: the AI hardcodes them into frontend JavaScript because that's the shortest path from prompt to working app. Builder sees it working, deploys, celebrates. Days later: a stranger's AWS bill.

This isn't user error in any meaningful sense. If the tool ships insecure defaults and the builder is a non-technical person who doesn't know what row-level security is, you've built a footgun with a hair trigger.

What makes a structured no-code platform different?

The no-code world figured this out years ago.

Bubble has built-in user authentication and a privacy rules engine that controls data visibility at the database level. You cannot accidentally expose a table to the public internet. You'd have to explicitly uncheck every privacy rule, one by one.

Webflow handles authentication through its Memberships system and separates the CMS from the rendered site by design. There's no raw database connection string to leak because there is no raw database connection string.

Stacker sits on top of whatever database or SaaS tools you already use (Airtable, Salesforce, Google Sheets) and enforces permissions through the platform layer. Users only see what you've explicitly granted them. You don't configure row-level security because the platform treats it as a first-class concept, not an opt-in setting buried in a Supabase dashboard.

This is the quiet, unsexy advantage of structured no-code. The platform owns the security boundary. Auth isn't a feature you bolt on after the demo works. It's baked into the architecture such that forgetting it isn't possible.

The Replit CEO, Amjad Masad, made a version of this argument himself when Apple blocked Replit's App Store updates. His pitch: Replit's full-stack architecture keeps the database private to the deployment, unlike tools that generate apps against a public Supabase or Firebase backend. He framed it as a security advantage. He's right. But the more honest headline is that some platforms have been doing this since before vibe coding had a name.

What should no-code builders actually do?

If you're building with a vibe-coding tool, the platform will not save you. You have to save yourself. Three things to check before anything goes live:

Where are your API keys? Open your browser dev tools, go to the Network tab, and check what's in the JavaScript bundles. If you see anything that looks like a key, rotate it immediately and move it server-side. Every vibe-coding tool has a way to do environment variables. Use them.

Is your database actually private? If you're on Supabase, open the dashboard right now and check the Authentication and RLS settings for every table. The default is "anyone can do anything." Change it. Firebase? Same default. Same problem.

Do you actually need to be on the public internet? Half the apps in the Red Access report were internal tools: team dashboards, sales trackers, inventory systems. They never needed a public URL. Put them behind authentication or, better, use a platform that handles access control for you.

If you're evaluating tools for something that handles real data, customer information, payments, anything you wouldn't want on Pastebin, start with the security question, not the "how fast can I build it" question. Structured no-code platforms cost more and involve more upfront configuration. That's the trade-off. It's worth it.

The takeaway

The Red Access research isn't a condemnation of vibe coding. It's a map of where the guardrails are missing.

Vibe-coding tools are getting more powerful every month. They'll ship more complete apps, with more convincing UIs, connected to more data sources. The attack surface grows in proportion. And the builders using these tools, most of whom aren't security engineers and shouldn't need to be, will keep shipping until the defaults change.

The no-code platforms that survived the last decade already solved this. Auth by default. Permissions as architecture. Security as a platform property rather than a box you tick before launch. As vibe coding matures, those platforms stop looking like the safe-but-dull alternative and start looking like the only serious option for anything that touches real data.

The era of "just deploy it and see what happens" needs to end. It probably won't. But if you're reading this, you now know what happens when it doesn't.