The Vibe Coding Security Audit: Q2 2026 Baseline

Vibe-coding platforms now generate and host applications at a scale most enterprise security teams have not begun to inventory. In May 2026, a single researcher at RedAccess scanned 380,000 of those apps across four platforms and surfaced 5,000 with no authentication and roughly 2,000 actively exposing sensitive data — clinical-trial dashboards, internal bank financials, hospital staffing records, customer-service transcripts, corporate strategy decks. The story landed in Wired on May 7, 2026, and the platforms' responses ranged from silence to a variant of "the creator is responsible for configuring their app securely."

This report is the first of a recurring Rafter audit. The goal is a citable, conservative, reproducible record of the security posture of major vibe-coding platforms — one that holds up under scrutiny, that does not name individual exposed apps or developers, and that updates quarterly so the industry has a stable reference point as defaults change.

---

What this report is — and what it isn't

The audit covers five vibe-coding platforms that host applications on their own domains: Lovable, Replit, Base44, Netlify, and Bolt. The four named in the RedAccess research are the primary subjects; Bolt is included for breadth because its hosting model is structurally similar. Cursor and Windsurf are out of scope for this volume — they are IDEs rather than hosting platforms, and the "deployment default" lens that organizes this report does not apply to them. If the Q3 update finds the IDE-to-hosting flow has shifted, the scope expands.

The audit is publisher-level, not developer-level. We report counts and categories. We do not name individual exposed apps. We do not enumerate developer email addresses, account handles, or anything that would let a reader identify a specific person whose app was exposed. This is a deliberate choice. The point of the report is to pressure platforms to change defaults, not to embarrass the users who trusted the platforms' defaults in the first place. The methodology section explains how a researcher could reproduce the high-level findings without reproducing the privacy harms.

The audit is observational, not adversarial. Every finding in this volume is based on publicly documented platform behavior, ordinary search-engine queries against platform hosting domains, and the published RedAccess research. Nothing in the methodology requires authentication bypass, credential reuse, rate-limit evasion, or any other behavior that would be unwelcome on the platforms.

The audit is conservative on numbers. Where the data underlying a claim is from a single source, we say so. Where multiple sources converge, we cite all of them. Where Rafter's own observations differ from a published source, we surface the difference rather than pick a number.

Headline findings

On scale and exposure (RedAccess baseline, May 2026):

• ~380,000 publicly accessible apps observed across Lovable, Replit, Base44, and Netlify hosting domains during RedAccess's May 2026 scanning window.
• ~5,000 apps (1.3%) had no authentication and no access control of any kind.
• ~2,000 apps (40% of the unsecured set) were actively serving sensitive personal, corporate, or clinical data without authentication.
• Numerous phishing pages impersonating major consumer brands (Bank of America, Costco, FedEx, Trader Joe's, McDonald's) were hosted on Lovable's own domain.

On platform defaults (Rafter audit, Q2 2026):

• 5 of 5 platforms host generated apps on a shared platform-owned subdomain (*.lovable.app, *.replit.dev, *.base44.app, *.netlify.app, *.bolt.new).
• 5 of 5 platforms publish content under that domain that is reachable by Google indexing absent an explicit opt-out by the creator.
• 0 of 5 platforms ship a default authentication scaffold on newly-generated apps that touch user-provided data — "add auth" is a creator-initiated step in every flow we audited.
• 0 of 5 platforms surface a security posture indicator at deploy time that distinguishes "this app is public" from "this app is gated."
• 2 of 5 platforms publish a dedicated security-best-practices page for app creators (Replit, Netlify). The other three either bury security guidance inside generic docs or do not publish creator-facing security guidance at all.

On platform response (since May 7, 2026):

• 0 of 4 platforms named in the Wired story have publicly announced a change to deployment defaults as of the cutoff date for this report.
• 3 of 4 issued the same general response: "the platform provides the tools to build securely; configuration is the creator's responsibility."
• 1 of 4 (Netlify) has not publicly addressed the findings.

Each of these is expanded in the sections below. The full per-platform breakdown is in the audit table.

Methodology

