Lovable apps expose passport details and more than 200K private messages

Swedish AI startup Lovable, founded by Anton Osika and Fabian Hedin, built an AI platform turning natural-language prompts into web applications, but an independent security audit has exposed widespread vulnerabilities across deployed software. An investigation detailed in crissyfield.de's report examined 159,041 Lovable projects and revealed that thousands of live deployments left sensitive personal data and backend databases exposed to the public internet without authentication.

This report details the specific security weaknesses identified across Lovable applications, the volume and classification of exposed customer records, and the structural risks inherent in automated database deployments. Software engineers, platform architects, and non-technical founders operating AI-generated applications will find critical operational takeaways regarding Supabase access controls, configuration responsibilities, and necessary verification protocols.

01Natural language prompts and developer responsibility

Lovable was established in Stockholm in 2023 by Anton Osika and Fabian Hedin following Osika’s open-source GPT Engineer project. The tool evolved into the GPT Engineer App before rebranding as Lovable in late 2024 and launching publicly that November. The service generates full-stack web applications featuring user management and database connections directly from plain-language conversational inputs.

Lovable’s commercial marketing highlights that non-technical creators can build sophisticated web applications without programming expertise. This positioning frequently leads non-technical founders to assume the platform automatically implements security and access controls across all system layers. In reality, Lovable’s legal terms and conditions place the entire burden of data security and application compliance onto the platform's customers.

This operational gap between simplified application assembly and downstream security responsibility created vulnerabilities across thousands of public projects. Security researchers partnered with business publication Handelsblatt to investigate how effectively Lovable applications safeguarded sensitive records in production environments. Journalist Lina Knees documented initial findings in November 2026, establishing that accessible databases remained common across active projects.

02Analysis of thirty-four thousand Supabase databases

Security analysts utilized public web archives from Common Crawl to examine 159,041 Lovable web projects active between December 2025 and September 2026. The technical assessment concentrated primarily on projects integrating the third-party database provider Supabase, which remains the dominant storage backend across the platform's ecosystem. Analysts noted Lovable introduced native database functionality in late 2025, though adoption remained secondary.

Of the 159,041 projects cataloged in the web archive sample, 34,545 deployments utilized Supabase infrastructure for persistent storage. Analysts identified 24,664 websites that transmitted database records immediately upon page initialization without demanding user authentication. While displaying public records on page load is standard web behavior, the client configuration permitted unrestricted exploration of adjacent backend data tables.

Researchers issued additional read-only queries against the exposed endpoints using identical public API credentials embedded in the client scripts. This secondary inspection revealed unprotected email records across 10,560 distinct database tables spanning 7,403 individual websites. That tally represented 30 percent of the 24,664 websites examined, demonstrating recurring failures to enforce basic backend read restrictions.

03Leaked passport records and private conversations

The unsecured databases contained severe leaks of sensitive personal and corporate information across multiple consumer-facing sectors. A German lifestyle forum exposed more than 80,000 personal user profiles detailing real names, email addresses, dates of birth, and gender markers. The same application left more than 200,000 private chat conversations accessible to unauthenticated read requests.

In one critical security breach, an operational service provider left more than 1,000 official identity documents completely open to inspection. The exposed records included valid passport numbers, document expiration dates, and citizens' nationalities, creating acute vulnerability to identity theft. Another project exposed 280,000 email messages previously transmitted by a business provider directly to its customers.

Additional exposed datasets included tens of thousands of event tickets and restaurant order receipts containing payment details, postal addresses, phone numbers, and barcode codes. Property managers exposed artificial intelligence email summaries revealing confidential tenant negotiations, contracts, and invoices. Thousands of private photo albums and internal WhatsApp message threads were similarly exposed without required login credentials.

04Shared patterns in unauthenticated database integrations

The widespread exposure stems directly from repetitive configuration templates generated across Lovable projects. Because the automated coding tool follows uniform integration routines when connecting client code to Supabase instances, security gaps repeat predictably across different domains. Attackers who construct a query against one Lovable deployment can execute identical extraction scripts against thousands of other applications.

Automated code generation removes technical barriers to shipping applications but prevents non-technical operators from spotting missing Row Level Security policies. Creators without programming backgrounds often fail to recognize that a frontend client API key should never possess unrestricted table permissions. Consequently, default Supabase configurations that permit unauthenticated read queries remain unnoticed and unaltered throughout production lifecycles.

Analysts acknowledged several structural caveats regarding the research data. Email addresses can include public corporate contact addresses or developer test data, while records without email strings were excluded from initial scans. Because researchers sampled Common Crawl archives rather than querying all live Lovable infrastructure, the raw figures represent lower bounds rather than total damages.

05Mandatory security reviews for production applications

The research team shared its analytical findings with Handelsblatt, which subsequently approached Lovable's management regarding the security failures. While researchers verified that exposed datasets allowed unauthorized extraction, they could not confirm whether malicious actors had exploited the records in the wild. The incident demonstrates that convenience in software generation cannot supersede baseline security architecture.

Automated platform safeguards and synthetic code generation do not replace independent human assessments of database access rules. Every application handling customer or business records requires explicit testing of backend permissions, user separation, and API boundaries. Teams must verify that database engines enforce authentication policies rather than relying on frontend obscurity to shield confidential data tables.

Organizations deploying AI-generated software must conduct structured access control audits before exposing systems to public traffic. Any significant change to application schemas, user roles, or data storage configurations requires immediate re-verification. When engineering teams lack in-house security expertise to audit database access policies, qualified external security specialists must review the production environment.