In Veracode's 2026 testing, AI-generated code compiled almost every time and passed security checks about half the time — with no security prompting, on raw models. Two public cases — a scan of Lovable's showcase in 2025 and Wiz's Moltbook disclosure in 2026 — show one shape a failure can take: a key that is meant to be public, and a server-side rule that was missing or wrong. Here is the mechanism, what the record actually establishes, what it does not, and the afternoon that checks for it.
Somebody on your side of the table shipped an app this quarter that no security person ever read. A client intake portal. A technician's internal tool. A dashboard built in an afternoon with an AI coding assistant and a login page that made it feel finished.
It works. I believe you. That is not the question any more.
Veracode's 2026 GenAI Code Security Report (press release, July 28, 2026) tracks code generated by more than 100 models. By Veracode's numbers:
Two conditions ride with those numbers and they matter: the tests used no security-specific prompting, and they ran against raw models — not agents, not tools with guardrails, not code a human reviewed. Veracode says so explicitly.
So the honest reading is not "AI code is insecure." It is narrower and more useful: code that nobody asked about security, and nobody reviewed, passes security checks about half the time. Our read: that describes a lot of the apps quietly going live inside small businesses right now.
Many of these apps put their data in a hosted database — Supabase is a common one — and the browser talks to it directly. To do that, the page carries a key.
Here is the part people get backwards: that key is supposed to be public. A publishable (or "anon") key is designed to sit in the browser. Anyone can read it. That is fine, because the key is not the lock.
The lock is a rule on the database itself — in Supabase, a Row Level Security policy — that says this user can read these rows, and only these. When the rule exists and is right, the public key is harmless. When the rule is missing or wrong, the public key opens the whole table, for anyone, without logging in. And nothing on the screen looks any different.
That is the entire mechanism behind both cases below.
In March 2025, Matt Palmer — who works in developer relations at Replit, which builds a competing AI app builder; read the finding with that in mind, and read his method yourself — found a Lovable-built site that would hand over its whole users table when a request was edited to ask for everything. So he and a colleague checked the rest.
Lovable keeps a showcase page of launched projects. Their script visited the homepages of 1,645 projects listed there, captured each request to the database, and re-issued it asking for everything. Per Palmer's published statement:
He is careful about the method, and so are we: the script only analysed homepages. It never logged in and never crawled deeper. Our read: that count is a floor, not a ceiling.
It was published as CVE-2025-48757 on May 29, 2025. Palmer also writes (as of May 2025) that Lovable's later "security scan" checked that an RLS policy existed, not whether it was correct. That is his assessment — but hold onto the underlying point, because it comes back below.
In January 2026, Moltbook — a social network for AI agents that had just gone viral, and whose founder said publicly he had vibe-coded it — got a visit from Wiz researchers who, in their words, were "simply browsing like normal users."
Within minutes they found a Supabase key in the site's client-side JavaScript. Wiz is precise here: it was a publishable key, and exposing one "does not automatically indicate a security failure." The failure was behind it — no Row Level Security. Per Wiz's write-up (Gal Nagli, February 2, 2026), that key gave unauthenticated read and write access to the production database:
Moltbook secured it within hours of Wiz's report, over several rounds of fixes, and Wiz deleted the data it had accessed. This was a research disclosure, not an attack report. (Wiz notes that researcher Jameson O'Reilly independently found the same misconfiguration.) Wiz's own summary is the line worth keeping: the issue "ultimately traced back to a single Supabase configuration setting."
Neither case is new in kind. OWASP's Top 10:2025 keeps Broken Access Control at #1; in OWASP's contributed test data, every application tested had some form of it. And OWASP states the principle plainly: access control is only effective when implemented in trusted server-side code.
One of OWASP's own example scenarios is an app that keeps its access checks in the front end — JavaScript that stops you navigating to the admin page — while the admin URL itself still answers a direct request. The attacker never clicks the button. They call the route.
Our read: this is the pattern an assistant ships most easily, because it builds exactly what was asked for: a page, a hidden button, a redirect for non-admins. It all looks right in a demo. Nothing in the demo asked the server to refuse.
It is worth being honest about the edges of the record.
What does hold across both: a rule that exists is not a rule that works, and the only way to know which one you have is to try it — from the outside, as somebody who should not get in.
One app. The one a real person can sign into today. Put whoever built it in the room.
THE PRE-LAUNCH AFTERNOON — ONE APP
1 PICK one app a real person can sign into.
2 SECRETS search the BUILT front end (view source,
network tab, build output) — not the repo —
for keys. Publishable key: fine.
Service / admin key: remove it,
redeploy, rotate, treat as exposed.
3 ROWS for every table the browser can reach,
confirm the row rule EXISTS, then prove it
WORKS with two test accounts: B's record
as A, and with no session; read AND
write. You should get nothing back.
4 ROUTES call the admin API directly as an
ordinary user. Expect a refusal (401/
403/404) or empty result, never data.
5 HOW every PASS gets a How-verified line, a date
and a named human.
Step 5 is the one that turns an afternoon into evidence. "The assistant said it did" is not a how. "Called /api/users/2 as user 1, got 403, 2026-09-29, J. Smith" is.
Two ground rules. Run this only on apps you own or are authorized to test. And if a check returns data that should not have been readable, treat it as a potential exposure — follow your incident-response plan and bring in counsel and your insurer; notification duties are a legal question, not a checklist one.
The free kit: The Vibe-Coded App Pre-Launch Kit (Gatorbyte #015) is this afternoon on paper — 26 controls in six groups, the five things the login page probably forgot, a legal and trust pass, a review-only prompt for the assistant that built the app, and a pre-launch register with a How-verified column. Runs offline as a portable Windows app; no account, nothing phones home. Free to use inside your organization and with your clients, including in paid engagements.
→ https://thesecuritygator.gumroad.com/l/gb015-vibe-coded-app-prelaunch-kit
The kit supports secure-development, pre-release review and audit-preparation workflows — a practical starting point to review and adapt for your organization; not legal, compliance, or audit advice, and not a substitute for a penetration test or an application security assessment. The Security Gator is not affiliated with Veracode, Wiz, OWASP, Replit, Lovable or Moltbook.
Sources: