Breach breakdowns

Breakdown: RedAccess found 5,000+ vibe-coded apps with almost no authentication

By Pritesh Ghodge, security engineer · Published 10 November 2026

In May 2026, WIRED and Axios reported that the security firm RedAccess had found more than 5,000 apps built with Lovable, Replit, Base44 and Netlify that had virtually no security or authentication. Anyone with the URL could open them. RedAccess said around 40 percent of those exposed sensitive data. The platforms pushed back hard. This is a plain-English breakdown of what was reported, what hasn't been independently verified, and how to check your own app.

What was reported

• The survey: RedAccess (CEO Dor Zvi) told Axios it found 380,000 publicly accessible assets built with tools from Lovable, Base44, Replit and Netlify, about 5,000 of them containing sensitive corporate data. WIRED's wording: more than 5,000 apps with "virtually no security or authentication of any kind", some with only trivial barriers such as signing in with any email address.
• The method: ordinary Google and Bing searches for the platforms' own hosting domains plus other search terms. No exploit was involved. Those platforms host apps on their own domains by default.
• Sensitive data: WIRED reports Zvi says around 40 percent of the exposed apps (close to 2,000) seemed to reveal private data: a hospital's work assignments with doctors' personal details, ad purchasing data, a go-to-market strategy deck, a retailer's chatbot logs with customer names and contact details, shipping records and financial records. In some cases he said the apps would have allowed administrator access.
• Independent checks: Axios says it independently verified multiple exposed apps, including a shipping company's vessel schedule, an internal clinical-trials app for a UK health company, unredacted customer-service conversations for a UK cabinet supplier and internal financial information for a Brazilian bank. WIRED says it verified several were still online and exposed, but that for the apps it reviewed it could not confirm the data was as sensitive, or as real, as it looked.
• Phishing: RedAccess also said it found Lovable-hosted phishing sites impersonating large brands. Lovable told Axios it has started reviewing and removing them.
• Some fixed quickly: Axios says some apps it viewed were no longer public after the companies were notified.

What was not verified

• The headline numbers come from RedAccess. The reporting doesn't include the list of apps, so the 5,000 and the roughly 40 percent figures are the firm's own claims.
• Some data may be fake or intentional. A security researcher quoted by WIRED notes data in a vibe-coded app might be placeholder or a proof of concept. Wix said two examples WIRED shared looked like test sites or AI-generated data, and that two apps were deliberately set public by their owners.
• The platforms dispute the framing. Replit's CEO said public apps being reachable is expected behavior and privacy can be changed with one click. Wix said where apps were public it reflects a user configuration choice, not a platform vulnerability. Lovable said how an app is configured is ultimately the creator's responsibility, and that it was investigating. Netlify didn't respond. They also said they hadn't been given URLs or enough time. RedAccess disputed that it hadn't provided examples to Base44.
• No breach was confirmed. Nobody has reported that the data was misused. RedAccess says it contacted a few dozen owners, who confirmed data had been exposed.

So this is not "five thousand apps were hacked". It's a survey of apps that were open on purpose, by default or by mistake, and a debate about whose job it is to close them. The useful part for builders is that the cause is dull and fixable.

Root cause

No login wall, or a login wall that lets any email in. That's a different miss from CVE-2025-48757 (open Supabase tables behind a working app), though the two often stack.

• Public by default. Axios says privacy settings on some tools made apps publicly accessible unless the user changed them. Replit says users choose public or private.
• "Sign in" isn't "authorised". Letting anyone with any email in checks that you're a person, not that you're allowed to see this data. This is the same lesson as the Base44 auth bypass.
• Search engines index these apps. Axios notes many are indexed by Google, so "nobody has the link" doesn't hold.
• Nobody reviews it. Zvi's point is that employees can publish an app to production with no security review. Another researcher quoted by WIRED says AI tools do what you ask, and won't secure it unless you ask.

How to check your own app

Only test apps you own.

1. Open your live URL in a private window, signed out. If you can see real pages or data, it's public. Then try a deep link such as /admin or /dashboard.
2. Check the platform's visibility setting. On Replit, Lovable and Base44 look for the public/private or visibility control for the published app. On Netlify, check whether any password or access protection is set. The exact names change, so read the platform's current docs.
3. Try your sign-up with a throwaway email. If you can get in and see other people's records, login isn't the same as access control.
4. Search for yourself: site:yourapp.lovable.app (or your platform's domain) in Google. Anything listed that shouldn't be public is an exposure.
5. If it uses Supabase, read a table with only the public key:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/TABLE?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY"

An empty array or a permission error is good. A real row means anyone can read it. The free Supabase RLS policy checker reads your policies in the browser.

Fix steps

1. Set the app to private unless it's meant to be public, and re-test signed out.
2. Require real authentication and check what each signed-in user is allowed to see, on the server. Don't rely on hiding links.
3. Remove or lock sign-up if the app is internal. Restrict it to your company's email domain or invite-only.
4. Turn on RLS for every Supabase table and write owner-scoped policies:

alter table public.orders enable row level security;

create policy "owner reads"
  on public.orders for select
  to authenticated
  using ((select auth.uid()) = user_id);

5. Take chat logs and uploads off public routes. Customer conversations and documents should be behind auth, with private storage and signed URLs.
6. Keep an inventory. If your team uses AI app builders, list what's published and who owns it. Remove what nobody needs.
7. Rotate anything exposed. If keys or personal data were reachable, assume they were copied and take the steps your privacy obligations require.

The takeaway

You can argue about whether this is a platform problem or a user problem, and the companies and RedAccess clearly disagree. Either way, the app is yours once you publish it. Spend two minutes opening it signed out, from a private window, before real data goes in.

Scan your app free

Sources

• WIRED (Andy Greenberg), Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, 7 May 2026
• Axios (Sam Sabin), AI coding tools exposed sensitive corporate and personal data, 7 May 2026

Related

• Breakdown: how Moltbook's open Supabase database exposed 1.5M agent API keys
• Breakdown: Crissy Field found thousands of Lovable apps with open Supabase tables
• Breakdown: how a public app_id unlocked private Base44 apps
• Lovable app security checklist
• How to check if your Supabase tables are readable by anyone