Lovable April 2026 Data Breach: Every Project Before November 2025 Exposed

TL;DR

Quick Answer: On April 20, 2026, security researcher @weezerOSINT disclosed a mass data breach affecting every Lovable project created before November 2025. By creating a free Lovable account, any user can read another tenant's source code, database credentials, AI chat history, and customer data. Morgan Linton, cofounder and CTO of BoldMetrics, amplified the warning the same day. This is the third major Lovable security incident in thirteen months, following CVE-2025-48757 (CVSS 8.26 to 9.3) in 2025 and a February 2026 incident that exposed 18,697 user records at universities including UC Berkeley and UC Davis. Teams using Lovable should rotate all secrets immediately, review Supabase audit logs, and treat any data that touched the platform as potentially public.

What Is Lovable?

Lovable is an AI "vibe-coding" platform that lets non-developers describe an application in natural language and have it generated, hosted, and connected to a Supabase backend automatically. The platform promotes its Discover page featuring user-built apps, some of which have reached tens of thousands of end users.

Because Lovable provisions the frontend, the backend, authentication, and database connectivity as a single bundle, a platform-level tenant isolation failure reaches every app built on it, not just the app being targeted. That is what makes the April 20, 2026 disclosure materially different from the earlier Lovable incidents.

The Disclosure: What @weezerOSINT Found

The Claim

On April 20, 2026, researcher @weezerOSINT posted on X warning Lovable users of a mass data breach. In the researcher's own words, "Lovable has a mass data breach affecting every project" created before November 2025. By simply creating a Lovable account, they were able to access another user's:

• Source code of other users' Lovable projects
• Database credentials, including Supabase connection strings and service keys
• AI chat histories containing prompts, system context, and the conversational trail that shaped each app
• Customer data stored in databases connected to those projects

All four categories, according to the disclosure, are "readable by any free account." The scope described is platform-wide: every Lovable project created before November 2025 is listed as affected.

Morgan Linton, cofounder and CTO of BoldMetrics, amplified the warning the same day with a post titled "Warning to all Lovable users," pushing the disclosure beyond the security research community and into the broader founder and developer audience.

Why the November 2025 Cutoff Matters

The November 2025 boundary suggests that Lovable introduced a platform change at that point that closed the isolation gap for newer projects but left historical projects in the vulnerable state. If accurate, this means the root cause is not a customer-side misconfiguration. It is a product-side regression in how the platform stored or exposed project artifacts before that change.

Teams cannot fix a platform-level tenant isolation bug by adjusting their own code. They can only reduce blast radius by rotating credentials and pulling sensitive data out of the affected projects.

This Is Not Lovable's First Security Incident

The April 2026 disclosure is the third major Lovable-related security event in about thirteen months. Understanding the pattern is important, because it changes how a compliance or security team should evaluate the platform going forward.

Incident One: CVE-2025-48757 (March to May 2025)

This one has a well-documented timeline:

The root cause was systematic. Lovable generated applications that used the Supabase public anon_key to make direct REST API calls from the browser, without any Row Level Security (RLS) policy enforcing per-user access. Of 1,645 scanned Lovable-built apps, researchers found 170 apps (about 10.3 percent) with 303 vulnerable endpoints. Attackers did not need credentials. A single modified query could dump entire tables containing:

• User emails, usernames, and phone numbers
• Payment and subscription records
• API keys for Stripe, Google Maps, Gemini, and eBay
• Home addresses, debt balances, and other sensitive personal data

Semafor summarized the state of the platform at the time as "a sitting duck for hackers." For a deeper look at why this pattern keeps recurring, see our guide on Supabase security best practices.

Incident Two: The Taimur Khan Disclosure (February 2026)

On February 27, 2026, tech entrepreneur Taimur Khan published findings on a featured Lovable app used to create exam questions and manage grades across universities including UC Berkeley and UC Davis, plus K-12 schools. Khan identified 16 vulnerabilities, 6 critical, and reported the following exposure:

• 18,697 user records compromised
• 14,928 unique email addresses
• 4,538 student accounts
• 10,505 enterprise users
• 870 individuals with full PII exposed

Khan also demonstrated that the flawed app permitted unauthenticated bulk email sending, unauthenticated account deletion, grade manipulation, and exposure of admin email addresses. The app had been actively featured on Lovable's Discover page, accumulating over 100,000 views and 400 upvotes before Khan's disclosure.

