Security Radar: RSC CVEs, Tighter Tokens

Two real vulnerabilities landed in React Server Components this week, and Vercel quietly tightened how tokens work on its platform. Neither is a headline-grabber, but both touch the stack that Lovable, v0, and most Next.js-based AI builders ship on top of. If your app runs on Next.js, this one's for you.

TL;DR

• Two CVEs disclosed in React Server Components: CVE-2025-55184 (high severity, denial of service) and CVE-2025-55183 (medium severity, source code exposure). See Vercel's security bulletin.
• Vercel now supports project-scoped access tokens and OIDC for Turborepo Remote Cache, both replacing long-lived, broadly-scoped credentials.
• Supapool, shown on Hacker News this week, spins up a dedicated Supabase instance per coding agent in about 400ms — convenient, but every new instance needs the same access rules as your main one.
• YC-backed Prized is betting that non-engineers building internal tools need security built in by default, not bolted on after.

React Server Components gets two new CVEs

If your app is built on Next.js — and most Lovable, v0, and Vercel-deployed AI apps are — pay attention to this one. Vercel disclosed two vulnerabilities in React Server Components: a high-severity denial-of-service bug (CVE-2025-55184) and a medium-severity source code exposure issue (CVE-2025-55183). Source code exposure means parts of your server-side logic could be readable by an attacker who knows how to trigger the bug. Denial of service means your app could go down under the right request pattern. Neither requires you to have done anything wrong — this is a framework-level issue, not a prompt-engineering mistake. The fix is a framework update, not a rewrite.

Vercel closes the token blast radius

Vercel shipped two changes this week that shrink what a stolen credential can do. Project-scoped tokens can now be limited to a single project, so a leaked token can't touch your other apps or team resources. And Turborepo Remote Cache now accepts OIDC tokens from CI/CD pipelines instead of long-lived personal access tokens. Short-lived, narrowly-scoped credentials are boring, and that's the point — they limit damage when something leaks. If you're still using a single all-access API token across every automation and CI job, this is your nudge to scope it down.

One Supabase per AI agent — and why RLS still matters

Supapool, posted on Hacker News this week, provisions a fresh Supabase instance for each coding agent in roughly 400 milliseconds. That's a real convenience for teams running multiple AI agents against isolated backends. But it raises a quieter question: every new instance inherits the same responsibility as your production database. A Supabase project's anon key being public is normal — it's designed to be public. The actual risk is whether Row Level Security is turned on and configured correctly on every table, in every instance you spin up, including the ones an agent created for you overnight. Spinning up databases fast doesn't make that check optional.

Non-engineers are building internal tools now

Prized, a Y Combinator S26 company, launched on Hacker News with a pitch aimed at a real gap: letting non-engineer staff build internal tools that are secure by default. That's the vibe-coding world in miniature — more people than ever are shipping software without a security background, and the tools around them are starting to compensate. It's a sign the market has noticed the gap between "an app that works" and "an app that's safe," which is exactly the gap this newsletter exists to close.

FAQ

Do I need to worry about the React Server Components CVEs if I built with an AI tool?

If your app runs on Next.js, yes — check what version you're on. Most AI builders that deploy to Vercel or use Next.js under the hood will need a framework update to pick up the fix. This isn't something you caused by prompting badly; it's a framework-level bug.

Is a leaked Supabase anon key a security risk?

No, not by itself. The anon key is meant to be public — it ships in every client bundle by design. The real risk is missing or misconfigured Row Level Security on your tables. If RLS is off or too permissive, the anon key is the least of your problems.

Should ai agents have separate databases?

Tools like Supapool make per-agent database isolation fast and cheap, which is a good practice for keeping agents from stepping on each other's data. But isolation only helps if each new database gets the same access control review as your main one — a fast provisioning step is not a substitute for checking RLS.

The bottom line

Nothing in today's roundup is a five-alarm fire, and that's the point — most real risk in AI-coded apps shows up as quiet framework bugs and default settings, not dramatic breaches. Patch your Next.js version for the RSC CVEs, scope down any long-lived tokens you're still using, and if you're spinning up new backends fast, check RLS on each one before you trust it with real data.