5,000 Vibe-Coded Apps Shipped to Production With No Authentication: The Deployment-Default Crisis at Lovable, Replit, Base44, and Netlify

Israeli cybersecurity firm RedAccess scanned 380,000 applications generated on four vibe-coding platforms — Lovable, Replit, Base44, and Netlify — and found:

• ~5,000 apps with virtually no security or authentication of any kind.
• ~2,000 apps (roughly 40 percent of the unsecured set) actively exposing sensitive corporate or personal data on the open web.

The research, by Dor Zvi and his team at RedAccess, was published in Wired on May 7, 2026. The exposed apps include hospital work assignments with physician personally identifiable information, an internal application tracking active clinical trials at a UK health company, full unredacted customer-service conversations for a UK cabinet supplier, internal financial information for a Brazilian bank, retailer chatbot conversation logs with customer names and contact details, corporate go-to-market strategy presentations, and shipping company vessel arrival schedules. Lovable, in addition, was hosting phishing pages impersonating Bank of America, Costco, FedEx, Trader Joe's, and McDonald's.

The root cause is not a clever exploit. It is the deployment default.

---

What RedAccess found

RedAccess scanned 380,000 apps hosted on the four platforms' own domains. The scanning methodology was, by Zvi's account, embarrassingly cheap — these apps are publicly accessible by default, indexed by Google, and discoverable through ordinary search queries. No exploit. No clever attack. Standard search-engine reconnaissance.

Of the 380,000 apps, 5,000 had virtually no security or authentication. They served their endpoints to anyone who arrived at the URL. No login wall, no API-key check, no rate limit, no origin-policy enforcement.

Of those 5,000, roughly 2,000 (40 percent) were actively exposing sensitive data. The list of confirmed examples — drawn from RedAccess's published findings — is the part of the story that turns this from "the deployment defaults are bad" into "this is a live data-breach surface for thousands of organizations."

Confirmed exposed apps

From RedAccess's verified inventory:

• A shipping company app exposing which vessels are expected at which ports, plus the cargo records that go with them.
• An internal UK health company app detailing active clinical trials across the country.
• Full unredacted customer-service conversations for a UK cabinet supplier.
• Internal financial information for a Brazilian bank.
• Hospital work assignments containing physician personally identifiable information.
• Retailer chatbot conversation logs including customer names and contact details.
• Corporate go-to-market strategy presentations.
• Corporate advertising purchasing details.

The phishing-host problem

Separately, Lovable was hosting numerous phishing pages impersonating Bank of America, Costco, FedEx, Trader Joe's, and McDonald's. The platform that pitches itself as letting anyone build apps was, in practice, also letting anyone build the brand-spoof page for the next phishing campaign — and hosting it on the platform's own domain, with the platform's own SSL certificate.

A phishing page hosted on *.lovable.app is a phishing page that passes SSL validation, that doesn't trigger newly-registered-domain heuristics, and that runs against the user's reasonable assumption that "this URL is on a platform domain, it's probably fine."

The root cause is the deployment default

The bug class here is unusual because it is not really a code-level bug. It is an architectural decision made at the platform level.

All four platforms — Lovable, Replit, Base44, Netlify — host the apps users generate on the platform's own subdomain. That decision has two consequences the platforms appear not to have fully considered.

Discoverability. Apps hosted on a single shared domain are discoverable through search-engine indexing. Google does not need a special crawler for *.lovable.app or *.replit.dev URLs; the indexing is normal. The platforms could prevent this with a default robots.txt or X-Robots-Tag header; they didn't. RedAccess found their 5,000 unsecured apps via ordinary search.

Public-by-default. Privacy settings on the platforms ship public unless the user explicitly flips them. A user who generates an app, tests it, and hits "deploy" gets a publicly accessible URL by default. The user has to know that the app is now public — and that the data the app touches is now reachable by anyone who finds the URL.

The combination is the cause. "We will host your app on a discoverable URL by default, and your app has no authentication by default." Either one alone is recoverable; together they produce a fleet of accidentally-public production apps.

The platforms' response

The vendor responses are the part of the disclosure worth reading carefully.

Netlify ignored the findings entirely. No public response to RedAccess's outreach.

Lovable, Replit, and Base44 all returned variants of the same statement. The Lovable version: "Lovable gives builders the tools to build securely, but how an app is configured is ultimately the creator's responsibility."

This is a defensible engineering stance once. Twice if the platform commits to make the secure configuration the default. After a Wired story documenting 2,000 actively-leaking apps across a sample of 380,000, with named organizations exposed, "creator's responsibility" stops being defensible. It becomes a position the platform has chosen to hold because changing the defaults is operationally annoying.

Dor Zvi's framing of the structural problem is direct: "Anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check. People can just start using it in production without asking anyone. And they do."

What this is, in pattern terms

The vibe-coded-app exposure story is the deployment-layer version of a recurring pattern across AI tooling. The pattern is:

1. AI tool compresses a workflow. Vibe coding compresses idea-to-deployed-app from days to minutes.
2. The compression removes a security review step the slower workflow used to include. SDLC review, threat modeling, secret scanning, deployment checklist — all of these existed in the pre-vibe-coding flow.
3. The platform's defaults make the unreviewed output the easiest path. Public hosting, indexed URLs, no auth scaffolding.
4. Real damage shows up in a Wired story six months later.

This is structurally identical to:

• Slopsquatting — LLM hallucinates a dependency, agent installs it without the human "wait, is that a typo?" check, malicious package ships to production. See our earlier post.
• Codex agent tokens — agent ships with broad-scope credentials because narrowing them is operationally annoying, attacker reaches the token through a tool input the surrounding product framing implied was safe. See here.
• Spring AI CVE-2026-41712 — implicit DEFAULT_CONVERSATION_ID because requiring developers to set it explicitly was friction the framework chose to absorb, until it couldn't.
• MCP STDIO design flaw — configuration becomes command execution by default because re-validating the trust assumption would have slowed adoption. See here.

The throughline: AI tooling defaults are doing more security work than the documentation acknowledges, and they're failing predictably. The fix in every case is the same shape — change the default, require an explicit choice, treat "the user will know to configure this" as a load-bearing assumption that needs evidence rather than hope.

What to do

If you lead engineering at an org where teams use these platforms

• Inventory. Search Google for site:lovable.app (and equivalents for replit.dev, base44.app, netlify.app) plus your company name, brand assets, product names, and internal codenames. The first signal is almost always a search query.
• Communicate. Tell teams that anything they ship on these platforms is, by default, public and indexed. Most users do not know this. Most security policies were written before vibe coding existed and do not name these platforms explicitly; update them.
• Enforce. If your org's data classification policy says certain data cannot leave a vetted infrastructure, vibe-coded apps with that data are policy violations. Treat them as such.
• Block at the egress. For sensitive data classifications, consider DLP rules that flag uploads to vibe-coding platform domains the same way you'd flag uploads to consumer file-sharing services.

If you are a user of vibe-coding tools

• Treat every deploy as a production-public deploy until you have verified otherwise. Click into the privacy settings. Confirm the URL is not indexed. Verify auth is required for endpoints that touch real data.
• Do not paste real production data into a vibe-coded app. The app is a tool for sketching, not for handling regulated data. Mock data, dev data, or sample data only.
• Add auth scaffolding before you share the URL. Most platforms support auth integrations; the integration is not the default but it is available.

If you build a vibe-coding platform

• Default to private hosting. Require an explicit click to publish.
• Default to authentication-on. Generate apps with an auth-template wired up. Let creators remove it if they don't need it.
• Default to noindex. A robots.txt and X-Robots-Tag: noindex on the platform's hosting domain prevents Google from cataloging unsecured apps for the next researcher (or attacker) to find.
• Surface the security posture in the UI. "This app is public. Anyone with the URL can access it." should be visible at deploy time, not buried in a settings page.
• Detect phishing-page generation. A prompt to "build a Bank of America login page" is not a legitimate creator request. Treat it as a content-policy violation at generation time, not after a researcher publishes a list of the brands you're impersonating.

How Rafter helps

Rafter's Code Analysis Engine scans the code of vibe-coded apps when those apps land in a repository — flagging hardcoded credentials, missing auth on routes that touch sensitive data, unsanitized input on endpoints, and similar patterns. The diff that introduces an unsafe app structure is exactly where the warning is most useful.

What Rafter does not address is the deployment-platform default. If a vibe-coded app never lands in a repository at all — because the platform hosts it directly and the user deploys from a chat interface — there is no diff for a code scanner to see. The only defense in that case is the platform's own defaults, and the platforms' position so far is that the defaults are the user's problem.

The honest read is that scanning helps when the AI-generated code is treated as code: committed, reviewed, scanned, deployed through normal infrastructure. It does not help when the vibe-coding platform is the deployment surface. Closing that gap is on the platforms.

Closing on the compression

Vibe coding compressed the time from idea to deployed app to minutes. The security review didn't get faster. It just stopped happening.

The 5,000-app number is the number of apps that shipped with no security. The 2,000-app number is the subset actively leaking real data. Both numbers are from a sample of 380,000 publicly accessible apps across only four platforms, by one researcher, over a finite scanning window. The actual surface is larger.

Set the defaults to private. Generate apps with auth scaffolding by default. Treat "the creator will configure it correctly" as a load-bearing assumption that needs evidence. The Wired story is the evidence that, today, it doesn't have any.

Further reading

• react-codeshift, the Package No One Wrote: Inside the Slopsquatting Pattern — the dependency-layer version of the same workflow-compression failure.
• Two AI Agent Frameworks, Five CVEs, One Week — the framework-layer version: insecure defaults in Spring AI and Semantic Kernel.
• The MCP Protocol Has a Design Flaw, and Anthropic Says That Is Expected — the protocol-layer version: unsafe defaults inherited downstream.
• A Branch Name as RCE: OpenAI Codex and the GitHub Token It Held — the credentialing-layer version: agent shipped with broad-scope tokens because narrowing them was friction.

Sources

• WIRED — Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web: https://www.wired.com/story/thousands-of-vibe-coded-apps-expose-corporate-and-personal-data-on-the-open-web/
• Axios — Thousands of AI-built apps exposed sensitive corporate and personal data, researchers found: https://www.axios.com/2026/05/07/loveable-replit-vibe-coding-privacy
• Security Boulevard — Thousands of Vibe-Coded Apps Exposing Corporate, Personal Data: RedAccess: https://securityboulevard.com/2026/05/thousands-of-vibe-coded-apps-exposing-corporate-personal-data-redaccess/
• Futurism — Vibe Coded Apps Are Spilling Users' Personal Information: https://futurism.com/artificial-intelligence/vibe-coded-apps-spilling-personal-information
• AI security beyond prompt injection
• A year of AI developer-tool supply-chain attacks