The technical root cause was memorable. The AI-generated backend contained an inverted access check in its authentication path. As Khan put it, "the guard blocks the people it should allow and allows the people it should block."

Lovable CISO Igor Andriushchenko responded that "any project built with Lovable includes a free security scan before publishing," adding that "ultimately, it is at the discretion of the user to implement these recommendations." The company also noted that some of the vulnerable code was not generated by Lovable and that the database in question was not hosted by Lovable itself. Khan pushed back, arguing the platform should not "showcase an app to 100,000 people, host it on your own infrastructure, and then close the ticket when someone tells you it's leaking user data."

This incident is also covered in our AI coding assistants security risks guide.

Incident Three: The April 20, 2026 Mass Breach

The current disclosure is categorically different. The first two incidents could be attributed to customer-built apps with bad access control. The April 2026 report describes a platform-level failure that reaches every pre-November 2025 project, regardless of how carefully the customer configured their app.

This is consistent with the broader pattern documented in the Cloud Security Alliance's February 2026 research note on the AI-Generated Code Vulnerability Surge, which tracked at least 20 documented security incidents exposing tens of millions of users across AI-powered applications between January 2025 and February 2026. Nearly every incident traced back to the same preventable root causes: missing authorization, exposed secrets in client code, and weak or absent multi-tenant isolation on the underlying platform.

Technical Root Cause Analysis

Based on the public disclosures and the earlier CVE, the failure pattern on Lovable has three reinforcing layers.

Layer 1: Missing Row Level Security by Default

Lovable's generated apps historically called Supabase directly from the browser using the anon_key. Without an RLS policy attached to each table, Supabase returns rows to any caller holding that key. The anon_key is public by design, so unauthenticated strangers can read the database as if they were a logged-in user. This is a well-documented Supabase security footgun that has burned dozens of AI-generated apps.

Layer 2: AI-Generated Access Control Logic

Even when access control is attempted, AI-generated code frequently inverts or weakens the check. The Taimur Khan disclosure is the canonical example, where an authentication guard blocked authenticated users and welcomed unauthenticated ones. These bugs pass visual review because the code "looks right." They only fail at runtime, which an untrained builder will not notice until a researcher publishes the exploit. Our post on AI agent security guardrails for SOC 2 and ISO 27001 covers why this class of bug is expected, not exceptional.

Layer 3: Platform-Level Tenant Isolation Failure

The April 20, 2026 disclosure points to a new, deeper layer. If a free Lovable account can read another user's source code, database credentials, and chat history, then the problem is not inside the generated app. It is inside Lovable's own multi-tenant storage and access model. This is the class of failure that SOC 2 CC6.1 and ISO 27001 A.5.15 are designed to prevent at a vendor level.

Why This Attack Matters

Credentials Embedded in AI Workflows Are Secrets

Lovable projects include the full trail of what the user asked the AI to build. That AI chat history often contains pasted API keys, sample records, internal system prompts, and integration details. If the chat log is readable by another free account, every one of those pasted values should now be treated as leaked.

Source Code Discloses the Attack Surface

An attacker with source code and database credentials for a target app does not need a vulnerability scanner. They have the schema, the business logic, the auth flow, and the keys. The investigation cost for them is near zero.

Customer Data Flows Through Connected Backends

Lovable apps commonly connect to Supabase, Stripe, Resend, SendGrid, and other services. When the project's secrets are readable, every downstream system those secrets touch is also exposed. This is the non-human identity blast radius problem we discussed in the context of the Vercel incident the day before this one.

What Lovable Users Should Do Now

Immediate Actions (First 24 Hours)

1. Treat every credential ever stored in a Lovable project as compromised. Rotate Supabase anon keys, service role keys, and any third-party API keys (Stripe, SendGrid, Resend, OpenAI, Anthropic, Google Maps, Gemini, eBay, and similar) that were pasted into a Lovable app or chat.
2. Rotate database credentials. In Supabase, reset project API keys and consider rotating to a new project reference where feasible. Revoke any service role keys that ever appeared in a Lovable chat.
3. Enable and audit Row Level Security on every table in every connected Supabase project. Assume no RLS is in place until you have read the policy yourself. This is covered in detail in our Supabase security best practices post.
4. Pull the Supabase logs for the last 60 days and look for reads from unexpected IP addresses, bulk SELECT * queries, or enumeration patterns against user tables.
5. If the project handled personal data of EU residents, start the clock on your GDPR data breach notification obligations. The 72-hour window to notify the supervisory authority begins when you become aware of a likely breach, not when you have finished investigating.

