Supabase RLS Gaps and Leaked Keys in Vibe-Coded Apps

A new CVE shows what happens when a database endpoint ships without row-level security. A Reddit teardown shows what happens when an API key ships inside the frontend. Neither is exotic. Both are common in apps built fast with AI tools.

TL;DR

• CVE-2026-56238 lets anyone with a public Supabase apikey pull revenue, customer counts, and other business metrics from a misconfigured global_stats endpoint — the flaw is missing row-level security, not the public key itself.
• A Reddit teardown of a vibe-coded chat app found a real OpenAI private key sitting in the public JavaScript bundle. That's a leak. A public Firebase config next to it is not — that's normal, unless the underlying rules are open.
• Vercel is warning that AI endpoints are now a direct billing target: a single abused prompt can cost far more than a normal web request, and attackers know it.
• None of this requires a sophisticated attacker. Thirty minutes and a browser's dev tools was enough in the Reddit case.

A public endpoint, a private ledger

CVE-2026-56238 hits Capgo before version 12.128.2. The bug is in a Supabase PostgREST endpoint called global_stats. Anyone with the project's public apikey — the one meant to be public — can query it and get back MRR, total revenue, plan-tier breakdowns, customer counts, and operational telemetry.

The apikey isn't the problem. Apikeys are supposed to be visible; that's how Supabase's client-side model works. The problem is that nothing on the server checked whether the caller should be allowed to read that table. No row-level security policy, no auth check, nothing standing between a public key and a full financial dashboard. If your app builder scaffolded a Supabase table for internal metrics or admin data, this is the exact failure mode to check for.

Secrets still leak in the JS bundle

A Reddit post describes a thirty-minute teardown of a vibe-coded chat app. The list of problems included an OpenAI private key sitting in plain text inside the public JavaScript bundle. That's a real leak — a secret key that should never leave a server, shipped straight to every visitor's browser. Anyone who opens dev tools can grab it and start spending on your account.

The same post also flagged a "fully public" Firebase config as a problem. It isn't, on its own. Firebase web config, like a Supabase anon key, is meant to be public — it's how the client connects. The actual risk sits behind it: whether Firestore or Storage rules actually restrict who can read and write data. Calling public config a "leak" points people at the wrong fix. Check your rules, not your config's visibility.

AI endpoints are now a billing target

Vercel's writeup on token theft makes a blunt point: a normal HTTP request costs a fraction of a cent, but a single prompt to a frontier model can cost dollars. That makes an exposed AI endpoint a far more attractive target than an exposed web page — Vercel says they've seen this attack against their own APIs. If your app calls an LLM from a route anyone can hit, an attacker doesn't need to breach anything. They just need to find the endpoint and start calling it.

On the mitigation side, Vercel also shipped a team-wide provider allowlist for AI Gateway, letting teams restrict which model providers can serve requests at the gateway level. That's a useful pattern even outside Vercel: verification and rate limits belong on every AI request, not just at signup.

FAQ

Is a public Supabase or Firebase key a security bug by itself?

No. Anon keys and web configs are designed to be public — that's how client apps talk to these backends. The bug is what happens after: whether row-level security (Supabase) or rules (Firebase) actually restrict access. CVE-2026-56238 is a real bug precisely because the RLS layer was missing, not because the key was visible.

My builder put an API key directly in the frontend. What do I do?

Rotate the key immediately — assume it's already been seen. Then move any call that uses a private key (OpenAI, Stripe, etc.) to a server route or edge function, so the key never reaches the browser.

How do I stop someone from running up my AI bill?

Put auth and rate limits in front of any endpoint that calls a language model, and check every request, not just the first one in a session. Gateway-level controls, like provider allowlists, add a second layer if a check gets missed somewhere in the code.

The bottom line

The failures that matter aren't the public keys everyone points at. They're the missing checks behind them: no RLS policy on a Supabase table, no rule on a Firebase path, no rate limit on an AI route, or a private key that never should have left the server. Fix the checks, not the visibility.