Lovable’s Leak Mess Shows Vibe Coding Still Has a Basic Security Discipline Problem
Lovable’s security mess is useful precisely because it is not subtle. The company spent the first part of the incident doing what too many fast-growing AI products still do when confronted with a bug that looks bad in screenshots: argue about semantics before fixing the trust problem people can plainly see.
According to The Register’s reporting, a researcher said they could create a free Lovable account, make five API calls, and access another user’s source code, chat history, credentials, and other project data. The bug was described as a Broken Object Level Authorization flaw, one of the least glamorous but most reliable ways to embarrass any software company exposing multi-tenant APIs. The researcher also said the issue had been reported 48 days earlier through HackerOne. Lovable’s public response first insisted there had not been a data breach and suggested the confusion stemmed from “intentional behavior” and unclear documentation around public projects. Later, the company apologized, said its initial statement “didn’t properly address our mistake,” and blamed a HackerOne triage failure for not escalating the report internally.
None of this is great. But the strongest signal is not the specific bug class. It is the maturity gap the response revealed. Vibe-coding companies keep getting valued like the future of software creation while occasionally behaving like trust and access control are optional cleanup work for later. That phase does not last forever. Either the platforms grow up, or enterprise buyers, regulators, and practitioners force them to.
The market keeps rewarding speed, then acts surprised by the consequences
Lovable is not some tiny hobby project that accidentally wandered into relevance. It is a heavily discussed product in a category that wants users to trust it with prompts, generated code, backend logic, app data, API keys, and increasingly business-critical workflows. When a platform operating at that level still gets tangled in the distinction between “public by design” and “public in a way users clearly did not understand,” the problem is not just one bad endpoint. The problem is a product philosophy that treated permission semantics as a secondary UX detail instead of a core security boundary.
Lovable’s later explanation makes the timeline more revealing, not less. The company said public projects historically exposed both code and chats, that free users gained private-project access in May 2025, that all tiers switched to private-by-default in December 2025, and that an attempt to unify backend permissions in February 2026 accidentally re-enabled chat access for public projects. That sequence reads like a startup growing faster than its authorization model. The defaults moved, the semantics shifted, the implementation changed, and somewhere in that motion the team lost control over what users reasonably thought was private.
When “public” means different things across history, docs, UI, and backend behavior, you do not have a feature. You have an incident waiting for a screenshot.
Why this matters beyond one startup’s ugly Monday
The vibe-coding category has spent the last year selling software creation as something that can be compressed into conversation. That is real progress, but it also changes what the platform is responsible for. Once users are building actual products inside these environments, the platform is no longer a toy prompt playground. It is a multi-tenant development surface holding source code, secrets, user data, and context about how the application behaves. That means the usual boring controls, authorization checks, secret handling, tenant isolation, disclosure process, and clear defaults, stop being nice-to-haves.
Lovable’s incident is a clean example of the category’s current blind spot. The market still lavishes attention on speed of output, valuation marks, and demo quality, while treating trust boundaries as something to clean up after growth. But the practical difference between a fun prototyping tool and infrastructure you can trust with serious work is rarely benchmark performance. It is whether the vendor acts like privacy and access semantics are first-class product features.
This is also why the initial messaging matters so much. Users can tolerate bugs. They are much less tolerant of vendors trying to explain away obvious exposure as a historical behavior mismatch or documentation problem. When the first instinct is to lawyer the definition of breach instead of acknowledging the boundary failure users actually care about, it trains the market to assume every future incident will be handled the same way.
What builders should do before handing these tools real work
If your team is evaluating vibe-coding platforms, stop assessing them like novelty accelerators and start assessing them like SaaS vendors that might end up holding sensitive engineering assets. Ask very plain questions. What is private by default right now, not six months ago? What exactly becomes visible when a project is marked public? Are prompts, chats, code, logs, and attached data governed by the same setting or different ones? Is secret storage separated from project visibility? Can the vendor explain its permission model clearly enough that a security review does not turn into folklore?
Then test the boring stuff. Review API authorization behavior. Check whether tenant boundaries are enforced server-side or merely implied in the UI. Inspect how the tool handles generated secrets, environment variables, and deployment credentials. Read the disclosure policy. Look at whether prior reports were acknowledged quickly and escalated well. A polished landing page is not evidence of operational maturity.
There is also a broader engineering lesson here for companies building in this space. Shipping faster with AI assistance does not exempt anyone from the old disciplines. In fact it raises the bar. The more your product abstracts software creation for non-experts, the more responsibility you take on for the guardrails those users cannot reasonably be expected to build themselves. A vibe-coding tool that makes app creation easy but access control fuzzy is not democratizing software. It is democratizing the production of future incident reports.
The likely winners in this market will not just be the tools that help people ship quickly. They will be the ones that make privacy defaults legible, permission boundaries boringly reliable, and incident response credible when something still goes wrong. That sounds less exciting than autonomous app generation, but it is the difference between a category that becomes infrastructure and one that stays a flashy risk surface for longer than investors would prefer.
Lovable’s leak story is not important because it produced another round of social-media dunking. It matters because it shows the vibe-coding market entering a more adult phase. From here on, the quality of authorization models, defaults, and disclosure handling will matter more than the polish of the demo. Good. That review was overdue.
Sources: The Register, weezerOSINT on X, Lovable on X