Follow-Up Actions (Within 72 Hours)

1. Export and archive any project data you need before deciding whether to keep using Lovable. Treat it as evidence for an incident investigation.
2. Remove sensitive credentials and secrets from all AI chat histories. Chat logs that once contained keys should be considered tainted even after rotation, because the original values were visible for an unknown period.
3. Notify affected end users where personal data exposure is plausible. For customer data breaches, follow your incident response policy and your contractual notice obligations.
4. Audit connected SaaS accounts. Check Stripe, Resend, SendGrid, and any OAuth-connected apps for unusual activity, new API keys, or unauthorized webhook endpoints.
5. Decide whether Lovable can remain in your stack. This is the third major Lovable security event in thirteen months. A vendor risk decision here is legitimate and defensible.

Structural Controls Going Forward

• No production secrets in AI coding tools. Treat Lovable, Cursor agents, Replit, and similar tools as untrusted environments for secret material. Use placeholder values during development and inject production secrets only at deploy time through a managed secret store. See our post on why you should stop storing credentials in env files.
• RLS on by default. Never ship a Supabase-backed app without row-level security policies, regardless of which tool generated the code. Review the policies by hand, not by asking the AI to confirm they exist.
• Vendor risk review for AI platforms. Apply the same diligence to vibe-coding platforms as you would to any data processor. This is the core idea in our vendor management for SOC 2 and ISO 27001 guide.

What This Means for SOC 2 and ISO 27001

SOC 2 Implications

For teams pursuing SOC 2 compliance, a Lovable-hosted project that handles customer data touches several Trust Services Criteria:

• CC6.1 (Logical and Physical Access Controls): Requires that access to systems and data is restricted to authorized users. A platform-level tenant isolation failure is a direct CC6.1 finding for any customer that stored production data on Lovable.
• CC6.6 (Logical Access to External Services): Applies to systems outside your immediate perimeter, including AI coding platforms with direct access to your Supabase database.
• CC7.1 (System Monitoring for Anomalies): Requires detection of unauthorized access. Supabase audit logs and alerting on unusual query patterns are the practical control here.
• CC9.2 (Vendor and Business Partner Risk): Ongoing vendor risk management. Three incidents in thirteen months is a risk signal that should force a re-evaluation of Lovable's suitability as a data processor.

ISO 27001 Implications

ISO 27001 (2022) has explicit controls aligned with this incident:

• A.5.15 (Access Control): Covers both user-level and tenant-level access controls. Tenant isolation failures on a vendor platform are directly in scope.
• A.5.19 and A.5.20 (Supplier Relationships): Require defined and contracted security expectations for suppliers. Vibe-coding platforms that host your code and data qualify.
• A.5.23 (Information Security for Use of Cloud Services): Directly applicable to platforms like Lovable that combine hosting, code generation, and database connectivity.
• A.8.9 (Configuration Management): How you classify, handle, and rotate secrets that touched the platform is a configuration management activity.
• A.8.16 (Monitoring Activities): Requires monitoring for unusual activity. Audit logs on Supabase and connected services are the operational control.

For organizations under GDPR, a breach that exposed personal data triggers the 72-hour notification requirement to the supervisory authority. The fact that the root cause sits at a processor does not remove the controller's obligation to notify.

Broader Lessons for 2026 Security Programs

Vibe-Coding Platforms Are Data Processors

When a platform generates code, hosts it, and holds the connection string to your database, it is not "just a coding tool." It is a data processor in every sense that matters under GDPR, SOC 2, and ISO 27001. The sooner security teams treat vibe-coding platforms with the same rigor they apply to Snowflake, Datadog, or AWS, the fewer April 20 disclosures the industry will read in 2027.

Three Strikes Is a Pattern, Not a Fluke

One incident is an accident. Two is a coincidence. Three distinct failure modes in thirteen months (missing RLS, inverted auth logic, tenant isolation) point to a platform that is shipping faster than it can secure its default configuration. Customers who care about compliance need to decide whether the product's velocity is worth the accumulated risk, or whether it is time to rebuild affected apps on a stack with better defaults.

