Independent security researcher @weezerOSINT publicly disclosed a critical Insecure Direct Object Reference vulnerability in Lovable.dev today. The flaw lets any free Lovable account holder read the full source code, database credentials, AI conversation histories, and live customer data of every project created before an apparent November 2025 cutoff. No exploitation skills required. Five API calls are enough.
Lovable is one of the higher-profile entrants in the AI app-building category. Users describe an application in natural language, and the platform generates code, provisions a backend (typically Supabase), and deploys the result. Reported users include developers from Nvidia, Microsoft, Uber, and Spotify, many of whom have built prototypes, internal tools, and customer-facing apps on the platform. Until today, they apparently did not know those projects were readable by anyone who bothered to try.
What the Bug Actually Does
The vulnerability is embarrassingly simple. From a new free account, @weezerOSINT was able to list other users' public projects, download complete source trees, extract Supabase credentials embedded in the code, and query live production databases. The same endpoint that serves a project to its owner serves it to anyone else who asks, provided the project predates the November 2025 cutoff.
The researcher's proof of concept used an actively maintained admin panel for "Connected Women in AI," a real Danish nonprofit. The project had been edited ten days before disclosure by a developer who has made more than 3,700 edits in 2026 alone. Querying the exposed database returned genuine personal information, including names, companies, job titles, LinkedIn profiles, and contact details for speakers from Accenture Denmark and Copenhagen Business School. None of it was test data.
The bug also exposes every conversation a user has had with Lovable's AI. Developers routinely paste error logs, schema definitions, and production credentials into these chats. Fields like email, first_name, date_of_birth, and stripe_customer_id appear regularly in the leaked histories, alongside keys and tokens that developers shared to debug deployments. All of it sits server-side. All of it is now readable.
The Disclosure Timeline
Lovable was notified through its HackerOne Vulnerability Disclosure Program on March 3, 2026, 48 days before today's public release. The report was triaged and eventually marked as a duplicate. In the interim, Lovable added ownership checks to newly created projects, meaning projects created after the November 2025 cutoff now correctly return a 403 Forbidden response when accessed by unauthorized accounts.
Legacy projects received no such treatment. The identical API endpoint returns different responses based purely on a project's creation date. That is the actual shape of the fix.
Why the Partial Fix Is the Story
Triaging a critical vulnerability and then addressing it only for future customers is an unusual choice. Lovable effectively decided to harden the platform going forward while leaving existing users, the ones who had already invested time and data in the product, exposed. Responses to the disclosure thread have not been kind. One reply characterized it as "an awful business decision made by SF elites."
The gap is particularly glaring given how Lovable markets its security posture. The platform's own documentation promotes automated vulnerability scanners, Row Level Security analysis, and AI-powered penetration testing. None of that caught a basic ownership check missing from the platform's own backend.
A Pattern, Not an Incident
This is not Lovable's first exposure. An earlier vulnerability, tracked as CVE-2025-48757, involved missing RLS policies in Lovable-generated applications and reportedly exposed data across more than 170 user projects. That one at least lived inside code the platform generated on behalf of users. Today's flaw is a platform-level authorization gap that affects Lovable itself.
The broader pattern is worth sitting with. AI-assisted coding tools have been racing to ship, and each new platform handles more sensitive data than the last: production databases, customer PII, business logic, payment integrations. The marketing promises that you can "vibe code" an application in minutes. What often ships underneath is a stack with the thinnest possible layer of authorization scaffolding, hardened reactively rather than by design.
The fact that Vercel disclosed an internal security incident yesterday is probably coincidence. The fact that developer platforms are increasingly visible attack surfaces is not.
What Affected Developers Should Do
The advice for Lovable customers is straightforward and urgent. Any project created before November 2025 should be treated as compromised until Lovable issues a full backfilled patch. That means rotating every credential that ever appeared in source code or AI chats, auditing Supabase row-level security policies on any connected database, and reviewing access logs for unexpected read activity over the past several weeks.
Assume data has been accessed. Plan as if it has been. The cost of acting on that assumption is measured in hours. The cost of the opposite assumption is measured in whatever happens when a database of real customer records is in someone else's hands.
Update: Lovable's Response
Shortly after this piece went live, Lovable posted a statement on social media rejecting the characterization of the issue as a breach and framing the exposure as a visibility-setting misunderstanding rather than a vulnerability.
We were made aware of concerns regarding the visibility of chat messages and code on Lovable projects with public visibility settings.
To be clear: We did not suffer a data breach.
AdvertisementOur documentation of what "public" implies was unclear, and that's a failure on us.
Specifically for public projects, chat messages used to be visible — this is now no longer possible.
When it comes to code of public projects: That is intentional behavior. We have experimented with different UX for how the build history is surfaced on public projects, but the core behavior has been consistent and by design.
Importantly, for enterprise customers, being able to set visibility to public for new projects has been disabled since May 25, 2025.
Three things stand out. First, Lovable is framing the issue as a documentation failure around what "public" means, not a vulnerability. Second, the company says code visibility on public projects is "intentional behavior." Third, the enterprise customer scope has been bounded since May 25, 2025.
What the statement does not address: why a free account could enumerate and download other users' projects with five API calls that did not require authentication of ownership, why the fix only protects projects created after the November 2025 cutoff, and whether the Supabase credentials and customer PII that appear inside the leaked AI chat histories were ever considered covered by "public" semantics. The disclosure thread has continued to push on those points since the statement was posted.
Whether this is a materially different reading of the disclosure depends on whether users genuinely understood their projects were publicly accessible in the way Lovable now describes. The researcher's demonstration of real PII on a Danish nonprofit's admin panel suggests at minimum that some users did not.
Speed without security is not a novel failure mode in this industry. It is, however, becoming a defining one for the current generation of AI coding tools. The companies that will still be standing in five years are the ones that treat authorization checks, and clear defaults around visibility, as features, not as documentation problems to be clarified after a researcher publishes the bug.
