The Rise of Vibe Coding and the Fall of Software Security

A new wave of software is flooding the internet. Powered by AI tools like Lovable, Bolt, and Cursor, non-technical founders and hobbyist developers are shipping fullstack web applications in weeks instead of months. The industry calls it “vibe coding”, the practice of describing what you want in plain language and letting an AI generate the code for you.

The results look impressive. The applications work. They deploy instantly. And they are, overwhelmingly, insecure.

At Kor Solutions, we’ve spent the past several months testing vibe coded applications across multiple industries. What we’ve found is alarming: the vast majority of these applications contain critical security vulnerabilities that leave user data completely exposed to anyone with a browser and basic knowledge of developer tools.

This is not a theoretical risk. Real users are being affected right now.

The Most Common Vulnerability: Misconfigured Backend-as-a-Service

The single most widespread issue we encounter in vibe coded applications is misconfigured Backend-as-a-Service (BaaS) platforms specifically, Supabase.

Supabase has become the default backend for AI code generation tools because of AI builder platforms like Lovable. When a user tells Lovable to “build me a SaaS app with user accounts and a database,” Lovable generates a React frontend wired directly to a Supabase backend. The app works out of the box.

The problem is what happens beneath the surface.

How the Vulnerability Works

Supabase autogenerates REST APIs from your database schema. Every table you create immediately gets a publicly accessible endpoint. Access control is managed through a feature called Row Level Security (RLS), database-level policies that determine which users can read, write, or modify which rows of data.

Here’s the critical detail: RLS is opt-in, not enabled by default. When a table is created without RLS policies, it is completely public. The anon_key, a public API key that Supabase intentionally embeds in frontend code for client-side queries, effectively becomes a master key to the entire database.

This means that anyone who opens a browser’s developer tools, inspects the network requests of a Lovable built app, and copies the Supabase URL and anon_key can query any table in the database. No authentication required. No special hacking tools. Just a simple API call.

The exposed data is not limited to email addresses. In real world cases, researchers have extracted full names, phone numbers, home addresses, financial records, payment information, personal debt amounts, developer API keys for services like Stripe and Google Maps, and admin access tokens.

CVE-2025-48757: 170 Apps Compromised by a Single Flaw

The scale of this problem became undeniable in 2025 when security researcher Matt Palmer discovered a critical RLS misconfiguration while testing Linkable, a Lovable-built site that generates web pages from LinkedIn profiles. By simply modifying REST API requests and removing authorization headers, Palmer could access the entire user database.

Palmer and his colleague Kody Low built an automated scanner and analyzed 1,645 Lovable created applications from the platform’s own showcase. The results were devastating: 170 apps (10.3%) had critical security flaws, exposing 303 vulnerable Supabase endpoints. The vulnerability was assigned CVE-2025-48757 with a CVSS score of 8.26 (High severity).

The leaked data included personally identifiable information, financial data, transaction histories, subscription details, and developer credentials including API keys for third-party services. In one case, public Stripe integration endpoints were exposed, meaning attackers could potentially override payment settings or inject unauthorized parameters into a live billing system.

Palmer reported the vulnerability to Lovable on March 21, 2025. After 45 days with no meaningful fix or user notification, the CVE was published on May 29, 2025. Semafor broke the story the same day with the headline calling Lovable a “sitting duck for hackers.”

Lovable eventually introduced a “security scanner,” but security researchers found it only checked whether RLS policies existed not whether they were correctly configured. It was, as multiple analysts noted, security theater that provided a false sense of protection while the fundamental architectural problem remained.

A subsequent large scale study by security firm Escape in late 2025 scanned over 5,600 publicly available vibe coded applications and identified more than 2,000 vulnerabilities, over 400 exposed secrets (API keys and tokens), and 175 instances of exposed personally identifiable information including medical records, bank account numbers, phone numbers, and emails. The problem was not limited to a single platform it was systemic across the vibe coding ecosystem.

