The Flaw That Should Not Exist at This Valuation
Lovable, a vibe coding platform valued at $6.6 billion, exposed the source code of every user's project through a Broken Object Level Authorization (BOLA) vulnerability in its API. The flaw was elementary: API endpoints accepted project identifiers without verifying that the requesting user had authorization to access the specified project. Any authenticated user could access any other user's project by modifying the project ID in the API request.
The exposure included source code, database credentials stored in environment configurations, API keys, and complete AI chat histories — the full record of every prompt and response between the user and Lovable's AI assistant. For a platform whose entire value proposition is generating application code through conversational AI, the chat history contains the business logic, architecture decisions, and implementation details of every application built on the platform.
What Was Exposed
The data accessible through the BOLA flaw fell into four categories. First, complete source code for every project built on Lovable — the generated applications that users are building businesses on. Second, database credentials and API keys stored in project configurations — the secrets that connect Lovable-generated applications to payment processors, databases, and third-party services. Third, AI chat histories containing the full conversational record of how each application was designed and built. Fourth, project metadata including deployment configurations and infrastructure details.
For users building commercial applications on Lovable, the exposure was comprehensive. A competitor or attacker with an authenticated Lovable account could enumerate project IDs and systematically download every application's source code, understand its architecture through the AI chat history, and extract the credentials needed to access its backend services. The attack required no sophistication — only sequential API calls with incrementing project identifiers.
Bug Reports Closed, Not Fixed
Security researchers who discovered the vulnerability reported it to Lovable through standard responsible disclosure channels. The company's response was to close the bug reports. Not acknowledge and schedule a fix. Not dispute the severity. Close the reports. The vulnerability remained accessible for 48 days from initial discovery to eventual remediation — a timeline that suggests the fix was driven by public reporting rather than internal security processes.
BOLA is the number one vulnerability in the OWASP API Security Top 10. It is not an obscure edge case or a novel attack technique. It is the first thing any API security audit checks for. Authorization verification on object-level access is a foundational API security control. Its absence in a platform handling user source code and credentials at a $6.6 billion valuation raises questions about what security review processes — if any — were applied to the API before launch.
The Vibe Coding Security Gap
Vibe coding platforms — Lovable, Bolt, Replit Agent, and others — promise to democratize software development by letting users describe applications in natural language and receive working code. The speed is real. Users generate functional applications in minutes that would take traditional development teams weeks. But the security posture of the generated applications inherits the security posture of the platform itself.
Users building on vibe coding platforms are making an implicit trust decision: that the platform securing their source code and credentials has implemented security fundamentals. Lovable's BOLA vulnerability demonstrates that this trust is not always warranted. The platform was building applications faster than it was securing its own infrastructure. Speed without authorization controls is exposure at scale.
The Incident Response Failure
The 48-day exposure window is telling, but the decision to close bug reports without remediation is more telling. Closing a valid security report signals one of two organizational failures: either the security team lacked the authority to prioritize a fix over feature development, or the organization did not have a security team with the capability to evaluate the report. For a company managing user source code and database credentials, both explanations point to the same structural gap.
Responsible disclosure timelines typically give vendors 90 days to remediate before public disclosure. Lovable's response — closing the reports — shortened that timeline by making it clear that private disclosure was not producing remediation. The vulnerability became public not because researchers acted prematurely, but because the vendor's response left no alternative path to protecting affected users.
What This Means for Platform Selection
The Lovable incident is a data point, not an indictment of all AI coding platforms. But it surfaces a due diligence requirement that did not exist when code was written by humans on local machines. When a platform generates, hosts, and deploys your application code, its security posture is your security posture. Its API authorization model protects — or fails to protect — your intellectual property, your credentials, and your users' data.
Organizations evaluating vibe coding platforms for production use need to assess the platform's own security controls with the same rigor they apply to cloud providers. API authorization testing, credential isolation verification, and incident response track record are baseline requirements. A $6.6 billion valuation is not a security credential. A 48-day BOLA vulnerability in a platform holding user source code and database credentials is the kind of finding that should appear in every vendor security assessment from this point forward.