This volume establishes the methodology for future volumes. The intent is that an independent third party — a security researcher, an enterprise security team, a journalist — can reproduce the findings at the publisher level without doing anything that would expose individual developers or their data.

Scope

A platform qualifies for inclusion in the audit if it meets all four of:

1. It accepts natural-language input from a user and generates an application as output.
2. It hosts the resulting application on a platform-owned domain by default (i.e., the user gets a URL like *.platform.com without having to configure their own hosting).
3. It is currently accepting new users without a significant access gate (waitlist of months, enterprise-only contract, etc.).
4. It has produced at least 10,000 publicly indexed applications, as observable through search-engine queries against the platform's hosting domain.

The five platforms in this volume — Lovable, Replit, Base44, Netlify, and Bolt — meet all four criteria. Cursor and Windsurf meet (1) but not (2): they are IDEs that deploy to user-controlled infrastructure or to third-party platforms (one of which may itself be in scope, as Netlify is). v0, GPT Engineer, and several smaller platforms are noted in the "monitoring list" at the end of the report; they are below the 10,000-app threshold at the time of this volume.

Inventory: counting publicly accessible apps

The starting count for each platform is derived from ordinary search-engine queries of the form site:<platform-hosting-domain> against Google's index. This is the same approach RedAccess used. It has three properties worth surfacing:

• It is non-invasive: the queries reach Google, not the platforms.
• It is conservative: it counts only apps Google has indexed. Apps the platform serves but Google has not crawled are excluded.
• It is publisher-level: results are aggregated at the platform domain. The audit reports counts, not URLs.

For this volume, the inventory baseline is the 380,000-app number published by RedAccess in May 2026. Rafter has not re-run the full RedAccess scan for this volume; doing so would require either reproducing the per-app review (a privacy-harm-multiplying step we explicitly avoid) or a sampling methodology we want to publish for review first. Future volumes will publish their own scan counts using the sampling methodology described below.

Sampling: identifying the unsecured population

In future volumes, the unsecured-app population is identified by a two-stage sampling protocol:

1. Stage 1 (automated, non-content): Random-sample URLs from the indexed population and check only HTTP-level signals — response status, presence of WWW-Authenticate or Authorization request requirements, presence of redirect to a login page, and presence of a robots.txt. No app content is fetched.
2. Stage 2 (manual, content-light): For URLs that pass Stage 1 as "loads with no auth gate," the human reviewer records only the category of content visible on the landing page (financial, healthcare, customer-data, internal-operations, marketing, demo, empty, etc.) without recording the content itself, the developer's identity, or any data subject's identity.

This sampling protocol is designed to produce conservative count estimates with confidence intervals while doing minimal additional harm to data subjects. It is the protocol Rafter intends to run for the Q3 2026 volume. It will be published in detail with that volume so it can be critiqued and reproduced.

What we deliberately do not do

Several actions would produce sharper numbers but cross a line the audit is committed to not crossing:

• We do not enumerate or contact developers of exposed apps. RedAccess did partial outreach to affected organizations; that is responsible disclosure, not auditing. The audit cites RedAccess's outreach where relevant but does not reproduce it.
• We do not scrape, store, or republish data observed in exposed apps. The findings table records categories of exposure ("internal financial data for a national-scale bank") not contents.
• We do not attempt authentication bypass. If an app presents an auth gate, it counts as authenticated for the audit, regardless of whether the gate is robust.
• We do not test platform rate limits to the point of degrading service. Where platform rate-limit behavior is reported, it is from documented limits, not from probing.

These constraints sacrifice some precision in exchange for an audit that does not itself become a story.

The audit table

The following table summarizes the Q2 2026 per-platform defaults audit. "Out-of-the-box" means "observable on a newly-created project on a free or default-tier account, without changing settings."

Default behavior	Lovable	Replit	Base44	Netlify	Bolt
Hosts on shared platform domain by default	Yes	Yes	Yes	Yes	Yes
Apps publicly reachable without auth out-of-the-box	Yes	Yes	Yes	Yes	Yes
robots.txt on platform domain blocks indexing by default	No	No	No	No	No
Auth scaffolding wired up on generated apps by default	No	No	No	No	No
Deploy-time UI surfaces public-vs-private status	Partial	Partial	No	No	Partial
Free tier permits production-scale traffic	Yes	Yes	Yes	Yes	Yes
Dedicated creator-facing security guidance page	No	Yes	No	Yes	No
Documented platform-side rate limiting on app traffic	Limited	Yes	Limited	Yes	Limited
Public response to May 7 Wired findings	Statement	Statement	Statement	None	N/A*

Bolt is included for breadth and was not named in the Wired story; its position on response is therefore not directly comparable.

A few of these rows deserve unpacking, because "Yes / No" compresses a structural choice into a single cell.

Hosting on shared platform domain. All five platforms put generated apps on a single shared subdomain. The architectural reason is convenience: one TLS certificate, one DNS record, one hosting tenant. The security consequence is uniform discoverability — a site: query against the shared domain is the entire inventory.

Public-reachable by default. None of the five require the creator to gate the app at deploy. The default link the platform produces is a public link. "Public" is the property of the URL, not the data behind it; the deploy step does not surface this distinction.

robots.txt and indexability. None of the five platforms ships a default noindex directive on the apps it hosts. A creator who deploys an app expecting "only people I share the link with will find this" is incorrect by default — Google will index the app, and search reconnaissance will surface it.

Auth scaffolding. None of the five platforms generates an app with an authentication template wired up by default. Auth integrations exist on every platform; they are an opt-in step the creator has to know to take. For a non-developer creator — the vibe-coding platforms' explicit target audience — "add authentication" is not a step a creator who doesn't know the term will take.

Deploy-time public/private indicator. Three of the platforms (Lovable, Replit, Bolt) surface some form of "this app is public" indicator at deploy time, but in every case the indicator is informational, not interruptive. "This URL is public" without a contrast against "...and the data inside it will be too" does not redirect a creator's behavior.

Security guidance. Two platforms (Replit, Netlify) publish a dedicated creator-facing security best-practices page that is reachable in two clicks from the platform home. The other three either bury security guidance inside generic developer docs or do not publish creator-facing guidance at all.

Platform response. Lovable, Replit, and Base44 each issued a statement to Wired or to subsequent reporting (Axios, Security Boulevard) that varied in wording but converged on the framing that secure configuration is the creator's responsibility. Netlify did not respond. None of the four have publicly announced a change to deployment defaults as of the cutoff date for this volume.

Findings: anonymized exposure categories

The exposed-app categories below are aggregated from RedAccess's published findings, summarized in Wired and Security Boulevard. They are reproduced here in category form only. No individual app, developer, or organization is named.

Category	Sector	Approximate count (RedAccess)
Internal financial data	Banking (national scale, Latin America)	Multiple
Active clinical trial dashboards	Healthcare (UK, national scale)	Multiple
Hospital staffing records with physician PII	Healthcare	Multiple
Customer service transcripts, unredacted	Retail (UK)	Multiple
Retail chatbot conversation logs with customer PII	Retail	Multiple
Corporate go-to-market strategy decks	Cross-sector	Multiple
Shipping company port-and-cargo schedules	Logistics	Multiple
Phishing-page hosts	Impersonating major US consumer brands	Multiple

"Multiple" in the count column reflects the audit's commitment to publisher-level reporting. RedAccess identified specific apps in each category; the audit does not republish those identifications. Researchers reproducing the methodology will arrive at the same categorical distribution; the per-category counts will vary with the scan window.

The phishing-host category deserves a separate note. The four named platforms each let a creator generate and deploy an arbitrary HTML/JS page with no content review. Lovable was identified in Wired as having hosted multiple phishing pages impersonating major US brands. The structural condition that produces this — platform-domain hosting with platform-issued SSL and no content review at deploy — exists on all four named platforms. The audit notes this as a pattern, not as a Lovable-specific finding.

The structural pattern

Across all five platforms, the audit identifies a consistent default stack:

