Lovable BOLA: 48 Days, Five API Calls, Source Code + Database Credentials of Other People's Projects

TL;DR

Lovable's backend authorized read access to project objects by ID without checking the requesting user's relationship to the object. Any free-tier account, with five API calls, could enumerate other users' project IDs and pull source code, Supabase database credentials, and AI conversation history — including prompts that may have contained business logic and PII. The vulnerability was reported via HackerOne on March 3, 2026, marked as a duplicate by Lovable's HackerOne triagers, and left open for 48 days before @weezerOSINT publicly demonstrated the API path on April 20. Lovable's eventual fix applies only to projects created after November 2025; the historical project corpus remains exposed unless individual project owners rotated credentials. If your project predates November 2025 and you stored database credentials or API keys in it, rotate them today.

What Happened

Lovable is an AI-driven app builder targeting non-developer founders — a representative "vibe coding" platform where prompts produce running software, source files, and provisioned backend resources (typically Supabase). The platform stores per-project artifacts in a backend object model: each project has a numeric ID, an owner, source code, environment variables (which include credentials for the Supabase project Lovable provisioned for the user), and the full transcript of the conversation between the user and the AI builder.

The vulnerability is canonical OWASP API Security API1:2023 Broken Object Level Authorization (BOLA). The backend's project-fetch endpoint accepted an object ID, looked up the project, and returned the full record — without verifying that the calling account held a relationship (owner, collaborator, or admin) to that object. Authentication was required (a free-tier account is an account), but authorization was not enforced at the object boundary.

The exploitation cost was negligible: a researcher demonstrated five API calls from a free Lovable account were sufficient to dump another user's project source, Supabase credentials, and AI chat history. Project IDs are sequential integers; enumeration is a for-loop.

Why This Bug Class Matters Beyond Lovable

BOLA is the most-reported API vulnerability class globally for a reason: it's the natural failure mode of REST API design. The pattern is so common that OWASP elevated it to API1 in the 2023 list, replacing what was previously "Broken Object Level Authorization" at #1 in the 2019 list — same name, same rank, because nothing structural has changed.

What makes the Lovable variant interesting is the composition with vibe coding:

• The user's source code is the asset. Most BOLA exploits leak metadata or PII; Lovable's leaked source code lets an attacker read the user's business logic directly.
• Database credentials in plaintext. Lovable stored Supabase project credentials inside the project object the BOLA endpoint returned. Rotating Supabase credentials means re-deploying the app — a step that vibe-coding users are unlikely to perform proactively.
• AI chat transcripts as PII. Users debug their apps in conversation with the AI. Those conversations contain real customer data, real schemas, real business descriptions. Leaking the transcript is leaking the design notes and the data the user pasted while debugging.
• Enterprise users in personal accounts. Public reporting identified employees of Nvidia, Microsoft, Uber, and Spotify with personal Lovable accounts tied to affected projects. The data those projects touched may have included corporate IP they were prototyping.

The Disclosure Timeline (And Why It's a Story)

The 48-day silence between disclosure and patch is the operational story. A duplicate-marked HackerOne report is a triage failure, not a fix. The structural lesson for vibe-coding platforms: the bug bounty program is not a substitute for an SLA on response, and the press cycle is the implicit escalation path.

What Was Exposed

Per public reporting and the @weezerOSINT demonstration, a successful BOLA call returned per-project:

• Source code — the entire generated codebase, including any user-edited files.
• Supabase database credentials — typically full service-role keys, granting read/write/delete on every table in the project's database. (Connected Women in AI, a nonprofit, was named publicly as one affected project; their Supabase contained real user records.)
• AI chat transcripts — the complete history of the prompts a user typed and the AI's responses, including pasted code snippets, schemas, and customer data fragments.
• Environment variables — third-party API keys (OpenAI, Anthropic, Stripe, etc.) the user stored for their app's runtime.
• Build artifacts — preview deployment URLs, asset paths, and config files.

Detection (For Lovable Project Owners)

1. Has your data been touched?

The relevant question for project owners is whether your Supabase credentials were used by anyone other than your own application during the exposure window. Supabase logs every database query at the project level. To audit:

1. Open your Supabase project dashboard.
2. Navigate to Logs > Database (or API logs).
3. Filter to the November 2025 – April 2026 window.
4. Group by source IP. Your application's deployment IP should be the dominant source. Anything else, especially residential ISPs or datacenter ASNs that don't match your deployment, is suspicious.
5. Pivot suspicious IPs into per-table query patterns. SELECT * FROM users from an unknown IP is the signal.

2. AI chat history scan

Open your Lovable project and scroll through the AI chat history. Look for moments where you pasted real customer data, real database schemas, or live credentials "just to debug." Those moments are now part of your threat model — the data was readable to anyone who pulled the project record.

3. Third-party API key forensics

For each external API key stored in your Lovable project's environment variables, check the provider's audit logs:

• OpenAI / Anthropic: usage by API key, look for spikes during the exposure window.
• Stripe: request log, filter by key, look for unfamiliar source countries.
• SendGrid / Twilio / etc.: message logs, look for unauthorized sends.

Mitigation

1. Rotate Supabase credentials immediately if your project predates November 2025. In Supabase: Project Settings > API > Reset. Update the new keys in your Lovable project's environment variables and redeploy.
2. Rotate every third-party API key stored in environment variables for affected projects. Treat the old keys as burned.
3. Audit your AI chat history for any pasted credentials or live data. Delete sensitive transcripts where the platform allows.
4. Re-key your application's auth if the Supabase JWT secret was exposed (it ships in the project's env vars). Sessions for existing users will invalidate; this is the cost of cleanup.
5. Move sensitive projects off shared vibe-coding platforms. Where the project handles real customer data or real revenue, the cost of an incident outweighs the velocity gain.

