Vibe Coding Security Risks: Real Incidents and How to Check

Legacies is a software and web studio from Romania, founded by Horia Stan and Alexandru Talnaci, and when founders send us an app built with AI tools, security is the first thing we check. We write a lot of our own code with AI agents too, so we know how easily these holes slip in.

The biggest vibe coding security risks are boring and well documented: databases anyone can read because access rules were never set, secret keys shipped to the browser, auth checks that only exist in the UI, and packages the AI pulled in without anyone checking. Newer risks, like prompt injection against coding agents, target the developer's machine itself. Most of these can be found in an afternoon if you know where to look.

Quick answer

• Most common hole: missing or wrong row-level security on Supabase or Firebase, which lets anyone read or edit your data with the public key.
• Second most common: secret API keys in frontend code, where anyone can copy them.
• Newer risks: prompt injection through repositories and docs, and slopsquatting, where attackers register package names that AI models invent.
• How to check: test your data access logged out, search your frontend bundle for keys, audit dependencies, and review what your agent is allowed to run.

Real incidents, not hypotheticals

Here is what has actually happened since the term vibe coding appeared in 2025. We only list cases with public, named sources.

Sources: the Lovable RLS case is documented in Superblocks' breakdown, the Moltbook case in Wiz's research, the 2026 Lovable findings in The Next Web's report, the Replit incident in eWeek, and the prompt injection research in Help Net Security.

Moltbook is the clearest example. Its founder said he did not write a single line of code. Wiz found the Supabase key in the client JavaScript within minutes, and with RLS off, it opened the whole production database.

Why AI-built apps leak

Security is mostly about what should not happen, and prompts describe what should happen. "Users can see their projects" gets built. "Users cannot see anyone else's projects" often does not, unless someone asks.

The research agrees. Veracode's 2025 GenAI Code Security Report tested over 100 models on 80 tasks and found that 45% of the generated code had security flaws, including OWASP Top 10 issues. Models failed to defend against cross-site scripting in 86% of relevant cases.

New to the term? Start with what is vibe coding.

The common holes, one by one

1. Missing row-level security

Supabase and Firebase let the browser talk to the database directly. That is safe only when access rules are in place. The Supabase docs state that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. They also warn that adding policies does not remove grants, so a table protected only by policies can still give anonymous users an insert path.

Typical mistakes we see: RLS on for the first tables but not the ones added later, a policy that says "true" to make an error go away, and storage buckets with user files left public.

2. Exposed API keys

AI tools often put keys wherever the code works first, and that is frequently the browser. An OpenAI or Anthropic key in the frontend means anyone can run up your bill. A Stripe secret key or a Supabase service role key in the frontend means anyone can do anything. In the Moltbook data, private messages even contained users' own OpenAI keys in plain text.

3. Auth that lives only in the UI

The admin button is hidden, but the admin API route does not check who is calling. Or the app checks that you are logged in, but not that the record you asked for is yours. This is called broken object-level authorization, and it was the root cause of the 2026 Lovable API flaw.

4. Prompt injection

Two kinds matter for vibe coders. First, if your app has AI features, users can write instructions into the input to make your model ignore its rules or leak data. Second, your coding agent reads files, READMEs, issues and web pages, and any of those can contain hidden instructions. The Mozilla research showed setup instructions in a repository leading an agent to fetch and run attacker code at runtime, invisible to code review. Agents usually have access to your environment variables and credentials, which is exactly what attackers want.

5. Dependency risks and slopsquatting

AI tools add packages freely. Some are outdated with known vulnerabilities. Some are real but compromised, which is a supply chain problem we cover in npm supply chain security and what npm v12 changes for install scripts.

Slopsquatting is the AI-specific version. Models sometimes invent package names that do not exist. A study presented at USENIX Security 2025 generated 2.23 million code samples with 16 models and found that 19.7% contained at least one hallucinated package, with 205,474 unique fake names. Commercial models averaged 5.2%, open-source models 21.7%, and many fake names repeated across runs. An attacker who registers a repeated fake name gets installed by the next person who trusts the AI. The Cloud Security Alliance research note summarizes the findings.

6. Agents with too much power

