Security Radar: An Auth Bypass and Agents With Wallets

Two things from today matter more than the usual model-of-the-week noise. One is a real authentication bug, the kind that lets a stranger log in as your admin. The other is a quiet shift in how much AI agents are now allowed to do inside your stack — including spending money.

TL;DR

• A WordPress plugin built on Firebase Authentication had a bug letting anyone log in as any user, including admins, because it never checked if the email was verified before issuing a session (CVE-2026-76793).
• Vercel Connect now lets v0 apps link to 100+ services — Slack, Google, GitHub, Salesforce — through one flow (source).
• Vercel MCP can now make purchases on your behalf, not just write code (source).
• A public Firebase config or Supabase anon key is not a leak by itself. Broken auth logic and over-scoped integrations are the real risk.

An auth bug, not a leaked key

CVE-2026-76793 hit a WordPress plugin that uses Firebase Authentication, not Firebase itself. The plugin matched a login token to a WordPress account by email, but never confirmed that email had been verified first. Anyone could forge that match and walk in as any user, including an admin (NVD).

This is worth sitting with if your AI builder wired up a custom login flow around Firebase Auth, Supabase Auth, or any provider. The lesson isn't "Firebase is unsafe." A public Firebase web config or a public Supabase anon key is meant to be public — that's how those platforms work. The lesson is narrower and sharper: if your app's own code decides who counts as "logged in," that decision has to check identity was actually verified, not just that some field matched. AI builders write this kind of matching logic fast. They don't always add the verification check unless you ask.

Agents are getting more reach

Two Vercel changes point the same direction. Vercel Connect now offers preset OAuth connectors for 100+ services inside v0 apps — Slack, Google, Notion, GitHub, Salesforce — so an agent can wire up an integration in one prompt (source). Separately, Vercel MCP now supports purchases: upgrading plans, buying credits, adding paid add-ons, all through an agent-facing interface (source).

Neither is dangerous on its own. Both raise the stakes of a mistake. An OAuth connector set up with broad scopes gives whatever reads your app's tokens broad reach into Slack or Google, not just your database. An MCP integration that can spend money means a misconfigured agent, or a prompt injection that reaches it, isn't just a bad commit — it's a bill.

What to check this week

• If you built a custom login flow (not the builder's default auth), confirm it checks that the identity is verified before issuing a session — don't just trust a matching field.
• List every third-party connector your app has authorized through Vercel Connect, Supabase integrations, or similar. Check the scopes each one actually needs versus what it was granted.
• If any agent in your stack has purchase or billing permissions, confirm who can trigger that and under what conditions.
• Don't flag a public Supabase anon key or Firebase web config as a leak in your own audits. Look at what's behind it — Row Level Security rules, Firestore rules — not the key itself.

FAQ

Is a public Firebase web config the same as a leaked key?

No. Firebase web config and Supabase anon keys are meant to be exposed in client code — that's how those platforms are designed to work. The actual risk is what's not locked down behind them: missing or broken Firestore rules, or Row Level Security policies that don't restrict access. Calling the config itself a "leak" is the wrong finding.

Can AI agents actually spend money through my app now?

Yes, in at least one concrete case today. Vercel MCP now supports purchases — upgrading plans, buying AI Gateway credits, adding paid features — through an agent-facing interface (source). If an agent in your workflow has access to that, treat it like any other credential: know who can trigger it and why.

Does the Firebase Authentication CVE affect my Lovable, Bolt, or v0 app?

Directly, only if you're running the specific WordPress plugin named in CVE-2026-76793. But the underlying pattern — matching a login token to a user without confirming the email was verified — is a mistake any custom auth flow can make, regardless of platform. If an AI builder wrote your login logic, it's worth a manual check.

The bottom line

Nothing here is a five-alarm fire. A plugin bug got a CVE, and two platform updates gave agents more reach. But both point at the same shift: AI-built apps are wiring themselves into more services and more identity logic than before, faster than most founders can review by hand. Check your auth checks. Check your connector scopes. Don't mistake a public key for a leak, and don't assume a new integration is safe just because it took one prompt to set up.