Next.js 16.3.8 patches a high-severity SSRF and five cache bugs that matter for AI

Vercel shipped Next.js v16.3.8 on September 30, and the release notes list seven security advisories: one high, five medium, one low. The headline item is a server-side request forgery in Image Optimization. The more interesting item, if you build anything that generates content with a model, is the cluster of five cache advisories that sit underneath it.

Read the list again. Four of the five medium-severity bugs are cache problems. “Cache poisoning of SSG and ISR pages in self-hosted Next.js applications” (GHSA-4jqv-mc3x-m676). “Cache poisoning in Next.js SSG/ISR rendering leads to cross-user content substitution and persistent denial of service” (GHSA-mcj8-r9mp-w47p). “Pending use cache fill can leak Draft Mode content into regular responses and persisted pages” (GHSA-3w37-wq28-93x7). “Cache leak across root param values in nested ‘use cache’ functions” (GHSA-h694-7cp9-m8p3). That is not a coincidence. That is a pattern.

The cache layer is now the product

Next.js spent the last two years turning itself from a routing framework into a caching framework. The App Router, React Server Components, use cache, ISR, Draft Mode, dynamicParams: these are all mechanisms for deciding what gets rendered once and served many times. That is exactly the right design for the current web. Rendering is expensive. Serving a cached HTML fragment is cheap. If your page contains a paragraph generated by a large language model, the gap between those two costs is the difference between a viable product and a money pit.

So the framework optimized hard for caching. And now the security advisories tell us what happens when a caching abstraction leaks.

Look at what the advisories actually describe. Cross-user content substitution. Draft Mode content bleeding into regular responses and persisted pages. Cache leaks across root param values in nested use cache functions. These are not exotic memory-safety bugs. They are bugs in the logic that decides which user gets which cached artifact. If a cache key is computed wrong, user A’s page gets served to user B. If a pending cache fill races with a Draft Mode request, unpublished content lands in a public response.

Why this lands squarely on AI apps

For a traditional CMS, cross-user content substitution is bad. For an AI product, it is worse. Consider the shape of a typical AI application in 2026: per-user context (chat history, retrieved documents, a system prompt tuned to the account), a model call that costs real money, and a rendered output that you want to cache so you do not pay for the model call twice. The whole economic case for the product depends on caching that output.

Now read GHSA-h694-7cp9-m8p3 again. “Cache leak across root param values in nested use cache functions.” If your root param is a tenant ID or a workspace slug, and the cache leaks across those values, then one tenant’s generated content can be served to another. That is not a rendering bug. That is a data-boundary failure, and for a lot of AI products it is the boundary that matters most.

The Draft Mode leak (GHSA-3w37-wq28-93x7) is the same story from the other direction. Draft Mode exists so editors can preview unpublished content. If a pending use cache fill pulls that preview content into a persisted page, the unpublished thing becomes public. For a newsroom or an internal AI tool, that is the failure mode you would write a whole incident postmortem about.

The SSRF is the boring one, and that is the point

The high-severity advisory is a server-side request forgery in Image Optimization. SSRF is a well-understood class of bug, and Vercel has patched it before. It matters because Image Optimization is a server-side fetcher: you hand it a URL, it fetches the image. If the URL validation can be bypassed, an attacker can make your server fetch internal endpoints. Every framework that proxies remote resources has had this bug. Next.js is not special here.

What is worth noting is the severity ordering. The SSRF is rated high. The five cache bugs are rated medium. If you run a multi-tenant AI application, that ordering may not match your risk. A cache leak that crosses tenant boundaries is a data exposure, and data exposure in an AI product often means a prompt, a document, or a generated answer that belonged to someone else.

What to do, and what to watch

Upgrade to 16.3.8. That is the whole remediation, and it is cheap. The harder question is whether your own application code has the same class of bug one layer up. If you cache model outputs in Redis, in a CDN, or in your own use cache wrappers, the cache key is your security boundary. Is the tenant ID in it? The user ID? The retrieved-document set? If a request can vary on a value that is not in the key, you have the same bug the framework just fixed.

The low-severity advisory is the one to file away. “Information disclosure in the Next.js development server’s Model Context Protocol endpoint” (GHSA-39w2-rjm5-chcv). Next.js has an MCP endpoint in its dev server. That is a signal about where the framework is heading: the toolchain itself is becoming an MCP server, which means the dev server is now part of the AI agent surface area. It is rated low today. It will not stay low as more agents get pointed at local dev servers.

The pattern across all seven advisories is the same. The web framework is now the place where AI applications decide what to remember, what to serve, and who gets to see it. Vercel patched the framework’s version of that problem. Your application still has its own.

{/* TODO: comment sought from Vercel on the cache-advisory cluster and whether the medium ratings reflect tenant-isolation risk /} {/ TODO: verify current MCP endpoint surface in Next.js dev server and whether it is enabled by default */}