Vibe Coding Radar: Platforms Tighten Access Controls

Two platform changes this week are both about the same question: who is allowed to act as whom inside your app. Vercel shipped a dashboard that surfaces access gaps across every project you run. Lovable let your app's own users connect their own GitHub account instead of sharing one. And a fresh CVE, unrelated to either platform, is a clean case study in what happens when a login check only runs on the client. None of this is about a leaked key. It's about identity and permissions.

TL;DR

• Vercel's Security Dashboard is now generally available on all plans. It flags missing 2FA, long-lived credentials, and other drift across your projects (Vercel).
• Lovable's GitHub connector now supports per-user access, so each person using your published app connects their own account instead of everyone sharing yours (Lovable Changelog).
• Vercel's GitHub App now requests write access to Actions and Workflows, so its coding agent can edit your CI pipeline directly (Vercel).
• CVE-2026-15985 shows what happens when a login flow trusts an OTP code without verifying it against Firebase on the server (NVD).

Vercel's Security Dashboard makes drift visible

Vercel's Security Dashboard is now generally available on every plan, in the UI or via vercel security check in the CLI (Vercel). It flags team members without 2FA and long-lived credentials sitting in your account. Vercel's own note on the release says the quiet part out loud: as coding agents make it faster to spin up projects, small misconfigurations add up. That's true whether your stack is Vercel, Lovable, Bolt, or anything else an AI builder shipped for you. Nobody sets out to leave 2FA off or let a token live forever. It just happens when you're moving fast and an agent is doing the clicking. A dashboard that names the gap is only useful if someone reads it and closes it.

Lovable closes the shared-GitHub-account risk

Until now, Lovable's GitHub API connector worked like most third-party integrations built by AI tools: you connected one account, once, and every visitor to your app shared it. As of August 24, the connector supports per-user access (Lovable Changelog). Each person using your published app now connects their own GitHub account, and the app reads and writes only the repositories, issues, and pull requests that person can already reach. This matters because a shared connection is a single point of failure. If your one connected account has broad repo access, every user of your app effectively inherits it, whether they should or not. Per-user access scopes each action down to what that specific person is allowed to do. If your app touches GitHub on behalf of users, this is worth turning on.

More permissions for agents: read Actions, write Workflows

The Vercel GitHub App now asks for two new permissions on install: read access to Actions, and read-and-write access to Workflows (Vercel). The stated reason is reasonable: it lets Vercel Agent read CI logs to diagnose failures and configure workflow files for you, and it lets v0 generate repositories with working CI/CD out of the box. But write access to Workflows is write access to what runs automatically on every push, including secrets exposure and deploy steps. If you install or re-authorize this app, know what you're granting. An agent with write access to your CI is an agent that can, in principle, change what your pipeline does without a human reading the diff first.

CVE-2026-15985: a reminder that OTP checks belong on the server

This one isn't a vibe-coding platform bug, but it's the clearest lesson of the week for anyone shipping their own login flow. CVE-2026-15985 affects a WordPress plugin, Classified Listing - Mobile Number Verification, up to version 1.6.0 (NVD). The plugin's process_otp_login() function never validates the OTP code against Firebase on the server side. That means an attacker can submit any OTP code and any UID for a phone number already in the plugin's table and get logged in as that user, no correct code required. Nothing about Firebase itself is broken here. The bug is entirely in how the plugin's own code decided whether to trust the request. This is exactly the kind of gap an AI builder can introduce if you ask it for "OTP login" and it wires up the UI without confirming the server actually checks the code against the provider before issuing a session.

FAQ

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

No. A Firebase web config and a Supabase anon key are meant to be public. They ship inside your app's client-side bundle by design, the same way a storefront's address is public. The real risk sits behind them: missing or broken Firestore/Realtime Database rules, or missing Row Level Security policies in Supabase. If either is misconfigured, the public key gives an attacker a working front door. Check the rules and the policies, not the presence of the key.

Should I let my AI coding agent have GitHub Actions write access?

Only if you understand what it changes. Vercel's coding agent now requests write access to Workflows so it can configure your CI pipeline directly (Vercel). That's convenient, but a workflow file can run arbitrary commands with access to your repo secrets. Before granting it, make sure you review workflow changes the same way you'd review any other pull request, and don't let an agent merge its own CI edits without a human looking first.

How do I check if my vibe-coded app's login has a broken server-side check like CVE-2026-15985?

Look at the function that handles your login or OTP submission and ask one question: does it call out to the auth provider (Firebase, Supabase, or otherwise) to confirm the code or token is real, or does it just trust a flag the client sent? CVE-2026-15985 existed because the server accepted any code paired with a known phone number without checking it against Firebase at all (NVD). If your builder generated a similar flow, ask it to show you the exact line that verifies the code server-side. If there isn't one, that's the fix.

The bottom line

Access control, not secret exposure, was this week's real theme. Vercel's dashboard names configuration drift before it becomes an incident. Lovable's per-user GitHub access stops one shared account from becoming everyone's blast radius. Vercel's expanded GitHub App permissions and CVE-2026-15985 both point at the same principle from opposite directions: know exactly what your agents can touch, and make sure your server actually checks what it claims to check.