Is Your AI-Built App Exposed? Next.js Just Got 12 New CVEs

Last week, the team behind Next.js (the framework most AI coding tools default to) disclosed twelve security holes. Three of them are bad. The worst lets a stranger walk past the front-door check on your app without logging in. No password, no exploit kit, no skill. Just a malformed link.

If your product was built by an AI tool, or by a developer who used one heavily, your app is almost certainly running Next.js. There is a good chance you are exposed. The fix is a one-line dependency update, but somebody on your side has to actually do it.

The four issues that matter

The auth bypass. Attackers can sneak past the gatekeeper code that protects your private routes. Dashboards, admin panels, anything behind a login. (CVE-2026-44574, middleware bypass.)

The internal network probe. Apps that handle real-time connections (chat, live updates) can be tricked into making requests to your internal infrastructure on the attacker's behalf. (CVE-2026-44578, SSRF via WebSocket upgrade.)

The XSS through the safety mechanism. A security feature called CSP nonces, designed to block injected scripts, becomes the attack vector itself. (CVE-2026-44581.)

The crash bug. A crafted HTTP request hangs the server. Site goes down. (CVE-2026-23870, denial of service.)

Patches are in Next.js 15.5.16 and 16.2.5, plus the matching react-server packages.

A firewall does not save you

Cloudflare published blocking rules for the crash bug, but stated openly that several of the others cannot be safely blocked at the firewall layer. A firewall matches known bad patterns. The auth bypass is a normal-looking link the framework misinterprets. The fix has to live in the framework code.

Why vibe-coded apps are extra exposed

If your app was built by prompting an AI, three things are usually true:

1. It is on Next.js with the App Router. Every major AI coding tool defaults to that.
2. Authentication is in middleware. That is the standard pattern AI tools generate.
3. Nobody on your team is watching the Next.js changelog.

The first two mean the bugs apply to you. The third means nobody will tell you.

What to do this week

If you are a founder, ask your developer:

1. Are we on Next.js 15.5.16 or 16.2.5 yet?
2. After we update, are we redeploying to production today?
3. Are we rotating secrets that may have been reachable through the auth bypass?
4. Can someone outside our team verify the patched build is actually live?

If you are shipping the code:

1. Bump Next.js to 15.5.16 or 16.2.5.
2. Bump react-server-dom-webpack, parcel, and turbopack to 19.0.6, 19.1.7, or 19.2.6.
3. Audit middleware for routes relying on path-shape assumptions.
4. Review any WebSocket upgrade handling for user-controlled outbound requests.
5. Rotate secrets an unauthenticated request could have reached.
6. Confirm the deployed build runs the patched version, not just the lockfile.

Step six catches most of the misses. A bumped package.json is not the same as a patched build serving traffic. We see that gap constantly.

The pattern

Third major React Server Components disclosure in six months. The trust boundary moved when RSC shipped, and the ecosystem is still finding the edges.

The auth bypass needs no credentials, no exploit kit, no skill. It is a route parameter.

Patch this week. If you are not sure who is responsible for that on your side, that is the actual problem.