Lessons for Other Vibe-Coding Platforms

The Lovable failure is not unique to Lovable. Every platform offering AI-generated apps with platform-managed backends faces the same risks:

• Object-level authorization at every API endpoint, not just the user's own pages. Every GET /api/project/:id needs to check that the requester is an owner or collaborator of that project.
• Don't store credentials in user-readable project objects. If a user's app needs database credentials at runtime, inject them through a separate secret-store service that requires additional authentication.
• Treat AI chat transcripts as PII at rest. Encrypt them, log access, and let users delete them.
• Have a triage SLA on bug bounty reports. 48 days from a HackerOne disclosure to a public demonstration is the worst possible outcome for both the platform and its users.
• Notify users. A patch for new projects without notification to existing users guarantees the historical exposure persists.

Frequently Asked Questions

Is my project affected?

If your Lovable project was created before November 2025, the public reporting indicates it was in scope of the BOLA endpoint until at least April 22, 2026. Project ID, owner mapping, and the ease of enumeration mean assume affected and rotate credentials.

Did Lovable notify users?

Public reporting at the time of this writing indicates Lovable patched the endpoint for new projects but did not centrally notify owners of pre-November-2025 projects. Diego's recommendation: assume you weren't notified, audit yourself.

Are my AI chat transcripts permanently leaked?

Once exposed, you cannot un-expose. The realistic question is whether anyone other than the public researcher pulled the data during the exposure window. Without Lovable's own access logs published to affected users, you cannot prove negative. Treat sensitive content in those transcripts as potentially read by an attacker.

What about Lovable competitors?

The same BOLA risk applies to any AI app builder where projects are stored in a multi-tenant backend with object-id-based access patterns. Bolt, Replit AI, v0.dev, Tempo Labs, and similar platforms each have their own architecture; the question for users is whether their authorization model checks the requester's relationship to every requested object. The safest assumption: if the platform doesn't publicly document its authorization model, it's worth manual testing on your own project (try fetching project IDs you don't own).

Is this a CVE?

BOLA bugs in proprietary SaaS APIs typically don't get CVE numbers because CVEs are for distributable software with versions. The fix lives on Lovable's servers; there's nothing for users to patch on their end. The mitigations above are the user's responsibility.

Key Takeaways

• Five API calls. Free account. Source code + Supabase credentials of any pre-November-2025 Lovable project.
• The bug class is OWASP API1 (BOLA) — boring, well-known, devastating in this composition.
• The HackerOne report was filed March 3 and marked duplicate. Public demo on April 20 forced the patch on April 22. 48 days is the failure mode worth studying.
• If your project predates November 2025: rotate Supabase keys, rotate third-party API keys, audit chat transcripts.
• The vibe-coding category needs platform-side authorization audits as table-stakes infrastructure, not an afterthought.

Sable Offensive Research conducts authorized API security assessments against multi-tenant platforms: BOLA / OWASP API Top 10 testing, authorization-model reviews, and post-disclosure incident response for vibe-coding-stack incidents. Contact us if you operate or build on a vibe-coding platform and want a focused review of object-level authorization.

References

• HackerOne disclosure (March 3, 2026, marked duplicate)
• @weezerOSINT public demonstration on X (April 20, 2026)
• Cybersecurity News: Lovable AI App Builder API flaw exposes thousands of projects
• Computing.co.uk: Lovable flaw exposed source code, credentials and AI chats
• Halborn: Lovable Data Leak — BOLA Vulnerability and App Security Risks
• The Next Web: Lovable security crisis — 48 days of exposed projects
• OWASP API Security Top 10 (2023): API1 Broken Object Level Authorization