24,664 Lovable Apps Were Leaking. No Hack Needed.
German security firm Crissy Field GmbH scanned 159,041 projects built on Lovable — the $6.6 billion vibe-coding platform with eight million users — and found passport numbers, payment details, and more than 200,000 private chat messages sitting in Supabase databases that anyone could read from a browser. No exploit kit. No SQL injection. No hacking of any kind. Just open the site, inspect network calls, and read other people's passport numbers.
📖 Read the full version with charts and embedded sources on AgentConn →
The story hit Hacker News at #1 with 700+ points and 295 comments. On the same day, OpenAI's codex-security CLI crossed 13,500 GitHub stars (+599/day) and Alibaba's open-code-review hit 51,000 stars (+897/day). The irony is precise: AI security tools are surging because AI code generators created the mess they're cleaning up.
This is not a story about one platform having a bad week. It's the story of what happens when the entire code-to-deploy pipeline drops the step that asks "is this safe?"
View the full discussion on Hacker News →
What Crissy Field Actually Found
The research, published in partnership with Handelsblatt, examined Lovable projects crawled between December 2025 and September 2026. Of 159,041 projects identified, 34,545 used Supabase as their database. The findings:
- 24,664 websites sent database records to the browser on page load, without any login or interaction
- 7,403 of those contained email addresses readable by anyone
- More than 1,000 identity records at a single service provider included passport numbers, expiry dates, and nationalities
- More than 200,000 chat messages at a German lifestyle forum were accessible, alongside 80,000+ user profiles with names, emails, birth dates, and gender
- 280,000 customer emails were readable at another provider
Read the full Crissy Field research report →
The methodology is worth noting: the researchers only checked what a browser received without authentication. They didn't attempt to enumerate or download complete datasets. The real exposure is likely worse.
The core failure is Row Level Security (RLS). Supabase databases have RLS disabled by default. Every Lovable-generated app that didn't explicitly enable RLS — which requires understanding what RLS is and writing policies for it — shipped with its entire database readable by any visitor. The AI code generator never asked "should this data be public?" because it was never trained to ask.
The Pattern: Three Incidents in Nine Months
This isn't Lovable's first security incident. It's the third documented one in 2026, and each reveals a different failure mode:
February 2026 — The Showcase App. Security researcher Taimur Khan found 16 vulnerabilities in an EdTech app that Lovable itself showcased on its platform. Six were critical. 18,697 user records — including 4,538 student accounts from top U.S. universities — were exposed. Khan's support ticket was closed without a response.
View the HN thread on the February incident →
April 2026 — The "Intentional Behavior" Incident. A researcher discovered that a free Lovable account could access other users' project source code and AI chat histories. Lovable's initial response: "We did not suffer a data breach" and the exposure was "intentional behavior." They later admitted that a February backend migration had re-exposed every project created before November 2025, and that chat histories containing API keys and credentials had been publicly accessible for 48 days.
November 2026 — The Crissy Field Report. The passport and chat message exposure described above. This time, the failure is in the generated apps themselves, not Lovable's infrastructure.
Each incident has a different proximate cause. But the root cause is the same: no security gate between code generation and deployment.
Why This Keeps Happening
The conventional explanation is that AI models generate insecure code because they're trained on insecure code. That's true but insufficient. The deeper problem is architectural.
Traditional development has a "security surface" that developers learn to see: authentication checks, input validation, database permissions, API rate limits. Experienced developers don't write secure code by default — they write it because they've been burned, reviewed, and audited into recognizing the surface.
Vibe coding removes every checkpoint where that recognition would activate:
- No code review. The developer doesn't read the generated code, so they can't see missing access controls.
- No deployment checklist. One click goes from "it works in preview" to "it's live on the internet."
- No security context in the prompt. Users ask "build me a social app with profiles and chat" — not "build me a social app with profiles, chat, row-level security, input sanitization, CSRF protection, and rate limiting."
- No feedback loop. Traditional developers learn from penetration tests, incident reports, and code reviews. Vibe coders learn that their app works, and nothing else.
As OX Security reported, 62% of AI-generated code ships with design flaws or known vulnerabilities. The Cloud Security Alliance tracked 74 AI-linked CVEs through March 2026 alone, with a 6x month-over-month increase. Georgia Tech researchers estimate the real number is 5-10x higher because most AI-generated flaws never receive CVE numbers.
Theo (t3.gg) has been sounding this alarm for months: AI's growing ability to find vulnerabilities means the exploit window is collapsing. In his follow-up "AI Is Hacking Everything Now", he makes the point that an AI agent with a token budget can now find exploits in real software — the same software that vibe-coded apps are shipping without review.
The convergence is devastating: AI makes it easier to generate vulnerable code AND easier to exploit it.
Contrarian corner: Lovable says users own their security. And technically, they're right — Lovable's terms place data-handling responsibility on customers. But this argument self-destructs. Lovable's entire pitch is that non-technical users can build production apps without technical knowledge. You cannot sell "no code needed" and then blame users for not understanding Row Level Security. If your marketing says "build apps without being a developer," your platform has accepted the obligation to not ship those apps with their databases wide open.
The Security Tooling Surge
The timing tells the story. On the same day as the Crissy Field report hitting HN #1:
OpenAI's codex-security (13,500 stars, +599/day) — a TypeScript CLI and SDK for finding, validating, and fixing security vulnerabilities. Originally codenamed Aardvark, launched in research preview in March 2026, and open-sourced in July. The scanning engine itself remains restricted to approved customers, but the CLI framework is Apache-2.0.
View the HN discussion on Codex Security →
Alibaba's open-code-review (51,000 stars, +897/day) — a hybrid code review tool combining deterministic pipelines with LLM agents for line-level security comments. Battle-tested at Alibaba's scale, built in Go, Apache-2.0.
View the HN discussion on Open Code Review →
These tools exist because the market learned something the hard way: AI code generation without AI code review is a liability. We wrote about this convergence when Codex Security positioned itself as an enterprise beachhead — the thesis was that security scanning would be the first agent workflow enterprises pay for without hesitation. The Lovable breach is the proof case.
Other players in this space: GitHub's AI security detections in pull requests (July 2026), CodeRabbit Security, and Endor Labs' AI security review. The Anthropic/Mozilla security partnership announced alongside Codex Security adds another contender. For a deeper look at the audit landscape, see our piece on who audits the agent.
The HN Thread: What Practitioners Are Saying
The Hacker News discussion (295 comments) surfaced perspectives that go beyond the research report.
The top comment nails the structural issue: data breaches predate AI, but "the difference with these AI generated apps is they are an easy target — they don't need any sophisticated hacking knowledge. And there are tons of those, and more created every day."
The Crissy Field researcher showed up in the thread: "I submitted it to HN two weeks ago, but it didn't gain much traction, so I'm glad to see it resubmitted."
And the Railway parallel is critical context: Railway was hit by approximately $740,000 in AI compute charges days before this story broke, from attackers using "abliterated models" (jailbroken LLMs) with stolen keys. If a funded infrastructure company gets hit, vibe-coded Lovable apps with exposed Supabase keys are the definition of low-hanging fruit.
The numbers in context. Lovable's valuation: $6.6 billion. Users: 8 million. ARR: $4M in its first four weeks, $10M within two months. The platform grew this fast because building apps without code is genuinely useful. The problem is not that Lovable exists — it's that the toolchain shipped without the security layer that enterprise software has spent decades building.
What This Means for Teams Using AI Code Generation
This is not a Lovable-specific problem. Every AI code generator — Lovable, Bolt, Replit, Cursor-powered prototypes, Claude-generated starter projects — shares the same structural vulnerability: the model optimizes for functionality, not security. The fix is a mandatory security gate between generation and deployment.
Three gates every team should implement today
Gate 1: Enable security defaults at the infrastructure level. If you're using Supabase, enable RLS on every table before writing a single row. If you're using Firebase, configure security rules before deploying. Don't rely on the AI to do this — it won't unless you explicitly ask, and even then it may hallucinate the policies.
Gate 2: Run automated security scanning before every deploy. codex-security in your CI pipeline, open-code-review on your PRs, or at minimum a static analysis pass. The AI wrote the code — let another AI review it. We covered the broader security review skills landscape and how to integrate scanning into your agent harness guardrail stack.
Gate 3: Assume the database is public until proven otherwise. Run SELECT * FROM information_schema.tables against your production database from an unauthenticated context. If anything comes back, you have an exposure. This takes 30 seconds and would have caught the Lovable problem before a single user signed up.
The minimum viable security prompt. When using any AI code generator, append this to your prompt: "Enable Row Level Security on all database tables. Require authentication for all API endpoints. Never expose database credentials in client-side code. Add rate limiting to all public endpoints. Sanitize all user input." It won't catch everything, but it shifts the default from "wide open" to "minimally locked down."
What Comes Next
The vibe-coding security crisis is not going away. Gartner projects that 60% of new code will be AI-generated by end of 2026. Enterprise adoption of AI code tools is up 340% year-over-year. Non-technical users of AI code platforms are up 520%.
Every one of those numbers is a multiplier on the security surface. The question is whether the security tooling layer — codex-security, open-code-review, CodeRabbit, Endor Labs, and whatever emerges next — can scale fast enough to match it.
The Lovable breach is the first incident large enough to change behavior. Whether it actually does depends on what the platforms do next. Lovable has launched automated penetration testing for apps built on its platform — the right direction, but after three public incidents, the burden of proof is on them.
The lesson for everyone else: if you're shipping AI-generated code to production, you need a security gate. Not a checkbox, not a "we'll get to it later," not "the terms say users are responsible." An automated, mandatory gate that runs before every deploy. The tools exist. The excuses don't.
This story emerged from today's convergence of three independent signals: HN's #1 story on the Crissy Field research, Theo's ongoing security coverage on t3.gg, and the simultaneous surge of codex-security and open-code-review on GitHub Trending. When the developer forum, creator layer, and tooling layer all point at the same problem on the same day, it's not a coincidence — it's a phase change.
Related reading:
- OpenAI's Codex Security: The Enterprise Beachhead
- Config Files That Run Code: The Agent Skill Supply Chain
- How to Sandbox Untrusted Agent Code
- Who Audits the Agent? Security Review Skills
Originally published at AgentConn
Top comments (0)