Vibe Coding Goes Mainstream as Leaked API Keys Pile Up

A week that put vibe coding in front of everyone

In mid-October 2026, vibe coding moved from a developer trend to a consumer product feature. On October 13, Google said people can build an Android app in Google AI Studio and run it on their own phone through Google Play. These apps stay private and never appear in the store's search results or listings.11 Bloomberg reported that this applies to anyone 18 or older with a Google account, including people without a paid developer account.17 Google also says that in the coming months users will be able to share these apps with trusted friends. Apps that catch on could later move to a full public listing once they pass Google's trust and safety reviews.11

The next day, Epic Games released a preview of a rebuilt Epic Games Launcher and said plainly that it was "vibe coded."20 Store chief Martin Keely said AI let a small team rewrite the codebase in a different tech stack and ship it faster on Windows and Mac, with a Linux version planned.12 Epic also warned that the preview "will have some bugs" and is "light on features."12 Meanwhile, Cloudflare open-sourced Void, a self-hostable platform pitched as a way for IT departments to manage apps that employees build with AI on their own.18

Taken together, the barrier to shipping software is close to gone. The security record of AI-built software has not kept up, and the weak point is almost always the same: the APIs these apps call and expose.

Why APIs are where vibe-coded apps break

Security firms, researchers and practitioners have independently reached the same diagnosis. Most vibe-coded apps fail in the plumbing that connects them to databases, payment processors and AI model providers, not in their visible features.

The first failure is credentials. RedHub AI explains the technical cause simply: a browser can't read server-side environment variables. So when a model needs a key to make a feature work, it often writes the key straight into client code that every visitor downloads.1 Cubic shows how this happens in frameworks like Next.js. Variables without a public prefix come through as empty strings in browser code, so a call to a paid API fails. The quickest fix is to rename the secret with the NEXT_PUBLIC_ prefix, which ships it to the browser.21 The tool is trying to make the demo work, and the shortcut that does so also exposes the secret.

The second failure is authorization. Several analyses describe the same pattern: generated endpoints check whether someone is logged in but not whether they own the record they are asking for.232 Netizen gives an example in which an invoices endpoint returns another customer's records to any authenticated user who changes the ID in the URL. The attacker uses the API exactly as designed.2 Cubic notes that OWASP's API Security Top 10 ranks this broken object-level authorization first.21 Superblocks adds that vibe coding makes it worse because each prompt produces a slightly different implementation, so endpoints that should enforce the same rules end up handling them differently.23

The third failure is excessive data exposure. Endpoints often return whole database rows when the interface only shows a name and email. The extra fields still reach anyone who inspects network traffic.223

The incident record

This is not only theory. Three cases come up again and again.

The first involves Lovable. A scan of 1,645 apps built with the platform found 170 that let outsiders read or write other users' data, including payment details and third-party API keys. That finding was recorded as a CVE in May 2025.24 Adversa ties CVE-2025-48757 to generated database tables that never had row-level security turned on.27

The second involves Base44, which Wix acquired. Wiz Research found exposed endpoints that let anyone bypass authentication on private apps, including SSO, using only an app ID visible in the URL.8 Adversa says the affected apps included internal corporate chatbots and HR tools.27

The third is Moltbook, a social network for AI agents. Wiz found a Supabase key in its client-side JavaScript that gave unauthenticated access to the production database, with both read and write rights.5 Wiz pointed out that a public Supabase key is meant to be safe to expose when row-level security is configured, and that this protection was missing here.5 The researchers say they could reach about 1.5 million API authentication tokens.5 Reports differ on the number of email addresses: Infosecurity Magazine reports 30,000,5 while Zuplo and Caspio put it at about 35,000.824 Either way, the impact was severe. Wiz said an attacker could impersonate any agent on the platform with a single API call.5

The numbers behind the pattern

Larger surveys suggest these incidents are typical. Newly.app cites a January 2026 SupaExplorer scan of more than 20,000 indie vibe-coded launch sites, which found about 11% exposing Supabase credentials in frontend code.4 The same guide cites GitGuardian's count of 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% increase over the year before.4 Zuplo reports that Escape.tech scanned 5,600 deployed vibe-coded apps and found more than 2,000 vulnerabilities and over 400 exposed secrets.8 Adversa cites a Veracode finding that 45% of AI-generated code samples failed security tests.27 It also cites a GitGuardian figure of 24,008 unique secrets exposed in MCP configuration files, the files that connect AI agents to outside tools.27

Visibility is a separate problem. Caspio reports that a security firm found about 380,000 publicly accessible apps and assets across four vibe-coding platforms in May 2026. Roughly 5,000 of them exposed sensitive data, largely because privacy was set to public by default.24 Caspio also cites a June 2026 academic audit that found at least one vulnerability in 91% of 200 deployed vibe-coded apps.24

The exact figures should be read with care. Many come from vendors that sell the fix, and the methods vary widely. What matters is that they all point the same way, and that the incident record backs them up.

Where the analyses diverge

The main disagreement is over who should fix the problem.

One group says teams should secure the code they generate. Cubic and Threatcop recommend reading every diff, scanning for secrets on every commit, and adding tests in which a second user requests the first user's record and gets an error.2126 RedHub stresses that a key that has ever reached a browser should be treated as already burned and rotated, not just moved.1

A second group says the platform should take care of it. Zuplo argues that an API gateway can handle authentication, rate limiting, input validation and secrets centrally, before traffic reaches the generated backend.8 Superblocks argues for a single auth middleware and policy layer instead of separate AI-generated checks on each endpoint.23 Caspio argues that builders shouldn't hold credentials at all.24

A third group looks at the agent layer. MCP Manager argues that the unmanaged Model Context Protocol layer is the biggest exposure for most organizations, because vibe-coded projects pick up whatever authentication method the AI happens to generate.25 P0 Security warns of a growing pile of service accounts, OAuth clients and API keys that outlive their purpose.

Researchers are also working on the models themselves. A September 2026 arXiv paper on SecureVibe reports that training focused on security improved secure-solution rates on vibe-coding benchmarks, including on vulnerability categories the model had not seen before.28 The authors note that code can pass its functional tests and still be insecure, which is the heart of the problem.28

What it means

The platform-level approach is the one that matches how vibe coding is actually spreading. Google's new pathway targets people who don't have a developer account, by design.17 Practitioners note that people building apps from prompts often can't spot an exposed key or a missing input filter in the first place.25 Telling these users to review their diffs won't work at scale.

The costs also go beyond data leaks. Kodu describes leaked keys turning into AI, cloud, SMS and maps bills that small teams notice only when the invoice arrives.3 Zuplo recounts a developer whose exposed keys were used to burn through hundreds of dollars in API credits overnight.8

Google's design has a sensible feature: apps start private, and the friends-and-family sharing phase is planned with a security review.15 That matters, because the worst cases so far came from apps that were public from day one with their data layer wide open. Still, being private doesn't secure the keys an app holds or the third-party APIs it calls.

Vibe coding has reached the point where Epic jokes that "programming is hard" while shipping a production launcher.20 The next step needs to happen at the API boundary: secrets kept server-side by default, ownership checks enforced in one place, and keys scoped and rotated automatically. The tools need to make the secure option the easiest one before the next billion apps are prompted into existence.