Source: r/vibecoding — “170 Lovable Apps Got Hacked Because of One…”; Matt Palmer’s CVE-2025-48757 Statement

This Isn’t New: Firebase Had the Same Problem

It’s important to understand that Supabase is not the first BaaS platform to suffer from this class of vulnerability. Firebase, Google’s widely used app development platform, has been plagued by the exact same misconfiguration issues for years.

In 2024, security researchers scanned over five million domains connected to Firebase and found 916 websites with either no security rules or misconfigured security settings. The exposed data included over 125 million sensitive user records containing emails, names, phone numbers, billing information, and astonishingly 19 million plaintext passwords. A separate analysis in early 2022 estimated that roughly 5% of all Firebase instances were misconfigured, affecting thousands of mobile applications including dating, fitness, bookkeeping, and e-commerce apps, some with over 10 million downloads.

As recently as early 2026, a Firebase misconfiguration in Chat & Ask AI, an app with over 50 million installs, left more than 300 million private chat messages from 25 million users exposed to the open internet, including deeply personal conversations about mental health, financial details, and other sensitive topics. The security rules were simply set to allow public read access.

The pattern is identical to what we see with Supabase today: developers leave databases in permissive “test mode” configurations, forget to lock them down before deployment, and the platform’s default settings do little to prevent it.

The critical difference is scale. Before AI code generation tools, building and deploying a full-stack web application required enough technical knowledge that developers were more likely, though far from guaranteed, to understand the need for proper access controls. The barrier to entry served as an imperfect but real filter. Vibe coding has removed that barrier entirely. Anyone can now ship a production application without ever understanding what Row Level Security is, what an anon_key does, or why their database is publicly queryable.

The result is an explosion of insecure software at a scale that dwarfs anything we saw during the Firebase era.

What We’re Seeing Across Industries

At Kor Solutions, our security assessments of vibe coded applications have revealed consistent vulnerability patterns across every industry we’ve tested.

The common thread in every case is the same: the AI optimized for making the application work, not for making it secure. The code functions exactly as described. It just happens to leave every door and window wide open.

Our Commitment to Data Security

At Kor Solutions, we believe that the democratization of software development is a positive force. More people should be able to bring their ideas to life. But that capability must not come at the cost of the security and privacy of the users who trust those applications with their data.

We will never ship software that treats security as an afterthought.

We care about our clients’ success, and we care about their customers’ data. Those two things are inseparable. A single data breach can destroy the trust that took years to build, expose a business to regulatory fines and legal liability, and cause real harm to the people whose information was compromised.

What You Should Do Right Now

If you’ve built an application with a vibe coding tool, or if you’re considering it, here’s what we recommend:

Audit your Supabase configuration immediately. Enable RLS on every table. Create policies that restrict access to authenticated users viewing only their own data. Test by querying your API with the anon_key directly and if you get data back without authentication, you’re exposed.

Remove all secrets from frontend code. Search your codebase for patterns like sk-, sk_live_, service_role, and any hardcoded API keys. Move everything to server-side environment variables.

Don’t trust AI-generated security. The code your AI tool generates may work perfectly while being fundamentally insecure. Working code and secure code are not the same thing. Have a qualified security professional review your application before it goes into production.

Engage a security partner. If you’re handling real user data, especially in regulated industries like finance, healthcare, or education, a professional security audit is not optional. It’s the baseline.

The Bottom Line

Vibe coding has made it astonishingly easy to build software. It has not made it easy to build secure software. The gap between those two things is where data breaches happen, where user trust is destroyed, and where businesses face existential risk.

At Kor Solutions, we’re here to close that gap. Whether you need a security audit of an existing application, guidance on secure architecture for a new project, or a development partner that builds security in from day one - we’re ready to help.

Your users trust you with their data. We help you earn that trust.

To learn more about how Kor Solutions can secure your application, contact us at contact@korsolutions.net.