The Next.js Dev Server Now Has an Attack Surface of Its Own: What the MCP Endpoint Patch Actually Changes

On September 30, Next.js shipped 16.3.8 and 15.5.27 with fixes for seven vulnerabilities. Six of them live in production code paths. The seventh — CVE-2026-94486 — lives in the Model Context Protocol endpoint of the development server, and it lets any website a developer opens in their browser read the project's location on disk, the route inventory, source snippets from error reports, and the dev logs. Vercel rated it Low (2.3/10) because production never serves that endpoint. That rating is written for a human with a browser tab open. It stops being the whole story the moment next dev runs unattended next to an AI agent for hours.

That is the direct answer. What follows is the real triage of the seven vulnerabilities, why the lowest-severity one says the most about how we work now, and the rules we apply every time an agent touches a development server.

What shipped on September 30 (and why the 29th didn't count)

The official Next.js advisory confirms the two patched versions: npm install [email protected] for Active LTS and [email protected] for Maintenance LTS. One detail plenty of teams missed: the day before, Vercel published 16.3.7 with a bug fix that did not include the security fixes — the advance notice explained the release had been held up by an upstream dependency. If your patching process says "bump to whatever is latest" on Monday morning, you bumped to a version that doesn't protect you. This is the second consecutive release where our patch runbook pays for itself: version inventory on announcement day, staging the same day, production inside the 24-hour window.

The breakdown of the seven matters, because roughly half of them don't apply to everyone:

Look at the last row. It's the only Low in the batch, and the only one that treats the development environment as a product with attacking users.

What the MCP endpoint can actually do

According to the GHSA-39w2-rjm5-chcv advisory, the MCP endpoint exposed by next dev does not verify which website a request originates from. The attacker doesn't need a path into the port over the network: the developer visits a malicious site, and that site — from the victim's own browser, against localhost — talks to the endpoint and walks away with four concrete things: the project's location on disk, source snippets from error reports, the route inventory, and the development logs. The advisory marks affected versions as >= 16.0.0, patched in 16.3.8, severity Low, CVSS 2.3.

In the classic threat model, "developer visits a sketchy site while the dev server is running" sounds minor. In 2019, it was. The problem is who spends those hours next to next dev today.

Why the "Low" rating understates it

Three signals that the development server is no longer a local toy:

Frameworks are building it as agent infrastructure. Astro 7's official announcement didn't just add astro dev --background: Astro now detects when it's running inside an AI agent and enables background mode automatically, with no flags, and turns on JSON logging so the agent can read the output. That's a deliberate product decision — the dev server becomes a system that talks to machines, not only to humans. When a system talks to machines, its endpoints get audited the way production endpoints do.

Agents already live inside our own pipeline. We publish this very blog through an agent-assisted pipeline — four crons that propose, generate, validate and publish bilingual articles — and the first layer of our guardrail architecture is scoped identity with minimum privilege. An origin-unverified endpoint on the dev server is the exact opposite: broad access with no identity to check. In our vibe coding security analysis we already documented that 45% of AI-generated code carries OWASP Top 10 flaws; this week's CVE shows the risk isn't only in the code the agent writes, but in the process the agent keeps alive.

The real exposure path isn't localhost. Nobody actually works in localhost only: previews get shared with clients, dev servers get tunneled with cloudflared or ngrok for a quick review, and some teams bind to the LAN to test on a device. Each of those decisions turns a "development" endpoint into a reachable one.

The exposure model we apply

Path A is what the "Low" severity takes for granted, and it's the most common one: the attacker never touches the network, they ride the victim's browser. Path B is the one I see most often in agencies — the "here's a link so you can take a look" — and the one that turns a development CVE into an incident.

The verification checklist fits in five lines:

1. npx next info — are you on 16.3.8 / 15.5.27? If not, upgrade today; it's one npm install.
2. ss -ltnp | grep -E '3000|3001' — what process is listening, and on which interface?
3. Is any tunnel (cloudflared, ngrok, frp) pointed at that port this week?
4. Does your config mix images.remotePatterns, a root-level catch-all, or Cache Components? Each one triggers a different advisory from the table.
5. After the upgrade: flush SSG/ISR caches and revalidate Draft Mode previews. Patching without purging just moves the problem.

What this is not

This isn't "Next.js is insecure." Vercel's process — an announcement 24 hours ahead, advisories with CVE and GHSA IDs, both LTS lines patched in parallel — is the standard every framework should aspire to; we wrote that in our August runbook and we're still using it. Nor is it a reason to kill the dev server and work against production: the same configuration discipline we already apply to Astro applies here — the development environment gets configured to production standards, because in 2026 the difference between the two is who has the session open.

The signal this week is different: the endpoint Vercel rated Low is the first of its kind, not the last. As agents settle into the development loop, expect more advisories that affect next dev and not next start. The useful question isn't whether your development server was in this week's seven-row table — it's whether you'd know within 24 hours if it were.