Missing Role Checks: This Week in Vibe-Coding

This week's clearest security lesson didn't come from a builder platform update. It came from a CVE. An open-source CRM shipped an admin panel where the app never checked who was asking. That single missing check is the same mistake we see over and over in AI-generated code, and it's worth checking for in your own app today.

TL;DR

• CVE-2026-47129: NextCRM's activateUser and deactivateUser Server Actions never checked for an admin role. Any logged-in user, including a plain "viewer," could disable any account, including the admin's. Fixed in version 0.12.0.
• Lovable's Project Monitoring is now in beta: Lovable checks your app's code and visitor errors on a schedule and flags findings to the project owner.
• Vercel published guidance on security boundaries in agentic architectures: most coding agents today run generated code with full access to your secrets.
• Vercel Sandbox and Supabase's CipherStash integration both shipped ways to keep raw secrets and sensitive data out of code paths.

The bug: a check that never happened

NextCRM's activateUser and deactivateUser actions had one job: confirm the caller is an admin before touching another account. They didn't. Any authenticated user, at any role, could flip another account on or off, including the admin's.

This is a Broken Access Control bug, and it's the single most common flaw we see in AI-generated apps. Here's why. When you ask an AI builder to "add an admin panel to deactivate users," it writes the button, the form, the database call. It usually does not write "and confirm the caller is actually an admin," because that instruction was never explicit. The happy path works. The security path is silent.

Next.js Server Actions make this worse, not better. A traditional API route is a URL you can list and eyeball. A Server Action is a function call embedded in your component tree. There's no obvious inventory of "here are all the privileged actions in my app." If you didn't ask your AI tool to add a role check, there's a good chance it isn't there.

What to do: list every action in your app that only an owner or admin should trigger — deactivate a user, delete a record, change a plan, export data. For each one, confirm the server code checks the caller's role before doing anything, not just that the UI hides the button from other users. Hiding a button is not a security control.

Platforms are starting to watch for this

Lovable's Project Monitoring, now in beta on Pro, Business, and Enterprise, has Lovable review your project's code and recent visitor errors on a schedule. When it finds something important, editors see it above chat and the owner gets an email. It's opt-in per project, but it's a sign that "AI wrote it, nobody reviewed it" is now a recognized gap even the builders are trying to close.

Vercel made a parallel move on the audit side. Activity log now tracks 100% of team and project changes, adding 88 new tracked events, and the Developer role is now available on Pro teams, not just Enterprise, so you can let someone deploy without handing them full environment variable visibility. If you've been running your team with everyone as an Owner because that was the default, this is a reason to reconsider.

Secrets are the next fight

Vercel's post on security boundaries in agentic architectures says the quiet part out loud: most agents today run generated code with full access to your secrets. As agents read filesystems, run shell commands, and write and execute their own code, they've become multi-component systems where each part deserves a different level of trust — but most teams still run it all in one context, because that's how the default tooling works.

Two concrete responses to that showed up this week. Vercel Sandbox can now inject credentials directly into HTTP headers for outbound requests, so an agent-generated script can call an authenticated API without the API key ever existing inside the sandbox it's running in. And Supabase's new searchable field-level encryption via CipherStash lets you encrypt specific sensitive columns so that even if your Row Level Security policy is wrong, that column is unreadable without the key.

Neither of these is about a leaked key. They're about reducing what a compromised agent, a bad policy, or a copy-pasted script can actually reach.

FAQ

Is a public Supabase anon key or Firebase config a leak?

No. Both are meant to be public and ship in your app's client bundle by design. The real risk is what they're allowed to touch: a missing or too-permissive Row Level Security policy, or open Realtime/Storage rules. Check policies, not key presence.

My AI builder generated an admin panel. Is it safe?

Treat it as unproven until checked. The NextCRM CVE (CVE-2026-47129) shows exactly the failure mode: admin-only actions with no server-side role check. Test it yourself — log in as a low-privilege user and try to hit every admin action directly. If it works, it's broken.

What's a Server Action, and why does it matter for security?

It's a Next.js pattern that lets a form or button call server-side code directly, without a separate API route. That convenience means there's no obvious list of "privileged endpoints" to review. If you're on Next.js, ask specifically whether each Server Action checks the caller's role — don't assume it inherited one from elsewhere in the app.

The bottom line

The NextCRM CVE is a reminder, not a novelty: AI-generated code builds the feature and skips the guard rail unless you ask for the guard rail by name. Builders are responding — Lovable is starting to watch your code for you, Vercel is tightening who can see what on a team, and both Vercel and Supabase are shrinking what a compromised process can actually reach. None of that replaces checking your own admin actions this week.