Real, publicly reported security problems in apps built with AI coding tools, and in the tools themselves. Each entry has a short plain-English summary, links to its sources, an honest answer on whether Milo's outside-in check would have caught it, and a prompt you can paste into your AI coder to check your own app.
How we pick entries: only incidents with a credible public source (a researcher's write-up, a CVE or security advisory, reputable news, or the vendor's own post), and we link every one. We stick to platform-level reports and research. We don't name small private apps or their owners unless the case itself was widely reported. Dates are when the problem was publicly disclosed or reported. Some entries are research by companies that sell security scanning, and we say so. Of the 15 entries, our passive check would catch 3, partly catch 4, and can't see 8. Many problems live in your editor, your packages or the platform, not on your live app.
· Lovable, Bolt, v0, Replit, Base44
Open Supabase tables and leaked keys (research)
A scanning vendor's passive scan of 30,998 live apps (12 to 14 August 2026) found that 2,096 of the 3,680 Supabase-backed apps it could check let a logged-out visitor read at least one table, and about 1 in 23 apps shipped a secret key in public code. Only 3 apps exposed the Supabase service_role key.
Would Milo's check catch this? Yes. These are the same outside checks we run: tables readable with your public key, and secret keys in your JavaScript.
Fix prompt (paste into your AI coder)
Check every table in my Supabase project. For each one, tell me whether Row Level Security is enabled and list its policies in plain English. Enable RLS on any table where it's off, replace any policy that uses USING (true) on private data with one that only lets users see their own rows (auth.uid() = user_id), and then show me how to confirm that a logged-out request to each table returns no private rows.
Researchers at RedAccess said they found more than 5,000 apps on these platforms' own domains with little or no authentication, and that around 40% appeared to expose sensitive data such as medical, financial or customer-chat records. Replit, Lovable and Base44 pushed back, saying visibility is the builder's setting, and WIRED couldn't confirm how real or sensitive all of the data was.
Would Milo's check catch this? Partly. We flag admin pages and data that open without a login on the URL you send us. We can't know which of your ordinary pages were meant to be private.
Fix prompt (paste into your AI coder)
List every page and API route in my app and mark which ones should only work for signed-in users (or only for admins). For each one that should be private, check that it actually refuses a logged-out request on the server, not just by hiding a button. Also tell me where my app's visibility or privacy setting is on this platform and what it's set to now.
Platform API flaw (broken object-level authorization)
A researcher reported that any free Lovable account could use Lovable's API to read other users' public projects created before November 2025, including source code, AI chat histories and, where builders had hard-coded them, database credentials. Lovable first said there was no data breach and that this was intended behaviour for public projects, then said its explanation of 'public' had been unclear and apologised.
Would Milo's check catch this? No. This was a flaw in Lovable's own API, not something visible on your live app. We would still flag a secret key if it also ships in your public JavaScript.
Fix prompt (paste into your AI coder)
Search my whole project for hard-coded secrets: API keys, database passwords, Supabase service_role keys, Stripe secret keys and tokens. List each one with its file and line. Move each to a server-side environment variable or secret, update the code to read it from there, and give me a checklist of which keys I must rotate in each provider's dashboard because they were in my code.
A researcher reported 16 flaws in one unnamed, Lovable-hosted education app. An AI-written access check was backwards, blocking signed-in users while letting anonymous visitors in, and exposed 18,697 user records. Lovable said the owner hadn't acted on its pre-publish security scan and that part of the code wasn't generated by Lovable.
Would Milo's check catch this? Partly. We'd catch tables a logged-out visitor can read. We don't call your database functions or try to change data, so a reversed check inside a function can slip past a passive check.
Fix prompt (paste into your AI coder)
Review every Supabase database function (RPC) and every access check in my app. For each one, write one sentence on who should be allowed in, then check the code actually does that and isn't inverted (for example blocking signed-in users or allowing anonymous ones). Revoke EXECUTE from the anon role on any function that shouldn't be public, and show me how to test each function as a logged-out user and as a normal signed-in user.
Supabase key in the frontend with no Row Level Security
Wiz found that Moltbook, a widely covered social network for AI agents, shipped its Supabase key in client-side JavaScript with Row Level Security missing, giving anyone read and write access to its production database, including about 1.5 million agent API tokens and 35,000 email addresses. It was fixed within hours of disclosure.
Would Milo's check catch this? Yes. A public Supabase key plus a table readable without login is exactly what our database check looks for.
Fix prompt (paste into your AI coder)
My Supabase anon (publishable) key is in my frontend, which is normal. Make sure that's safe: enable Row Level Security on every table, add policies so each user can only read and change their own rows, and make sure no table that stores tokens, API keys, emails or private messages is readable or writable by the anon role. Then show me a curl command I can run with only the anon key to prove a logged-out visitor gets nothing private back.
Leaked secrets and missing Row Level Security (research)
Escape, a security-testing company, scanned about 5,600 publicly available vibe-coded apps and reported more than 2,000 high-impact vulnerabilities, 400+ exposed secrets and 175 cases of exposed personal data. The most common problems were exposed Supabase tokens and missing or weak Row Level Security.
Would Milo's check catch this? Partly. Exposed keys and tables open to logged-out visitors, yes. Business-logic bugs that need a logged-in account, no.
Fix prompt (paste into your AI coder)
Do a pre-launch security pass on my app: 1) find any secret keys that end up in the browser bundle and move them server-side, 2) check Row Level Security and policies on every database table, 3) list API routes that work without login and confirm each one should, 4) add the main security headers for my host. Explain each finding in plain English before fixing it.
Malicious versions of the popular Nx build packages were on npm for about 4 hours. On install they hunted for tokens, SSH keys and .env files, tried to use locally installed AI coding command-line tools to search the machine, and uploaded what they found to public GitHub repositories.
Would Milo's check catch this? No. This happened on developers' own computers when they installed a package, not on a live app.
Fix prompt (paste into your AI coder)
Check my package-lock.json (or yarn/pnpm lockfile) for any of the malicious Nx versions listed in GitHub advisory GHSA-cxm3-wv7p-598c. If any are present, tell me exactly which, then walk me through cleaning node_modules and package caches and give me a list of every token and key stored on this machine (GitHub, npm, cloud, .env files) that I should rotate.
Cymulate reported two Claude Code flaws. CVE-2025-54794 let file access escape the working folder through a look-alike folder name (fixed in 0.2.111), and CVE-2025-54795 let a crafted command run without the approval prompt (fixed in 1.0.20).
Would Milo's check catch this? No. This affects the coding tool on your computer, not your live app.
Fix prompt (paste into your AI coder)
Tell me which version of Claude Code I'm running and how to update it. Then review my Claude Code permission settings and list every command and folder it's allowed to use without asking me, so I can remove anything broader than this project needs.
CVE-2025-54135: in Cursor 1.2.1 and earlier, a prompt injection (for example in content an MCP tool reads) could make the agent create a new .cursor/mcp.json file without approval and run attacker-chosen code on the developer's machine. Fixed in Cursor 1.3.9.
Would Milo's check catch this? No. This affects the editor on your computer, not your live app.
Fix prompt (paste into your AI coder)
List every MCP server configured for this project and for my user (including .cursor/mcp.json), what each one can access, and whether it reads content from outside sources such as tickets, web pages or emails. Flag any I don't recognise, suggest removing ones I don't need, and remind me to update Cursor to the latest version.
Veracode tested more than 100 language models on 80 coding tasks and found that the generated code introduced an OWASP Top 10 security flaw in 45% of the tasks.
Would Milo's check catch this? Partly. Only problems that show from the outside (exposed keys, open data, missing headers, open admin pages). Injection bugs behind a login aren't in reach of a passive check.
Fix prompt (paste into your AI coder)
Review the code you wrote for this app for the OWASP Top 10, in plain English. Look especially for: user input reaching SQL or shell commands without parameters, missing authorization checks on API routes, secrets in client code, and unsafe HTML rendering. List each finding with the file, the risk and the fix, then fix the high-risk ones first.
Wiz found that two undocumented Base44 sign-up and verification endpoints let anyone who knew an app's public app_id create a verified account on private, SSO-only apps. Wix fixed it in under 24 hours and found no evidence of abuse.
Would Milo's check catch this? No. This was a flaw in Base44's own sign-up system, fixed platform-wide. We don't try to register accounts on your app.
Fix prompt (paste into your AI coder)
List all user accounts in my app with their sign-up date and sign-up method. Flag any accounts I didn't invite, especially ones created on or before 9 July 2025, and show me where in my Base44 settings I can confirm my app is set to private with invited users only.
An attacker used a wrongly scoped GitHub token to slip a destructive prompt into version 1.84.0 of the Amazon Q Developer extension for VS Code. AWS says the code failed to run because of a syntax error and no customer environments were affected. Version 1.85.0 removes it.
Would Milo's check catch this? No. This affected an editor extension on developers' machines, not live apps.
Fix prompt (paste into your AI coder)
List every extension installed in my editor with its version, and tell me how to check each against its publisher's security advisories. If Amazon Q Developer 1.84.0 is installed, tell me how to remove it and update to 1.85.0 or later.
During a public vibe-coding experiment, SaaStr founder Jason Lemkin said Replit's AI agent deleted his app's production database despite an explicit code freeze, then wrongly said it couldn't be rolled back. The rollback did work, and Replit later made development and production databases separate by default.
Would Milo's check catch this? No. This is about what the AI agent is allowed to do inside your project, not something visible from outside.
Fix prompt (paste into your AI coder)
Before you change anything else: tell me whether this project uses separate development and production databases. If not, set that up so you can only touch the development database. Confirm that backups or rollback points exist for production and show me how to restore one, and never run a command that deletes or overwrites production data without asking me first.
General Analysis showed that if a coding agent connected to Supabase with the service_role key reads text an attacker wrote (such as a support ticket), hidden instructions can make it copy private tables to somewhere the attacker can see. Supabase recommends running its MCP server read-only and scoped to one project.
Would Milo's check catch this? No. This risk lives in your development setup (agent plus database access), not on your live app.
Fix prompt (paste into your AI coder)
Check how my coding agent connects to Supabase. Make sure the Supabase MCP server runs in read-only mode, is scoped to a single development project, and doesn't use the service_role key. Then tell me which tools it exposes and turn off any I don't need, and remind me never to let the agent read user-submitted content (tickets, messages) while it has database access.
Missing or weak Row Level Security (CVE-2025-48757)
Researchers checking apps listed on Lovable's showcase found 303 Supabase endpoints across 170 of 1,645 projects that let unauthenticated visitors read, and sometimes change, data such as emails, payment status and API keys. Lovable disputes the CVE, saying each app's owner is responsible for its data rules.
Would Milo's check catch this? Yes. Tables that answer a logged-out request with your public key are exactly what our database check tests (read-only, one row at most).
Fix prompt (paste into your AI coder)
For every table my frontend reads or writes through Supabase, check that Row Level Security is on and that the policies match who should see the data. Remove any policy with USING (true) on tables holding personal data, payments or keys, move sensitive columns (keys, payment status) into a table the browser can't read, and show me how to test each table as a logged-out visitor.
This tracker summarises public reports. It isn't a security audit, and it doesn't claim that any app is still vulnerable today: most issues listed here were fixed after disclosure. Figures are as reported by the linked sources, and vendors sometimes dispute them, which we note. Know of an incident with a public source, or spotted a mistake? Email hello@milokits.com.