The Replit incident was not a hacker. It was an agent with write access to production, doing something it was told not to do. Any agent that can run shell commands, call your database or push to production can cause real damage by mistake.

How to check your own app

You can do most of this yourself in an afternoon.

1. Test your data logged outTake the public URL and key of your Supabase project, which are in your frontend, and try to read each table without logging in. If you get rows back that should be private, RLS is missing or wrong.
2. Test as the wrong userCreate two accounts. Log in as user A and try to load user B's records by changing IDs in the URL or in requests from your browser's network tab.
3. Search the frontend for secretsBuild the app and search the output for key patterns. Anything you find there is public.
4. Audit dependenciesRun npm audit, check that every package actually exists and is maintained, and remove the ones you do not use.
5. Review what your agent can doCheck which commands it may run without asking, which credentials it can see, and whether it can touch production. It should not.

The first command tests anonymous access to a table. The second searches your built frontend for common secret key patterns:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: YOUR_PUBLIC_KEY"

grep -rE "sk_live_|sk-ant-|sk-proj-|service_role" .next/static dist build 2>/dev/null

Also run the Supabase Security Advisor in your dashboard, and use your builder's own scan. Lovable, for example, runs a quick scan on every publish and offers a deeper one, but its docs say plainly that automated scans cannot guarantee complete security.

For the full launch list beyond security, including payments, tests, backups and monitoring, use our vibe coded app to production checklist. Still choosing a tool? See the best vibe coding tools in 2026.

Fix or rebuild?

Most apps we review need fixes, not a rewrite. Turning on RLS with correct policies, moving keys to the server, adding server-side auth checks and cleaning up dependencies is often a few days of work. A rebuild makes sense when access control was never designed at all, and patching it table by table would leave gaps.

This is a big part of what we do: we review the app the way an attacker would, list what is exposed, then fix it or rebuild what cannot be saved. After launch, keeping frameworks patched matters as much, as we explain in Next.js security patches are now a product maintenance task.

When to do it yourself and when to bring in a team

Do it yourself if your app has no real users yet, holds no personal data or payments, and you are comfortable running the checks above and reading what they return. Fixing RLS and moving a key are well within reach for a careful founder with a good coding agent.

Bring in a team when real customer data or money is involved, when you find a hole and are not sure what else is open, or when the app is about to go in front of a lot of people. Our services page has fixed prices, with web apps from 3,499 lei (about EUR 665) and monthly maintenance at 499 lei (about EUR 95) for monitoring, updates and backups. For a marketing site, our free website audit is a quick first check, and our projects page shows what we build.

Frequently Asked Questions

Is vibe coding a security risk?

It can be. AI tools usually build what you ask for and skip what you did not ask for, such as access rules, server-side auth checks and safe key handling. Veracode's 2025 research found security flaws in 45% of AI-generated code samples, and several public incidents came from vibe coded apps with open databases. A review before launch removes most of the risk.

What is the most common security problem in vibe coded apps?

Missing or incorrect row-level security on the database, usually Supabase. Because the browser talks to the database directly with a public key, a table without RLS can be read or edited by anyone. This caused the Lovable showcase exposure tracked as CVE-2025-48757 and the Moltbook leak of 1.5 million API tokens in 2026.

What is slopsquatting?

Slopsquatting is when attackers register package names that AI models tend to invent. A USENIX Security 2025 study found that 19.7% of 2.23 million AI-generated code samples referenced at least one package that did not exist, and many fake names repeated across runs. If an attacker publishes a package under a repeated fake name, developers who trust the AI may install malware.

How do I know if my Supabase database is exposed?

Use the public URL and key from your frontend and try to read your tables without logging in, for example with a simple curl request to the REST API. If private rows come back, row-level security is off or too loose. Also run the Supabase Security Advisor in your dashboard and check that storage buckets with user files are private.

Can AI coding agents be hacked through prompt injection?

Yes. Agents read files, READMEs, issues and web pages, and hidden instructions in that content can push them to run commands. In June 2026 Mozilla's 0DIN team showed a malicious repository leading coding agents like Claude Code to fetch and run a reverse shell. Treat setup instructions in unfamiliar repositories as untrusted, and limit what your agent can run without asking.