Next.js patches 13 vulnerabilities in security release

What happened

Vercel shipped a coordinated security release on May 7 covering 13 advisories across Next.js and React. The vulnerabilities span five categories: middleware and proxy bypass, denial of service, server-side request forgery, cache poisoning, and cross-site scripting. One advisory tracks an upstream React Server Components vulnerability as CVE-2026-23870.

Patched versions are Next.js 15.5.18 and 16.2.6. On the React side, the react-server-dom-* packages (parcel, webpack, turbopack) are fixed in 19.0.6, 19.1.7, and 19.2.6. All Next.js 13.x and 14.x users must upgrade to at least 15.5.18 or 16.2.6. There is no backport. This is a major version jump that requires React 19 and may include breaking API changes, so review the official upgrade guides before deploying to production.

Vercel explicitly stated that WAF rules cannot block these issues. The vulnerabilities sit deep in the request routing pipeline, not at the input validation layer.

Why it matters

Four of the five middleware and proxy bypass advisories are rated High; the fifth (middleware redirect cache poisoning) is rated Low. Per the Vercel advisory, these affect any application that relies on middleware.js or proxy.js for authorization. For SEO practitioners, that means sites using proxy to gate content behind paywalls, subscription checks, or bot-detection logic.

The segment-prefetch bypasses are the most SEO-relevant. They allow requests to reach protected content paths without triggering the auth middleware. Robots.txt is fetched independently by the crawler and would still be honored. If you’ve Disallowed those paths, compliant bots like Googlebot won’t request them. The real exposure is meta robots tags and other response-level signals. If your middleware served a noindex header or a login redirect on protected paths, the bypass skips that logic and serves the gated content directly. Googlebot can then index pages that should have been protected.

Consider an e-commerce site checking subscription status in middleware before serving /products/premium-inventory. The segment-prefetch bypass lets a crawler fetch that path without hitting the auth check. Private SKUs get indexed. Because the bypass serves a normal 200 response, the exposure may only become apparent through manual crawling or by noticing protected URLs appearing in site: queries.

The cache poisoning advisories compound the problem. If a protected resource gets fetched via the bypass, your CDN may cache that response. Subsequent requests from any user or bot then receive the cached protected content. One advisory notes that middleware redirects can be cache-poisoned: a legitimate /protected → /login redirect gets replaced with an attacker’s response. Crawlers hitting the poisoned cache encounter redirect chains that waste crawl budget or follow redirects to attacker-controlled URLs. If your site uses aggressive HTTP caching with long TTLs, the poisoned responses persist longer.

The DoS vulnerabilities matter for crawl reliability. CVE-2026-23870 is a denial-of-service vulnerability in React Server Components, while a separate Cache Components issue causes DoS via connection exhaustion. In a DoS scenario, server unavailability could cause crawlers to time out, potentially delaying indexing of new content.

The two XSS advisories affect apps using CSP nonces in App Router or beforeInteractive scripts consuming untrusted input. These are less directly SEO-impactful but still relevant for sites that inject nonces into server-rendered responses.

What to do

Patch immediately. Update Next.js to 15.5.18 or 16.2.6. Update react-server-dom-webpack, react-server-dom-turbopack, and react-server-dom-parcel to the latest patched version for your React release line (19.0.6, 19.1.7, or 19.2.6).

Check both dependencies. If your bundler pins a specific version of react-server-dom-*, the Next.js upgrade alone won’t fix CVE-2026-23870. Verify your lockfile includes the patched React packages.

Audit for prior exploitation. Search Google using site:yourdomain.com for URLs that should be behind authentication. Check Search Console’s indexed pages report for protected paths that shouldn’t appear. If you find indexed protected content, request removal and purge your CDN cache for those URLs.

Purge your CDN cache after patching. Cache poisoning means stale or malicious responses may persist even after the code fix is deployed. If you use ISR, consider triggering a full revalidation rather than waiting for individual paths to expire.

Don’t rely on middleware alone for auth. The server/client boundary in RSC is still maturing. Defense-in-depth matters. Use signed cookies, JWTs, or HTTP-only tokens validated at the data layer, not just at the routing layer.

Test locally before deploying. Attempt to access protected routes directly to confirm the segment-prefetch bypass is closed in your patched build. Verify that protected paths return the expected auth response rather than serving gated content.

Related: If your Next.js site uses streaming, check whether streaming metadata is reaching Google’s index correctly.

Watch out for

Silent bypass. Because the segment-prefetch bypass skips middleware rather than triggering an auth failure, protected content may appear in search indexes or CDN cache entries without obvious error signals. Actively check for indexed protected URLs rather than waiting for errors to surface.

Coordinated dependency updates. Patching Next.js without also updating react-server-dom-* leaves the upstream RSC vulnerability (CVE-2026-23870) open. Both packages must be updated in the same deploy cycle. Check your lockfile explicitly.