A One-Day Disclosure Cycle Is Itself a Test Result
A vendor's first day after a vulnerability disclosure is a security control, and last week Lovable failed that control in front of every procurement team watching. The $6.6B vibe-coding platform shipped a Broken Object Level Authorization (BOLA) flaw that left source code, database credentials, AI chat histories, and customer data from pre-November-2025 projects readable to anyone with a free Lovable account, including projects belonging to Uber, Zendesk, and Deutsche Telekom. The exposure ran 76 days, from February 3 to April 20. The fix is straightforward to write up; the disclosure handling is what procurement should be scoring.
Start with the bug. BOLA is the simplest class of authorization failure: the API confirms who you are but never confirms whether the object you asked for belongs to you, so any logged-in user can read any other user's data by changing the ID in the request. It is OWASP API Security Top 10's number-one risk because it is both common and trivial to exploit. In Lovable's case, five API calls from a free account were enough.
Now look at the disclosure cycle. On April 20, 2026, Lovable's response cycled through three official positions in a single day. The first was a flat denial: "To be clear: We did not suffer a data breach." The second narrowed the failure to a documentation problem: "Our documentation of what 'public' implies was unclear, and that's a failure on us." The third, posted hours later, conceded that the first response "didn't properly address [the] mistake," per Sifted's reporting that day. Two days later, Lovable's own incident writeup retracted the documentation framing entirely, admitting the company "hadn't built the product safeguards, the communication muscle, or the security processes to match the trust our users placed in us." That is the security control failing in real time, not after the fact. The harder thing to write about, and the thing procurement teams should actually care about, is the disclosure cycle itself. A vendor's first 24 hours after disclosure is a security control, and Lovable's first 24 hours produced three contradictory stories.
The Diligence Stack Bought Everything Except the Thing That Failed
Here is what Lovable already had, on paper, when the BOLA was reachable for 76 days: SOC 2 Type II issued August 13, 2025, ISO 27001:2022, a dedicated CISO, an active HackerOne program, and a 24/7 incident response team. That stack covers nearly every diligence checkbox a security or procurement team would ask a Series B vendor to fill in, and Lovable is post-Series-B: CapitalG and Menlo led a $330M round at $6.6B in December, with NVentures, Salesforce Ventures, Databricks Ventures, and Deutsche Telekom's T.Capital on the cap table.
None of that stack caught the failure. The first HackerOne report was filed February 22, 2026, and "closed instead of being escalated to Lovable because of outdated internal documentation," per Lovable's own admission. The CISO did not catch it. The 24/7 IR team did not catch it. SOC 2 Type II controls CC6.1, CC6.6, CC7.1, and CC9.2 were ostensibly in scope; Bastion's analysis traces how they were bypassed by the same regression that reintroduced the vulnerability. Anton Osika himself told Sifted the company first learned about the problem via social media, because its vulnerability disclosure process had "broken". The disclosure pipeline was not a backstop; it was the gap.
This is the same compounding pattern I traced in the broken shared-responsibility model for AI tools entering enterprise environments: the certifications attest that controls were documented and followed across an audit window, not that the product is secure today. What Stackademic calls "Control Drift" is the gap between the audit window and the production system on the day a researcher hits an endpoint. SOC 2 cannot close that gap, and procurement diligence built around SOC 2 cannot either. Lovable is also not a one-off: Wiz researchers found PromptBase, a vibe-coded site whose founder said he "didn't write one line of code," shipped with a misconfigured database exposing roughly 1.5M tokens, which is the same authorization-class failure at a different vendor.
The Third Missing Row
The procurement row that would have caught Lovable does not exist on standard vendor questionnaires, and it is the third row I have argued is missing in eighteen months of AI-vendor incidents. The first was the privileged-identity row, which Vercel's Context.ai breach exposed when a fourth-party AI tool with OAuth scope into a customer's repo data ended up listed for $2M on a leak site. The second was the data-custodian row, which Mercor's 4TB breach exposed when a vendor procured as a labor marketplace turned out to be holding training data the AI labs had treated as throwaway. Lovable's incident exposes the third: vendor disclosure maturity, the measurable behavior of a vendor in the first hours and days after a credible external report.
It is a measurable dimension with sub-criteria a buyer can score:
- First-response time and framing. How long between a credible external report and the vendor's first public acknowledgment, and does the first acknowledgment narrow the scope or accept it? Lovable's first acknowledgment narrowed the platform issue to "documentation," which is a measurable signal of disclosure immaturity. The same signal showed up when OpenAI and Anthropic each declined to patch a CVSS 7.5 agent-config vulnerability within their five-day windows; the response posture is the disclosure.
- Bug bounty triage configuration. Is HackerOne (or equivalent) wired to current internal documentation, with verifiable escalation paths? Lovable's program closed the report at intake because routing pointed at stale internal docs. A bug bounty program is not a positive signal on its own; the Lilli breach at McKinsey started through a publicly disclosed HackerOne program that an autonomous agent picked precisely because it existed. Procurement needs to score what the program actually does, not whether it exists.
- Regression-test discipline for security fixes. When a vulnerability is patched, does the patch ship with a regression test that fails if the fix is undone? Lovable's March 2025 fix was undone by a February 2026 backend unification, and no regression test caught the reintroduction across two months of production.
- Customer notification timeline. What is the contractual SLA between vendor knowledge and affected-customer notification, and does the vendor publish a developer-facing changelog for security-relevant platform changes? A developer commenting under Osika's apology asked for exactly this: notification when platform-level permission semantics change. The absence of that channel is why Uber, Zendesk, and Deutsche Telekom learned from a researcher's X post that their data had been reachable for 76 days.
- Disclosure history as a leading indicator. This is Lovable's third major security incident in 13 months, following CVE-2025-48757 and a February 2026 university records breach affecting 18,697 records at UC Berkeley and UC Davis. A vendor with three platform-level incidents in 13 months is a different risk profile than a vendor with zero, and standard diligence does not weight that history.
The reason this row is not on questionnaires is that it cannot be self-attested. SOC 2 is self-attested through an auditor; ISO 27001 is self-attested through a certification body; a HackerOne program is self-attested by existing. Vendor disclosure maturity is only legible from the outside, in the vendor's actual handling of actual incidents, which is why it has to be reconstructed from public timelines rather than answered on a form.
The Eleven-Month Warning
Vibe coding tools are entering procurement pipelines at the pace of the broader AI software repricing I covered earlier this year: demo velocity, not deployment maturity. Lovable's user base reached roughly 8 million by November 2025 with $200M ARR and 100,000+ new projects daily, and the customer logos include Klarna, Uber, and Zendesk. The procurement signal on a vendor at that scale is not the certification stack; it is the disclosure history.
That signal was readable eleven months before the April 2026 exposure. In April 2025, Anton Osika told the press that Lovable apps were "pretty much guaranteed to be secure." The same Semafor reporting documented that a Replit employee had already found a Lovable-built app exposing roughly 500 user emails the previous month, and that Lovable's scanning feature only verified whether Supabase access controls were enabled, not whether they were properly configured. Eleven months later, the same posture, in compressed form, produced the 76-day window and the one-day cycle of denial, deflection, and apology.
What I Would Ask a Vendor This Week
Procurement teams already ask for SOC 2 reports and pen-test summaries. The single question I would add to the next vendor security review, anchored to this incident: walk me through your last three external vulnerability reports, including the time from researcher contact to internal escalation, the time from escalation to customer notification, and the regression test that ships with each fix. A vendor that can answer that question in concrete numbers has built the disclosure muscle. A vendor that cannot is selling the certification stack Lovable already had on April 19.