1. Generate an app from a natural-language prompt.
2. Deploy the app to a platform-hosted URL on a shared platform subdomain.
3. Index the app in search engines, because the platform does not ship a default noindex.
4. Serve the app without authentication, because the platform does not ship a default auth scaffold.
5. Surface the deploy state to the creator as "your app is live" — accurate, but ambiguous about whether "live" means "my link works" or "this is on the open internet."

Each step of this stack is a defensible engineering choice in isolation. Shared hosting domains simplify TLS. Default indexability is the open web's default. Auth scaffolding adds complexity to a first-run experience the platforms have worked hard to keep simple. Deploy-state language matches what backend platforms have said for a decade.

The problem is the composition. A non-developer creator who is not aware that any of these layers exist gets a publicly reachable, search-indexable, unauthenticated production app as the default output of a tool whose advertising explicitly targets non-developers. This is not a code-level bug — no individual line of generated code is wrong. It is the way the layers compose by default. The bug class is "compositional default."

Compositional-default bugs are the throughline across multiple AI-tooling incidents covered in Rafter's research silo:

• Slopsquatting in package managers — LLM hallucinates a dependency, the package manager's default is "install whatever is requested," and the malicious package ships.
• Spring AI's DEFAULT_CONVERSATION_ID — implicit conversation identifier because requiring developers to set one was friction, until the implicit one became an authentication boundary that didn't hold.
• MCP STDIO design — configuration becomes command execution by default because re-validating the trust assumption would have slowed adoption.
• Codex agent tokens — agent ships with broad-scope credentials because narrowing them was operationally annoying, attacker reaches the token through a tool input the surrounding product framing implied was safe.

The vibe-coding platform exposure is the same shape one layer up: the deployment platform is the layer making the unsafe default, and the LLM is the layer that generates the code that inherits it. Each individual layer has a defensible reason for the default; the composition is the failure.

Recommendations

Recommendations are split by audience because the action that closes the gap is different for each.

For platform vendors

The single highest-leverage change is to flip the deployment default from "public, indexed, unauthenticated" to "private, noindexed, gated" and require an explicit creator action to publish. Concretely:

• Default to private hosting. Generated apps are reachable only by the creator and explicitly-invited reviewers until the creator clicks a "publish" action. The action is interruptive: it shows the public-vs-private contrast, names the data the app touches, and requires confirmation.
• Default to noindex on the hosting domain. A platform-level X-Robots-Tag: noindex header on the hosting subdomain prevents Google from cataloging unsecured apps. Creators who want indexability can opt in at publish time.
• Default-generate auth scaffolding for apps that touch user-provided data. The generation layer can detect "this app reads or writes user data" in the prompt or generated code and wire up a minimal authentication template. Creators can remove it if they don't need it.
• Surface security posture at deploy time, not in settings. "This app is public. Anyone with the URL can access it." is a sentence the creator should see on the deploy screen, with a contrast against "this app is gated." If it's only reachable through a settings page, it isn't a default.
• Detect phishing-page generation. A prompt to "build a Bank of America login page" is not a legitimate creator request. Content-policy enforcement at generation time prevents the platform from becoming a brand-spoof host.
• Publish creator-facing security guidance. Two of the five platforms do; three do not. A dedicated "Security for creators" page that is reachable in two clicks from the platform home is a low-cost change.

For app creators (vibe-coded app deployers)

For a creator who has already shipped a vibe-coded app:

• Treat every deployed app as production-public until proven 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. Mock data, dev data, or sample data only. The platform is a tool for sketching, not for handling regulated data.
• Run the site: query for your own work. A site:<platform-domain> query plus your project name surfaces what Google has indexed. If you find apps that should not be public, gate or unpublish them.
• Add auth scaffolding before sharing the URL. Every platform supports auth integrations; the integration is not the default but it is available.

For enterprise security teams

For security leaders at organizations where employees use these platforms:

• Inventory. Search Google for site:lovable.app, site:replit.dev, site:base44.app, site:netlify.app, and site:bolt.new plus your company name, brand assets, product names, and internal codenames. The first signal of exposure 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 organization'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.
• Update third-party risk reviews. If your organization vets SaaS vendors, vibe-coding platforms belong in the same pipeline. The fact that an employee can sign up without a procurement gate does not exempt them.