Audit Logs Only Help if You Read Them

For this class of breach, the detection control is not a WAF. It is a well-reviewed Supabase audit log, an alert on unexpected service role key usage, and a habit of sampling query patterns. None of this is new, and yet it is the first thing that gets skipped when a team moves fast on a no-code tool. The lesson repeats from the Moltbook AI agent incident and from the McKinsey Lilli hack.

Security Checklist

Within 24 Hours

• Rotate every Supabase anon and service role key used by any Lovable project
• Rotate every third-party API key that was pasted into a Lovable app, prompt, or chat
• Enable RLS on every table and review the policies by hand
• Pull 60 days of Supabase audit logs and search for anomalous reads
• If EU personal data is involved, open the GDPR breach notification process

Within 72 Hours

• Export and archive any data you need from Lovable projects
• Remove sensitive values from AI chat histories and treat original values as burned
• Audit connected SaaS accounts (Stripe, Resend, SendGrid, OAuth apps) for unusual activity
• Notify affected end users where customer data exposure is plausible
• Document the incident, evidence, and actions for your SOC 2 or ISO 27001 auditor

Ongoing

• Enforce "no production secrets in AI coding tools" as a written policy
• Require RLS on every Supabase-backed project, verified manually
• Include vibe-coding platforms in your vendor risk assessment on the same footing as traditional data processors
• Add vibe-coding platform failures to quarterly tabletop exercises
• Subscribe to researcher disclosures (weezerOSINT, CVE feeds, Supabase advisories)

Conclusion

The April 20, 2026 Lovable disclosure is the third major security event on the platform in just over a year, and it is the one that finally escalates from "misconfigured customer app" to "platform-level tenant isolation failure." Any team that shipped a Lovable-built app before November 2025 should treat the associated secrets, source code, AI chat histories, and customer data as exposed, and respond accordingly.

More broadly, the incident is a reminder that vibe-coding platforms sit in the same regulatory and operational category as any other data processor. They host credentials, store customer data, and generate the attack surface of production apps. Treating them with less diligence than you would apply to a traditional SaaS vendor is a compliance gap that an auditor will find eventually, and an attacker will find sooner.

If you need help evaluating vibe-coding platforms, adding them to your vendor risk program, or responding to an incident on one of them, get in touch with Bastion. We help startups and SMBs build SOC 2 and ISO 27001 programs that treat AI tooling as what it really is, a data processor with real blast radius.

Sources

• @weezerOSINT on X: Lovable has a mass data breach affecting every project - Original April 20, 2026 disclosure
• Morgan Linton on X: Warning to all Lovable users - Same-day amplification from the BoldMetrics cofounder and CTO
• The Register: AI-built app on Lovable exposed 18K users, researcher claims - Coverage of the Taimur Khan disclosure (February 2026)
• Rankiteo: Supabase and Lovable February 2026 vulnerability summary - Victim count breakdown and CISO quote
• Superblocks: Lovable Vulnerability Explained, How 170+ Apps Were Exposed - Technical analysis of CVE-2025-48757 and disclosure timeline
• Symbiotic Security: Your Lovable App Is Probably Exposed, Here's How to Check - Practical scanner guidance for affected apps
• CursorGuard: 170 Vibe-Coded Apps Leaked User Data, The RLS Misconfiguration Epidemic - Ecosystem-level analysis of the RLS pattern
• Gptsters: Supabase Service-Role Key Exposed in Lovable, Fix Guide - Remediation steps for service role key exposure
• Barrack AI: Every AI App Data Breach Since January 2025, 20 Incidents, Same Root Causes - Cross-incident pattern analysis and Lovable timeline
• CSA Labs: AI-Generated Code Vulnerability Surge 2026 - Research context on vibe-coding security debt
• SC Media: Lovable platform faces scrutiny over app vulnerabilities and data leak - Industry response summary
• Semafor: The hottest new vibe coding startup Lovable is a sitting duck for hackers - Background on Lovable's 2025 security posture
• Cybernews: Lovable apps may be dangerous by design, research finds - Root cause analysis across multiple Lovable incidents
• Brinztech: AI Platform Database Leaked via Supabase Misconfiguration - Breach alert and technical summary
• Yahoo Tech: Lovable accused of hosting malware-ridden apps exposing thousands of users - Additional context on hosted-app risk