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.
What Lovable Hasn't Said
As of publication, Lovable has not issued a public statement on the disclosure, the 48-day interval, or the decision to leave legacy projects unpatched. The HackerOne program page and the company's security documentation remain unchanged.
That silence is its own message. For a platform whose business model depends on developers handing over production data and trusting the platform to protect it, the response to a critical disclosure is itself a signal. So far, the signal is not reassuring.
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 as a feature, not an afterthought to be retrofitted after a researcher publishes the bug.
