A security audit of the vibe-coding platform Lovable has found a hole you can drive a database through: 7,403 public apps built with the tool left customer records readable on the open internet, without any login, including passport and payment records. The finding comes from Nightingale Security's audit of 159,041 Lovable apps, reported by 404 Media on November 3, 2026, and it turns the most popular metaphor of the AI-coding era on its head. If you can describe an app in a sentence, you can build it in an afternoon. It turns out you can also ship it with the customer database unlocked, and no one will warn you.
The funnel, in numbers
The audit's numbers deserve a slow read, because the headline figure is the end of a funnel, not a single test. Nightingale Security scanned 159,041 Lovable apps, the company's full public corpus, and identified 7,403 that had email records readable without authentication. That is about 4.7 percent of all apps scanned, and it is the subset that matters most, because an email address is often the key that unlocks password resets and account recovery on other services. The researchers then examined a closer sample of 30 sites in detail and found that 9 of them, 30 percent, had email records readable without a login, while 21, or 70 percent, did not. That closer sample is where the most sensitive findings sit: among the sites examined in detail, records included passport information and payment data, alongside contact details.
| Stage | Count | Share |
|---|---|---|
| Apps scanned | 159,041 | 100 percent |
| Apps with email records readable without a login | 7,403 | About 4.7 percent |
| Closer sample examined in detail | 30 sites | — |
| Closer sample with email records readable without a login | 9 sites | 30 percent |
| Closer sample without that flaw | 21 sites | 70 percent |
The most important correction to any shorthand version of this story is about what was actually exposed and how. The audit did not claim that every Lovable app is vulnerable, that 159,041 databases were open, or that attackers downloaded all the data. It found a specific configuration failure repeated at scale: database tables that should have required authentication were readable by anyone who knew where to look, because the app's access rules were left open. That distinction matters for both blame and repair. A single misconfigured app is a bug. Seven thousand misconfigured apps are a defaults problem, a documentation problem, and a review problem all at once.
Why a public key is not a lock
The technical root, as described in the reporting, is Lovable's use of Supabase, a popular backend service that gives each app a public, anonymous key for its database. That key is designed to be embedded in the app, so on its own it is not a secret and not a vulnerability. The lock is supposed to be Row Level Security, the set of rules that say which rows a given user, or an anonymous visitor, may read. If those rules are not written, or are written to allow all reads, then the public key plus the table name is enough to fetch the data, and no login is required. Lovable's own guidance warns builders about exactly this, but the audit shows that warning did not reach, or did not stick with, thousands of builders who had no reason to know what Row Level Security was.
That framing also clarifies why the usual instinct, rotate the key, does not fix it. Rotating a public key that was never secret does nothing if the access rules still say anyone may read the table. The fix is to write and test those rules, and to default them to deny, so a builder who never touches the database panel ships a closed app rather than an open one. Platforms that let a novice ship a production database with public reads enabled have made the dangerous option the default option, and the audit is the predictable result. Lovable told 404 Media it has notified affected users and worked to secure the exposed data, and the company says it is strengthening its defaults and guidance, but the audit's scale suggests the notification problem alone is large: thousands of builders, many of them non-technical, must now understand that their customer data was public, and act on it.
Who is responsible, and the check that catches it
Responsibility here is shared, but not equally. The builder who collected passport or payment data without understanding the database rules bears responsibility for the data they chose to collect, especially if they collected sensitive data they did not need. The platform bears the larger structural responsibility, because it chose the defaults, wrote the onboarding, and decided what a first-time builder sees before their app goes live. A platform that can generate a full app from a sentence can also run a pre-publish check that asks, in plain language, whether anonymous visitors should be able to read this table, and block publication until the answer is no for any table holding personal data. That check is not exotic. It is a query against the app's own access rules, and it would have caught the exact failure in this audit before a single record was exposed.
For anyone who built with Lovable, or any vibe-coding tool, the practical step is the same: open your database panel, check every table that holds personal data, and confirm that anonymous reads are denied, then test it from a logged-out browser before you assume it is closed. For anyone whose data was in one of these apps, the practical step is less comforting: assume the record was public, watch for account-recovery attempts, and treat any email address in the set as compromised for reset purposes. The era of describing an app into existence has arrived. The era of securing it by default has not, and until platforms make the secure choice the automatic choice, audits like this one will keep finding the same open door, at larger scale, with more sensitive data behind it.
By ByteHerald Staff. Nightingale Security, audit of 159,041 Lovable apps, reported by 404 Media, November 3, 2026, finding 7,403 apps with email records readable without authentication, and, in a closer sample of 30 sites, 9 sites, 30 percent, with email records readable without a login and 21 sites, 70 percent, without that flaw, with passport and payment records among the sensitive data found. Lovable, via 404 Media, November 3, 2026, stated it has notified affected users, worked to secure the exposed data, and is strengthening its defaults and guidance.
Comments
Post a Comment