[{"data":1,"prerenderedAt":397},["ShallowReactive",2],{"blog-stories/lovable-app-exposed-18000-users":3},{"id":4,"title":5,"body":6,"category":366,"date":367,"dateModified":367,"description":368,"draft":369,"extension":370,"faq":371,"featured":380,"headerVariant":366,"image":381,"keywords":381,"meta":382,"navigation":380,"ogDescription":383,"ogTitle":381,"path":384,"readTime":385,"schemaOrg":386,"schemaType":387,"seo":388,"sitemap":389,"stem":390,"tags":391,"twitterCard":395,"__hash__":396},"blog/blog/stories/lovable-app-exposed-18000-users.md","How a Lovable App Exposed 18,000 Users, Including Students",{"type":7,"value":8,"toc":351},"minimark",[9,16,21,24,27,34,37,41,44,47,50,60,66,69,73,76,96,99,133,136,140,143,146,149,155,164,168,171,174,200,203,208,211,214,217,221,224,227,236,239,244,248,251,284,287,315,339],[10,11,12],"tldr",{},[13,14,15],"p",{},"A researcher found 16 vulnerabilities, six critical, in a single Lovable-hosted app featured on Lovable's Discover page. The AI-generated authentication logic was literally backwards: it blocked logged-in users and granted access to anonymous visitors. 18,697 user records were exposed, including 4,538 student accounts from K-12 schools and universities like UC Berkeley and UC Davis. The app had over 100,000 views. Lovable initially closed the security report without responding.",[17,18,20],"h2",{"id":19},"what-happened","What Happened",[13,22,23],{},"On February 27, 2026, The Register published findings from security researcher Taimur Khan, who discovered that a popular app hosted on Lovable's vibe-coding platform was riddled with basic security flaws.",[13,25,26],{},"The app, an exam question and grading platform, was featured on Lovable's own Discover page. It had more than 100,000 views and around 400 upvotes. Behind the scenes, it was leaking everything.",[28,29,31],"story-block",{"attribution":30},"Taimur Khan, security researcher",[13,32,33],{},"\"You can't showcase an app to 100,000 people, host it on your own infrastructure, and then close the ticket when someone tells you it's leaking user data.\"",[13,35,36],{},"Khan found 16 distinct vulnerabilities. Six were critical. The root cause was the same thing we keep seeing: a Supabase backend with missing security controls and AI-generated code that looks functional but isn't.",[17,38,40],{"id":39},"the-authentication-was-literally-backwards","The Authentication Was Literally Backwards",[13,42,43],{},"Here's the detail that makes this one stand out.",[13,45,46],{},"The AI that generated the Supabase backend implemented access control using remote procedure calls. The intent was to block non-admin users from sensitive parts of the app. Simple enough.",[13,48,49],{},"But the AI inverted the logic. Instead of blocking unauthenticated users, it blocked authenticated ones. If you were logged in, you were locked out. If you were an anonymous visitor, you got full access.",[51,52,53],"danger-box",{},[13,54,55,59],{},[56,57,58],"strong",{},"The logic inversion:"," The access control guard blocked the people it should have allowed and allowed the people it should have blocked. This error was repeated across multiple critical functions in the app.",[28,61,63],{"attribution":62},"Taimur Khan",[13,64,65],{},"\"This is backwards. The guard blocks the people it should allow and allows the people it should block. A classic logic inversion that a human security reviewer would catch in seconds, but an AI code generator, optimizing for 'code that works,' produced and deployed to production.\"",[13,67,68],{},"This isn't a subtle misconfiguration. It's the kind of bug that a single code review (or an automated security scan) would have caught immediately.",[17,70,72],{"id":71},"what-was-exposed","What Was Exposed",[13,74,75],{},"Because the app was a platform for creating exam questions and viewing grades, the userbase was teachers and students. Some from top US universities. Some from K-12 schools with minors on the platform.",[77,78,79,84,88,92],"stat-grid",{},[80,81],"stat-card",{"label":82,"number":83},"Total user records exposed","18,697",[80,85],{"label":86,"number":87},"Unique email addresses","14,928",[80,89],{"label":90,"number":91},"Student accounts","4,538",[80,93],{"label":94,"number":95},"Critical vulnerabilities","6",[13,97,98],{},"With the security flaws in place, an unauthenticated attacker could:",[100,101,102,109,115,121,127],"ul",{},[103,104,105,108],"li",{},[56,106,107],{},"Access every user record"," on the platform",[103,110,111,114],{},[56,112,113],{},"Send bulk emails"," through the platform's infrastructure",[103,116,117,120],{},[56,118,119],{},"Delete any user account"," without authentication",[103,122,123,126],{},[56,124,125],{},"Grade student test submissions"," as if they were a teacher",[103,128,129,132],{},[56,130,131],{},"Access organizations' admin emails"," and internal data",[13,134,135],{},"Of the exposed users, 10,505 were enterprise accounts and 870 had their full PII leaked: names, emails, and organizational data all accessible to anyone who looked.",[17,137,139],{"id":138},"lovables-response","Lovable's Response",[13,141,142],{},"When Khan initially reported his findings through Lovable's support, his ticket was closed without a response.",[13,144,145],{},"After The Register got involved, Lovable's CISO Igor Andriushchenko said the company received \"a proper disclosure report\" on the evening of February 26 and acted on the findings \"within minutes.\"",[13,147,148],{},"Andriushchenko pointed out that every Lovable project includes a free security scan before publishing:",[28,150,152],{"attribution":151},"Igor Andriushchenko, Lovable CISO",[13,153,154],{},"\"This scan checks for vulnerabilities and, if found, provides recommendations on actions to take to resolve before publishing. Ultimately, it is at the discretion of the user to implement these recommendations. In this case, that implementation did not happen.\"",[156,157,158],"lesson-box",{},[13,159,160,163],{},[56,161,162],{},"The security scan existed. The user ignored it."," This is the fundamental tension in vibe coding: platforms can flag problems, but if the person building the app doesn't understand security (or doesn't care), the warnings go unheeded. The app ships anyway, vulnerabilities and all.",[17,165,167],{"id":166},"this-is-a-pattern-not-a-one-off","This Is a Pattern, Not a One-Off",[13,169,170],{},"This isn't the first time Lovable has been in the security spotlight. In 2025, researchers scanned 1,645 Lovable-created web apps from the platform's Discover page. Of those, 170 allowed anyone to access user information including names, emails, financial data, and API keys.",[13,172,173],{},"And it's not just Lovable. The broader vibe-coding ecosystem has the same problems:",[100,175,176,182,188,194],{},[103,177,178,181],{},[56,179,180],{},"Veracode found"," that 45% of AI-generated code contains security flaws, with no improvement over time as models get larger",[103,183,184,187],{},[56,185,186],{},"Bubble.io"," had an unpatched zero-day that allowed database bypass",[103,189,190,193],{},[56,191,192],{},"Firebase test mode"," was left enabled across 900+ mobile apps, exposing 1.8 million passwords",[103,195,196,199],{},[56,197,198],{},"39 million secrets"," were leaked on GitHub in 2024. 70% are still active today",[13,201,202],{},"The pattern is always the same: AI generates code that works functionally but fails on security. The developer doesn't know enough to spot the problems. The app ships. Users pay the price.",[204,205,207],"h3",{"id":206},"why-ai-gets-security-wrong","Why AI Gets Security Wrong",[13,209,210],{},"AI code generators optimize for \"code that works.\" When you ask for an authentication system, you get one that appears to authenticate users. When you ask for an admin panel, you get one that looks like it restricts access.",[13,212,213],{},"But \"looks like it works\" and \"is actually secure\" are two very different things. As Alex Stamos, CISO at SentinelOne, has noted, the best practice for web apps is to avoid letting users access the database at all. The application should determine what information users can see and fetch only that data.",[13,215,216],{},"Vibe-coded apps often skip this architectural pattern entirely, connecting frontend code directly to the database with only client-side guards standing between users and full data access.",[17,218,220],{"id":219},"whos-responsible","Who's Responsible?",[13,222,223],{},"This is the question the vibe-coding industry hasn't answered yet.",[13,225,226],{},"Lovable says users are responsible for implementing security recommendations. That's technically correct. But when your platform markets itself as generating \"production-ready apps with authentication included,\" users reasonably expect that the authentication actually works.",[228,229,230],"warning-box",{},[13,231,232,235],{},[56,233,234],{},"The marketing vs. reality gap:"," Vibe-coding platforms sell the dream of shipping without needing to understand code. But security can't be vibed. Someone (the platform, the AI, or the developer) needs to verify that the generated code is actually secure. Right now, nobody's doing that consistently.",[13,237,238],{},"Khan's perspective is worth hearing:",[28,240,241],{"attribution":62},[13,242,243],{},"\"If Lovable is going to market itself as a platform that generates production-ready apps with authentication 'included,' it bears some responsibility for the security posture of the apps it generates and promotes. At minimum, a basic security scan of showcased applications would have caught every critical finding in this report.\"",[17,245,247],{"id":246},"what-you-can-do","What You Can Do",[13,249,250],{},"If you're building on Lovable, Bolt, Cursor, or any other vibe-coding platform, the lesson here is straightforward:",[252,253,254,260,266,272,278],"ol",{},[103,255,256,259],{},[56,257,258],{},"Never trust generated code is secure."," Always verify authentication and access control logic",[103,261,262,265],{},[56,263,264],{},"Enable Row Level Security"," on every Supabase table before going live",[103,267,268,271],{},[56,269,270],{},"Test as an unauthenticated user."," Can you access data you shouldn't? If yes, you have a problem",[103,273,274,277],{},[56,275,276],{},"Run a security scan before publishing."," The flaws in this app were basic, and any automated scanner would have caught them",[103,279,280,283],{},[56,281,282],{},"Don't ignore security warnings."," Lovable's own scan flagged issues. The developer ignored them. 18,000 users paid the price",[13,285,286],{},"The fix isn't complicated. The consequences of skipping it are.",[288,289,290,297,303,309],"faq-section",{},[291,292,294],"faq-item",{"question":293},"What happened with the Lovable app vulnerability?",[13,295,296],{},"A security researcher found 16 vulnerabilities in a Lovable-hosted exam app, including backwards authentication logic. 18,697 user records were exposed including student data from K-12 schools and universities like UC Berkeley and UC Davis. The app was featured on Lovable's Discover page with over 100,000 views.",[291,298,300],{"question":299},"What is the Lovable vibe coding platform?",[13,301,302],{},"Lovable is a vibe-coding platform that generates full-stack web applications from natural language prompts. Apps are built with AI-generated code and powered by Supabase backends for authentication, file storage, and database access through PostgreSQL. It's part of the broader movement of AI-assisted development tools.",[291,304,306],{"question":305},"How did the AI write authentication backwards?",[13,307,308],{},"The AI implemented access control using Supabase remote procedure calls but inverted the logic, blocking all authenticated (logged-in) users while allowing unauthenticated (anonymous) visitors full access. This classic logic inversion was repeated across multiple critical functions. A human security reviewer would catch this in seconds, but the AI optimized for \"code that works\" rather than \"code that's secure.\"",[291,310,312],{"question":311},"Could a security scan have prevented this?",[13,313,314],{},"Yes. An automated security scan before publishing would have caught the missing Row Level Security, the inverted authentication logic, and the exposed user data. Lovable includes a free security scan before publishing, but the app owner didn't implement the recommendations. Regular scanning (both before launch and ongoing) catches exactly these kinds of basic misconfigurations.",[316,317,318,324,329,334],"related-articles",{},[319,320],"related-card",{"description":321,"href":322,"title":323},"Another Supabase app launched without Row Level Security. 1.5 million records exposed.","/blog/stories/moltbook-exposed-api-keys","How Moltbook Exposed 1.5 Million API Keys",[319,325],{"description":326,"href":327,"title":328},"15 items to check before shipping your Supabase app","/blog/checklists/supabase-security-checklist","Supabase Security Checklist",[319,330],{"description":331,"href":332,"title":333},"How Cursor, Bolt, and Lovable handle secrets, and how to stop leaks","/blog/best-practices/ai-api-key-exposure","Why AI Code Generators Expose Your API Keys",[319,335],{"description":336,"href":337,"title":338},"What to check before you launch anything","/blog/checklists/pre-deployment-security-checklist","Pre-Deployment Security Checklist",[340,341,344,348],"cta-box",{"href":342,"label":343},"/","Start Free Scan",[17,345,347],{"id":346},"is-your-vibe-coded-app-leaking-data","Is Your Vibe-Coded App Leaking Data?",[13,349,350],{},"Run a free scan to check for backwards auth logic, missing RLS, exposed API keys, and other vulnerabilities the AI might have missed.",{"title":352,"searchDepth":353,"depth":353,"links":354},"",2,[355,356,357,358,359,363,364,365],{"id":19,"depth":353,"text":20},{"id":39,"depth":353,"text":40},{"id":71,"depth":353,"text":72},{"id":138,"depth":353,"text":139},{"id":166,"depth":353,"text":167,"children":360},[361],{"id":206,"depth":362,"text":207},3,{"id":219,"depth":353,"text":220},{"id":246,"depth":353,"text":247},{"id":346,"depth":353,"text":347},"stories","2026-02-27","A Lovable-hosted exam app had 16 vulnerabilities including backwards authentication logic that blocked logged-in users and let anonymous visitors access everything. 18,697 user records leaked, including K-12 students.",false,"md",[372,374,376,378],{"question":293,"answer":373},"A security researcher found 16 vulnerabilities in a Lovable-hosted exam app, including backwards authentication logic. 18,697 user records were exposed including student data from K-12 schools and universities.",{"question":299,"answer":375},"Lovable is a vibe-coding platform that generates full-stack web applications from natural language prompts. Apps are powered by Supabase backends for authentication, storage, and database access.",{"question":305,"answer":377},"The AI implemented access control using Supabase remote procedure calls but inverted the logic, blocking all authenticated (logged-in) users while allowing unauthenticated (anonymous) visitors full access. This classic logic inversion was repeated across multiple critical functions.",{"question":311,"answer":379},"Yes. An automated security scan before publishing would have caught the missing Row Level Security, the inverted authentication logic, and the exposed user data. Lovable even includes a free security scan before publishing, but the app owner didn't implement the recommendations.",true,null,{},"A vibe-coded exam app on Lovable exposed 18,697 users including students. The AI wrote authentication backwards. A security scan would have caught it instantly.","/blog/stories/lovable-app-exposed-18000-users","9 min read","[object Object]","BlogPosting",{"title":5,"description":368},{"loc":384},"blog/stories/lovable-app-exposed-18000-users",[392,393,394],"Lovable","Supabase","Access Control","summary_large_image","FxZdB021_Csd4OR-IWPzwhXIEUcdRIbt1r8aIHHRaEE",1775843918545]