Two distinct Lovable-related security stories became public this week, close enough together that I've already seen them getting blurred into one another in casual conversation. Worth being precise, because they're genuinely different failures with different lessons attached.
Incident one: chat history and source code exposed to any authenticated user
Earlier this week, a flaw came to light that exposed a public project's chat history and source code to any authenticated user, not just the project's own owner or collaborators. By Lovable's own account, this was patched within about two hours of being discovered. That's a genuinely fast response, and it's worth acknowledging as such: two hours from discovery to fix is close to the best-case outcome for an active vulnerability once it's found.
Incident two: a permission flaw reported 48 days ago, still unpatched for older projects
Separately, a broken object-level authorization flaw in Lovable's API, originally reported back on March 3rd, also became public this week, roughly 48 days after it was first flagged. By the account making it public, the flaw remains unpatched for any project created before November 2025 at the time of this disclosure. That's a very different timeline than the first incident: not a fast in-and-out fix, but a known issue that sat unresolved for a meaningful stretch before becoming public knowledge.
Why I think it matters to keep these separate
Lumped together, these read as one vague story: "Lovable had security problems this week." Kept separate, they tell two very different stories about how a platform handles risk. A newly discovered, actively exploitable bug fixed in two hours is a genuinely good incident-response outcome, whatever caused the original bug. A known, previously reported flaw sitting unpatched for 48 days, still affecting a defined set of older projects at the time of disclosure, is a different kind of problem entirely, one about prioritization and backlog, not response speed.
What this means if you have an older Lovable project specifically
If your project predates November 2025, the second issue is the one worth taking seriously right now, given the account that it remains unpatched for exactly that population of projects as of this week. Don't assume the fast two-hour fix on the first incident means everything's been addressed. These are separate bugs, on separate timelines, and only one of them has a confirmed resolution as of today.
The broader lesson, again
A fast fix on a newly found bug and a slow fix on an already-known one can happen at the same company, in the same week, for different reasons entirely. Speed of response says something real about incident handling. It says nothing about whether every previously reported issue has actually been addressed. If you're relying on any platform's security track record, both numbers matter, and they don't always move together.