Next.js Patches, Cursor 0-Day, Lovable Locks Down Access

Three things moved today that matter more than the usual feature drop: a coordinated Next.js security release, a Cursor zero-day that went to full public disclosure, and a Lovable change that quietly fixes a real access-control problem for multi-tenant apps. None of this is exotic. All of it is worth ten minutes of your time.

TL;DR

• Next.js shipped 13 security advisories in one release, including an upstream React Server Components flaw tracked as CVE-2026-23870. If your app runs on Next.js, update now.
• A Cursor zero-day was written up under the title "Full Disclosure Becomes the Only Protection Left" and hit 300+ points on Hacker News — a reminder that your editor is part of your attack surface too.
• Lovable's new App user connectors let each signed-in user connect their own third-party account instead of everyone sharing one connection — a real fix for a real multi-tenant risk.
• Vercel open-sourced deepsec, an agent-powered scanner you can run against your own codebase, on your own machine.

Next.js patched 13 issues in one release

The May 2026 Next.js security release covers 13 advisories spanning denial of service, middleware and proxy bypass, server-side request forgery, cache poisoning, and cross-site scripting. One of them is an upstream React Server Components vulnerability, CVE-2026-23870.

If your app was built with v0, Bolt, or exported from Lovable and deployed on Vercel, there's a decent chance it's running Next.js under the hood, even if you never wrote a line of it yourself. Patched versions are already out. Redeploy on a current version and move on — this is the kind of fix you apply once and stop thinking about.

A Cursor zero-day, disclosed in public

A writeup called "Cursor 0-day: When Full Disclosure Becomes the Only Protection Left" climbed to over 300 points on Hacker News. The title tells you the shape of the story: a vulnerability in Cursor, and a decision to go public rather than sit on it quietly.

The lesson for founders isn't about this specific bug. It's that your AI coding tool — Cursor, Windsurf, Claude Code, whatever you use — is software with its own vulnerabilities, running with access to your source, your credentials, and often your terminal. Keep it updated. Don't treat the editor as a trusted black box just because it's the thing writing your code.

Lovable narrows who can act as whom

Lovable's new App user connectors let each person using your published app connect their own account — their own inbox, their own calendar, their own CRM — instead of the app sharing one connected account across every visitor.

That second pattern, one shared connection for all users, is a common vibe-coding mistake. It means every user of your app can see or act on data that belongs to someone else, because the app never distinguished between them at the permissions layer. If you built a multi-tenant app in Lovable and connected a single third-party account for everyone, this is the fix. Switch to per-user connectors before you scale.

New tooling: deepsec and sandbox controls

Vercel also open-sourced deepsec, a security scanner powered by coding agents that you run on your own machine against your own codebase, using a Claude or Codex subscription you already have. Alongside it, Vercel Sandbox firewall now supports request proxying and filtering and Postgres connections, and integration credentials can now be locked to production-only access. None of these are things a non-technical founder needs to configure by hand today, but they signal where the platform is investing: locking down what agents and sandboxes can reach.

FAQ

Do I need to worry about the Next.js CVE if an AI builder wrote my app?

If your app deploys on Vercel and uses Next.js underneath — common for v0 and many Lovable exports — yes. Redeploy on a current, patched version. You don't need to understand the CVE, just confirm you're not on an old build.

Is a public Supabase anon key or Firebase web config in my code a leak?

No. Both are meant to be public — they identify your project, not your data. The actual risk is what happens after that key reaches your database: missing or misconfigured Row Level Security in Supabase, or open Firestore/Realtime Database rules in Firebase. Check those, not the key's visibility.

What should I actually do about the Cursor zero-day?

Update Cursor to the latest version and keep auto-update on. There's no evidence here of a public exploit against typical vibe-coded apps — this is about keeping your tools current, the same discipline you'd apply to any software with access to your code and credentials.

The bottom line

Today's changes are mundane on the surface and useful underneath: patch Next.js, keep your editor updated, and if your app lets users log in and connect accounts, make sure each user connects their own — not one shared login for everyone. None of this requires a security background. It requires ten minutes and a checklist.