The scan that turned the anecdotes into a number

Vibe Graveyard already has a thick shelf of vibe-coding incident stories: Lovable's BOLA flaw left exposed for 48 days, Base44's authentication bypass on every app built with the SDK, Replit's AI agent wiping a production database, Tea's dating-app breach, Lovable's showcased edtech app exposing 18,000 university users. Until early May 2026, the public picture was a stack of these individual reports. RedAccess's May 7 study is the first systematic measurement of the underlying pattern.

The Israeli security firm scanned roughly 380,000 applications built on the major vibe-coding platforms: Lovable, Base44, Replit, and Netlify. About 5,000 of those apps were leaking sensitive corporate or personal data at the moment the scan caught them. Of the apps with detected security weaknesses, roughly 40% exposed things RedAccess could identify as sensitive: medical information, financial data, corporate presentations, strategy documents, and detailed logs of customer conversations with chatbots.

That ratio - five thousand leaks out of three hundred eighty thousand apps - sounds small until you realize the denominator is a lower bound on the actual platform population, the numerator is what one researcher could find from outside the platforms, and the sensitivity bar is high enough that the count excludes apps that merely had weak controls without exposing identifiable data.

What was actually leaking

The verified exposures published with the report cover a surprising spread of industries.

• A shipping company's app contained information on vessels scheduled to enter port. That kind of operational data has obvious uses for cargo theft, customs fraud, and physical-security planning.
• A healthcare company's internal app exposed the status of clinical trials underway across Britain. Trial data is among the more aggressively protected categories of corporate information for both competitive and regulatory reasons.
• A British furniture retailer's customer-service chat transcripts were accessible from the open web. The transcripts included order details and personal conversations between named customers and the company.
• A Brazilian bank had internal financial information exposed in an app that was supposed to be employee-only.

Beyond the data leaks, RedAccess also documented phishing infrastructure quietly running on Lovable: pages built to look like Bank of America, FedEx, Trader Joe's, and McDonald's. Those pages did not need to bypass any platform-level guardrails. They were just sites a user could spin up like any other Lovable project. The phishing finding sits in a different category than the data exposures, but both rely on the same underlying property of the platforms: anyone can publish anything quickly, and nothing in the workflow forces a separate review step before the project is reachable on the public internet.

Why this is happening

RedAccess pinned the root cause on a default-permissions pattern. Several of the major vibe-coding platforms make new projects publicly accessible unless the builder explicitly changes the privacy setting to private. That is a defensible default for a personal portfolio site or a quick demo. It is a hostile default for the apps non-developer builders actually create on these platforms, which routinely include internal HR tools, customer-facing chatbots, knowledge bases, and lightweight CRMs.

The mismatch produces a familiar failure mode. A non-technical user describes the app they want, accepts whatever the AI builds, looks at the demo, sees it working, and moves on to the next task. The setting that controls whether the project is reachable by a stranger with a URL never comes up in that workflow. Many apps are also indexed by Google and other search engines as soon as they go live, which means stumbling onto a private-by-intent vibe-coded app does not require any reconnaissance skill. A normal search query is enough.

This is the structural complaint Wiz made when it disclosed the Base44 vulnerability in 2025: vibe-coding platforms collapse the trust model. The builder cannot inspect the auth implementation, the storage configuration, the access controls, or the routing rules. They have to trust the platform to handle those correctly. When the platform gets any of them wrong by default, every app built on the platform inherits the failure.

RedAccess's numbers indicate that the structural complaint is not theoretical. Across roughly 380,000 apps from multiple platforms, the default-public pattern alone produced five thousand confirmed data leaks. That is before counting platform-side vulnerabilities like the Lovable BOLA issue or the Base44 SDK auth bypass, both of which would multiply the actual exposure surface beyond what a passive scan can see.

Where the responsibility sits

There is a tempting framing that blames the non-developer builders for shipping insecure apps. That framing misreads what the platforms sell. Lovable, Base44, Replit's AI builder, and Netlify's AI offerings explicitly target users who are not equipped to evaluate authentication models or access-control settings. The marketing materials promise that the user can describe an app in natural language and ship it without coding knowledge. The default permission state is a platform decision, not a user one.

RedAccess's report and the follow-on coverage in Axios, VentureBeat, Slashdot, and Futurism reached the same conclusion from different angles: the platforms need to ship safer defaults. A user who has never thought about authentication should not, in the course of describing a "private HR portal" to an AI builder, end up with a publicly indexed URL serving employee data. The way to fix that is not to add a checkbox the user might forget to tick. It is to flip the default so projects are private unless explicitly published, and to gate the publishing action behind a clear warning when the project contains anything that looks like authentication, file storage, or sensitive form fields.

Some of the affected platforms have started moving in this direction since the report. Lovable spent the back half of April and into May dealing with a separate BOLA incident and the resulting bug-bounty mishandling, which Vibe Graveyard has covered separately. Replit pushed a Security Agent and Workspace Security Center update during the same window. Vercel open-sourced a tool called Deepsec aimed at scanning AI-generated projects. The defender stack is finally moving. RedAccess's study is partly responsible for the urgency.

The graveyard lesson

Two patterns are worth separating in the story.

The first is the platform-default pattern. Default-public deployment is a design choice that suited an earlier era of the web, where most of what hobbyists shipped was meant to be public. It does not suit the actual usage profile of modern vibe-coding platforms, where most projects involve some kind of internal data, login flow, or customer information. The 5,000 leaking apps in the RedAccess sample are the direct cost of leaving that default in place.

The second is the verification gap on the builder side. Even non-technical builders are eventually going to learn that "the AI made it work" and "the project is safe to ship" are not the same sentence. The platforms can help by shifting defaults and adding friction at publish time, but the underlying habit needs to develop too: anyone shipping a vibe-coded app that touches anyone else's data needs to ask, before going live, who can reach this URL and what they can see when they do.

The RedAccess study is the moment the anecdotes became a baseline. The next round of data is going to either show the curve bending downward, because platforms changed defaults and builders learned the question, or it is going to show a higher number than 5,000. The bet that the curve bends on its own without platform-level changes is not supported by anything in the report.