Build · founder · 5 min read

380,000 Vibe-Coded Apps Were Publicly Accessible. 5,000 Were Leaking Your Data.

RedAccess found 380K AI-built apps publicly exposed — 5K leaking sensitive data. What happened, which tools were involved, and what to do right now.

Published May 8, 2026 ·

security lovable replit base44 netlify

On May 7, 2026, Axios published research from Israeli cybersecurity firm RedAccess that should concern every founder who has shipped an internal tool or prototype using a vibe coding platform. Researchers found approximately 380,000 applications built with AI coding tools that were publicly accessible on the open web — and roughly 5,000 of them were actively leaking sensitive corporate and personal data.

Medical records. Active clinical trial data. Unredacted customer service conversations. Internal financial information from a Brazilian bank. Shipping manifests detailing which vessels were expected at which ports. All of it sitting in apps that were built with a prompt, deployed with a click, and shared with a default-public URL.

The tools involved: Lovable, Base44, Netlify, and Replit.

How it happened

This isn’t a single hack. It’s a privacy-settings problem at scale.

Most vibe coding platforms default new apps to publicly accessible URLs — and most builders never change it. When you deploy something fast to show a stakeholder or test with a client, you hit “deploy” and share the link. You don’t go looking for a privacy toggle. Why would you? It feels like a prototype.

The problem is that those URLs are often indexed by Google and other search engines. Meaning the app you built to track your active U.K. clinical trials isn’t just accessible to people who have the link — it’s findable by anyone who searches the right terms. RedAccess CEO Dor Zvi called it “one of the biggest events ever where people are exposing corporate or other sensitive information to anyone in the world.”

That’s not hyperbole. It’s a consequence of the speed-first, deployment-easy philosophy that makes vibe coding appealing in the first place. The same frictionless experience that helps you ship an MVP in a weekend also removes the friction that would have made you think twice about what you were exposing.

Who’s at risk

If you built any of the following with a vibe coding tool and deployed it, check your privacy settings today:

• Internal dashboards connected to real customer data
• Apps that pull from your CRM, your database, or any API with customer records
• Tools used by your team that contain employee or financial data
• Prototypes shared with clients that included their real data “just to test”
• Any app built on Lovable, Base44, Replit, or Netlify where you didn’t explicitly set visibility to private

The RedAccess findings don’t mean your app is definitely exposed — they mean this class of app is structurally vulnerable to this class of mistake. The default settings on several major platforms made public deployment the path of least resistance.

What each platform said

Lovable and Replit did not immediately respond to Axios for comment. Base44, which Wix acquired in April 2026, was already under scrutiny after security firm Wiz found a critical vulnerability in its architecture earlier this year. Netlify, notably, is the deployment layer rather than the builder — apps deployed there were likely built elsewhere and pushed to Netlify’s CDN, where Netlify’s own privacy controls may not have been applied.

Lovable has been moving on security since the BOLA exposure in March 2026: their 2.0 release added a built-in security scanner, and the team has been more proactive about flagging privacy misconfigurations. But the RedAccess data makes clear that these mitigations aren’t catching everything, and that the volume of at-risk apps built before these improvements is substantial.

What to do right now

Step 1: Audit everything you’ve deployed. Log into every vibe coding platform you’ve used — Lovable, Replit, Base44, Bolt, Firebase Studio, any of them — and check the visibility settings on every app you’ve published. Most platforms now have a way to view all your projects. Look for any app with a default-public URL.

Step 2: Make internal tools private immediately. If the app is internal-facing (a dashboard, a reporting tool, an ops interface), make it private or require login. Don’t assume that an obscure URL is protection enough — it isn’t.

Step 3: Audit your data connections. If the app connects to a database, an API, or any data source with real customer or business data, assume the data is exposed until you’ve confirmed it isn’t. Check your database’s access logs if your platform provides them.

Step 4: Don’t use real data in prototypes. For anything you’re sharing externally before launch, use dummy data. This sounds obvious, but the research exists because it wasn’t obvious in practice.

Step 5: Check for indexing. Search Google for your app’s URL or distinctive strings from its content. If it’s indexed, submit a de-indexing request via Google Search Console and set the app to private immediately.

The bigger issue

This story is going to keep happening. The speed-first design of vibe coding tools is a feature, not a bug — but it creates a consistent blind spot around the post-deploy step. Most founders are focused on building, not on what happens after they click publish.

The industry response so far has been reactive: tools add security scanners after an incident gets press coverage, platforms update default visibility settings after researchers find exposed data. That pattern suggests more incidents before the structural defaults genuinely improve.

Until the defaults change across the board, the burden is on you. Know what you’re deploying, know who can see it, and treat any app connected to real data as a production system from day one — not a prototype you’ll secure later.

Sources: Axios, May 7 · Security Boulevard · eWeek