Cadence and Q3 2026 focus

This audit will be published quarterly. The Q3 2026 volume — scheduled for early August — will focus on three things:

1. Default changes. Have any of the five platforms changed their deployment defaults in the wake of the Wired disclosure? The audit will re-run the per-platform defaults table and report deltas.
2. A Rafter-original scan. Q3 will be the first volume to publish its own scan counts using the sampling methodology described in this volume. The intent is a 5,000-URL random sample per platform, Stage-1 / Stage-2 protocol as described, with confidence intervals.
3. Scope expansion. Bolt was added for breadth in this volume. Q3 will assess whether v0, GPT Engineer, and one or two other platforms have crossed the 10,000-app threshold for inclusion.

Subsequent quarterly volumes will track the same metrics, plus any new platforms that emerge. The audit's value compounds with longitudinal data: a single snapshot says "defaults are bad." A four-quarter time series says "defaults are bad, here's which platforms moved, and here's which didn't."

What this report does not claim

A few load-bearing limits deserve to be stated explicitly so the report can be cited accurately.

• The 5,000-unsecured-apps and 2,000-leaking-apps figures are RedAccess's, published in Wired on May 7, 2026. They are reproduced here as the May 2026 baseline. Rafter has not independently replicated the per-app review.
• The per-platform defaults table is based on publicly documented platform behavior and direct platform observation as of the cutoff date for this volume. Platforms change defaults. The Q3 volume will re-audit.
• The audit covers five platforms. It is not a statement about every vibe-coding tool in the market. Platforms below the 10,000-indexed-app threshold are not in scope for this volume.
• The audit is observational, not adversarial. Apps that present an auth gate are counted as authenticated, even if the gate is weak. A future volume may include a "gate quality" dimension; this volume does not.

Closing

The Wired story documented an outcome: 2,000 apps actively leaking sensitive data, 5,000 apps with no security, four platforms, 380,000 apps in the indexed population. The story did its job — the outcome is now widely known, and the platforms have been on notice for the better part of a week.

The story did not — could not, in the space of a news article — document the structural condition that produced the outcome. The structural condition is the deployment default. Public hosting, indexable URLs, no auth scaffolding, no security posture at deploy time, no creator-facing guidance on two of the five platforms. Each of those is a layer; their composition is the failure.

This report is the first attempt at a recurring, citable record of that structural condition. The expectation is that the platforms will change their defaults — some quickly, some slowly, some not at all. The audit will track which.

The compression that vibe coding offers is real. The security review didn't get faster. It just stopped happening. The least the platforms can do is make the secure configuration the default. Volume 2 will report on which of them did.

Further reading

• 5,000 Vibe-Coded Apps Shipped to Production With No Authentication — the incident write-up of the RedAccess findings.
• react-codeshift, the Package No One Wrote: Inside the Slopsquatting Pattern — the dependency-layer version of the same compositional-default 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.

Sources

• WIRED — Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web (May 7, 2026): 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 (May 7, 2026): https://www.axios.com/2026/05/07/loveable-replit-vibe-coding-privacy
• Security Boulevard — Thousands of Vibe-Coded Apps Exposing Corporate, Personal Data: RedAccess (May 2026): https://securityboulevard.com/2026/05/thousands-of-vibe-coded-apps-exposing-corporate-personal-data-redaccess/
• Futurism — Vibe Coded Apps Are Spilling Users' Personal Information (May 2026): https://futurism.com/artificial-intelligence/vibe-coded-apps-spilling-personal-information

---

The Rafter Vibe Coding Security Audit is a recurring publication. Volume 1 (Q2 2026) is the baseline. Volume 2 (Q3 2026) will track platform-default changes and publish the first Rafter-original scan results using the sampling methodology described above. Subscribe to the Rafter blog to be notified when subsequent volumes are released.

• A year of AI developer-tool supply-chain attacks
• AI security beyond prompt injection
• MCP server security review checklist