I Audited 50 Vibe-Coded Apps. Here's What Broke.

I audited 50 Lovable / v0 / Bolt / Cursor / Claude Code apps over the last few months. Some were friends' side projects, some were YC-backed startups, some were 24-hour hackathon submissions that made it to production anyway. Same five bugs in nearly every one.

This post is the writeup. Concrete grep commands, real CVEs, what to actually fix.

If you want the kit at the end of the post: it's $10, 50 skills.

Bug 2, Secret keys in NEXT_PUBLIC_* (39 of 50)

This is the Moltbook leak (Feb 2026, 1.5M API tokens, 35K emails, 47GB of agent conversation history). Cause: a Supabase anon key was hardcoded in the bundled client JavaScript via NEXT_PUBLIC_SUPABASE_ANON_KEY. That key, with no RLS to back it, returned every row of every table.

NEXT_PUBLIC_ is not a naming convention. It's a build instruction. Every variable with that prefix gets baked into the JavaScript that ships to every visitor's browser. If it's a secret, it's not a secret anymore.

How to find it:

# Audit every NEXT_PUBLIC_* var in your codebase

grep -rE "NEXT_PUBLIC_[A-Z_]+" app/ pages/ components/ lib/ --include="*.ts" --include="*.tsx" --include="*.js" | sort -u



# Audit the build output for committed secrets

grep -rE "sk_live_|pk_live_|sk_test_[a-zA-Z0-9]{24,}|sb_secret_|AKIA[A-Z0-9]{16}" .next/ public/

Anything in NEXT_PUBLIC that names a secret (SECRET, KEY other than ANON_KEY/PUBLISHABLE_KEY, TOKEN) is a leak.

How to fix: rename the var to remove NEXT_PUBLIC_, move usage to a server-only file (API route, server component, or getServerSideProps). For Stripe: keep NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY, hide STRIPE_SECRET_KEY. For Supabase: keep NEXT_PUBLIC_SUPABASE_ANON_KEY (with RLS), hide SUPABASE_SERVICE_ROLE.

Source:

Bug 4, AI agent destructive operations with no gate (8 of 50, but every one was scary)

PocketOS, April 2026. A Cursor + Claude agent ran with an unscoped Railway API token. The agent dropped the production database and all backups in 9 seconds. 30-hour outage.

In 8 of the audited apps, an AI agent had:

• A Railway / Vercel / Supabase token with project-wide write access (no environment scoping).


• No human-in-the-loop gate on destructive operations.


• No rate limit on tool calls.

How to find it:

# Token scope audit

echo "Tokens this agent has access to:"

grep -rE "_TOKEN|_KEY" .env .env.local 2>/dev/null | awk -F= '{print $1}'



# Check what tools the agent can call

ls .mcp.json && cat .mcp.json | jq '.mcpServers | keys'

ls .claude/skills/  # in Claude Code



# Check destructive tools have gates

grep -rE "DROP TABLE|DELETE FROM|rm -rf|--force" .claude/skills/ .mcp.json

How to fix:

1. Use scoped tokens. Railway, Vercel, Supabase all support read-only or environment-scoped tokens. Use them.


2. Wrap destructive verbs with a confirmation gate. Either via the agent's permission system, or a shell wrapper that requires CONFIRM=yes.


3. Log every tool call. Audit the log post-incident.

Source: and

If you want the full kit (50 audit skills, 4 full checklists, 15 .cursorrules, 30 adversarial review prompts, 10 case studies): $10 flat at https://rishabhvaai.gumroad.com/l/plddbd. Lifetime access. 7-day refund.

If you spot a sixth pattern I should add to v1.1, comment below or DM me. I'm tracking everything I miss.