Security Radar: Missing RLS, a Next.js RCE, Leaky Secrets

Today's vibe-coding chatter split into two lanes: which model writes better code, and what that code leaves exposed. The second lane matters more if you've shipped an app. A recurring gap in Cursor-built Supabase apps, a real CVE in a bundled Next.js dependency, and a new push to keep secrets out of AI agents all point at the same problem: what an AI builder sets up by default isn't always what your app needs to be safe.

TL;DR

• Cursor will scaffold working Supabase CRUD using the anon key without writing row-level security (RLS) policies. The anon key is public by design — the real gap is missing RLS, not the key itself.
• CVE-2025-71389: Cal.com before 5.9.9 bundled a Next.js version vulnerable to unauthenticated RCE via React Server Components request handling, inherited from upstream CVE-2025-55182.
• Vercel now auto-revokes API tokens and keys it finds leaked in public GitHub repos, gists, or npm packages, and notifies the owner.
• A new open-source tool, OneCLI, tries to keep raw secrets out of AI coding agents' hands entirely.

Cursor's default Supabase setup skips RLS

A detailed r/cursor post lays out a pattern the author found in four separate projects. Ask Cursor to wire up Supabase and build CRUD, and it hands back working code that queries the database with the anon key from the client. That code runs fine in testing. Nothing errors. Nothing warns you.

Here's the part that gets missed: the anon key is public by design. It ships in your client bundle. Anyone can see it in devtools. That is normal, not a leak. The actual control that decides whether a stranger with that key can read your whole users table is row-level security. If you never wrote RLS policies, the default in most Supabase projects is wide open. Cursor doesn't add them unless you ask, and most people don't know to ask.

The fix takes minutes: open the Supabase dashboard, check Table Editor for the RLS toggle on each table, and write policies that scope reads and writes to the requesting user. This applies just as much if you built on Lovable, Bolt, or v0 — any tool that scaffolds Supabase queries from a prompt can produce the same silent gap.

A dependency bug becomes an unauthenticated RCE

CVE-2025-71389 shows what happens when a framework-level bug rides along in a bundled dependency. Cal.com (calcom/cal.diy) before version 5.9.9 shipped a Next.js version whose React Server Components request handling deserializes attacker-controlled input. A remote attacker could send a crafted RSC request and get arbitrary code executed on the server — no authentication, no user interaction. The bug traces back to an upstream Next.js vulnerability, CVE-2025-55182, and Cal.com resolved it in 5.9.9 by updating the dependency.

The lesson isn't specific to Cal.com. Plenty of AI-scaffolded apps — from v0, Bolt, and Lovable projects — run on Next.js under the hood, often pinned to whatever version the builder templated in months ago. If you never bump that dependency, you inherit whatever the framework maintainers patch later. An AI builder that generates your app once doesn't come back to update it.

Secrets are becoming a separate problem from code

Two unrelated items point at the same shift. Vercel's new token formats and secret scanning update means Vercel now automatically revokes API credentials it detects committed to public GitHub repos, gists, or npm packages, and notifies you when that happens. Separately, OneCLI, an open-source credential gateway, launched on Hacker News with the explicit goal of keeping raw secrets away from AI coding agents rather than pasting them into chat context or config files an agent can read.

Both are responses to the same trend: as agents get write access to dashboards, CLIs, and deploy tools, the old advice of "don't commit your .env file" isn't enough. Agents read files, run commands, and sometimes echo output back into logs or chat history. Secret hygiene now needs its own layer, not just a gitignore entry.

FAQ

Is a Supabase anon key a security risk by itself?

No. The anon key is meant to be public — it's embedded in your client bundle and visible to anyone who opens devtools. It's not a leak and not a vulnerability on its own. The risk is what happens after: without row-level security policies, that public key can read or write any row in a table. RLS is the control that matters, not the key.

What is CVE-2025-71389 and does it affect my app?

It's an unauthenticated remote code execution flaw in Cal.com versions before 5.9.9, caused by a bundled Next.js version that mishandles React Server Components requests. It traces back to CVE-2025-55182 in Next.js itself. If your app uses Cal.com or bundles an affected Next.js version, check your dependency version and update. It's a useful reminder that AI-scaffolded apps built on Next.js inherit framework bugs unless someone keeps dependencies current.

How do I keep secrets out of my AI coding agent?

Avoid pasting raw API keys or tokens into agent chat or prompt files. Use environment variable managers and secret scanning where your host supports it — Vercel now auto-revokes leaked tokens found in public repos. Tools like OneCLI aim to sit between your agent and your credentials so the agent never sees the raw secret at all.

The bottom line

None of today's items are exotic. A missing RLS policy, an outdated framework dependency, a secret pasted somewhere it shouldn't be — these are old problems wearing new clothes because an AI builder wrote the first draft. The fix in every case is the same: check what got scaffolded by default, then close the specific gap, whether that's writing RLS policies, updating a dependency, or keeping raw keys out of your agent's context.