Firebase Studio Patched a Source-Code Leak Bug

A patched bug in Firebase Studio shows that the platforms behind AI coding tools can leak your work, not just your app's runtime data. Nothing you need to do here — it's already fixed. But it's a useful reminder of where the real risk sits when you build with AI.

TL;DR

• CVE-2026-12715: Firebase Studio had a missing-authorization flaw that let an attacker download other users' deployed source code by forging GCS URL signing requests. Google patched it April 15, 2026. No customer action needed.
• This is a platform-side bug, not a config mistake in your app. It's different from a public Supabase anon key or a Firebase web config — those are meant to be public. This bug bypassed authorization entirely.
• On r/vibecoding, builders are getting more disciplined: using a second model to review a first model's code, specifically for security, then reproducing each finding before trusting it.
• Vercel published a piece called "Agent responsibly" making the same point from the vendor side: a flawless-looking PR from an agent can still ship a bad assumption straight to production.

The Firebase Studio bug

CVE-2026-12715 affected Firebase Studio, Google's cloud IDE for building apps with AI assistance. The flaw was missing authorization on GCS URL signing requests — meaning an attacker could get a signed URL to download another user's deployed source code without permission. Google patched it April 15, 2026, and says no customer action is needed.

This matters because it's a reminder that the tool you're vibe-coding in is also part of your attack surface. A leak here isn't your Supabase RLS policy or your Firebase security rules — it's the platform's own access control failing. You can't fix that yourself. You can only keep tools updated and watch for these disclosures.

Don't confuse this with a "public key leak"

We say this every day for a reason: a Supabase anon key or a Firebase web config showing up in your frontend JavaScript is not a leak. Both are designed to be public. The real question is always what those keys are allowed to do — whether Row Level Security is on and correct in Supabase, whether your Firestore/Storage rules actually restrict reads and writes in Firebase.

CVE-2026-12715 is a different category of problem: a genuine authorization bypass inside the platform itself, not a client-side key someone found. Keep those two things separate when you're triaging what a scanner or a bug bounty report tells you.

Builders are starting to review each other's AI

A thread on r/vibecoding titled "What worked for me: making Codex, Claude, Kimi and GLM review each other's fixes" describes a pattern worth copying. The author found that asking the same model to review its own change usually produced agreement, not scrutiny. What worked was: one model implements, a different model reviews with fresh context for code, UX, and security, and every finding gets reproduced by hand before it's trusted or fixed.

That last step is the important one. AI reviewers, like AI coders, can overstate severity or invent problems that don't reproduce. Vercel's "Agent responsibly" post makes the same argument from a different angle: agents generate code at a speed that outpaces judgment, and a PR that looks clean can still encode a wrong assumption that reaches production. Cross-model review, plus manual verification, is a cheap way to catch both kinds of failure — bad code and false alarms — before they ship.

FAQ

Do I need to do anything about CVE-2026-12715?

No. Google patched Firebase Studio on April 15, 2026, and states no customer action is required. This one's closed.

Is a public Supabase or Firebase key ever the actual security problem?

Rarely on its own. The key being visible is expected. The problem is when the rules behind it — Row Level Security in Supabase, Firestore/Storage security rules in Firebase — are missing or too permissive, letting that public key read or write data it shouldn't.

Should I have one AI model review another model's code for security?

It's a reasonable habit, and builders on r/vibecoding are reporting good results with it. Just don't stop there — reproduce each finding yourself before deciding what's real and what's not.

The bottom line

Today's real news is small and already resolved: a Firebase Studio authorization bug, patched, no action needed. The bigger pattern is what builders are doing about AI-generated code they can't fully audit themselves — using a second model as a reviewer, then checking its findings by hand instead of trusting severity labels. That habit matters more than any single CVE.