--- title: "Seven fixes in Next.js 16.4.5: who needs to update today?" description: "Next.js 16.4.5 and 15.5.29 close seven flaws, including a cache that can hand one tenant's data to another and HttpOnly cookies readable on Edge routes. Update, then see which ones touch your app." url: https://ihsanalapsi.dev/articles/nextjs-16-4-5-security-release lang: en date: 2026-11-05 updated: 2026-11-05 tags: ["Security updates", "Web development", "App security"] author: Ihsan Alapsi (إحسان العبسي) --- # Seven fixes in Next.js 16.4.5: who needs to update today? If your Next.js app serves more than one customer from the same server, or sets the session cookie from an Edge route, this update is for you. The [Next.js November security release post](https://nextjs.org/blog/november-2026-security-release) says the fixes are out in v16.4.5 (Active LTS) and v15.5.29 (Maintenance LTS). By the end of this article you will know which flaw touches your app, and how to update with two commands. ## What does Next.js 16.4.5 fix? Next.js 16.4.5 and 15.5.29 close seven security flaws, and each one needs a specific setup in your app before it can affect you. This is how they split, per the official post: | Flaw | Who is affected | | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Cache handed to another tenant when a `use cache` function is called both directly and from inside `unstable_cache` | Cache Components apps whose cached function reads a root parameter, such as a tenant identifier | | Content for one root parameter value served for another in nested `use cache` functions | Cache Components with cached functions nested inside each other | | Different binary arguments producing the same cache identity | Apps passing binary arguments that tell users apart to `use cache` | | A shared page shell poisoned by an unauthenticated request | Self-hosted `next start` with Cache Components and Partial Prefetching disabled or unset | | A response delivered to the wrong client | Self-hosted apps returning a fetched `Response` unchanged, behind an HTTP/1.1 reverse proxy that queues pipelined requests on a shared connection | | An `HttpOnly` cookie value in the `x-middleware-set-cookie` header | Edge routes that set cookies with `NextResponse.cookies.set()` | | An SVG image passing as AVIF despite `dangerouslyAllowSVG: false` | Image Optimization with a backend that can decode SVG | If no row looks like your app, updating is still the safer move, because it is easier than checking every condition on its own. ## Why is the cache flaw the worst one for SaaS apps? The cache flaw can let one customer see another customer's data, because a cached result made for one tenant can be stored and returned to another with the same arguments. According to [advisory GHSA-mfr8-8qww-v76h](https://github.com/vercel/next.js/security/advisories/GHSA-mfr8-8qww-v76h), published on Nov 3, 2026, affected versions are 16.3.0 and later. The problem happens during a cold cache fill: two requests at the same moment, one direct and one from inside `unstable_cache`, and the second can receive the first one's result without checking its root parameters. The wrong result then stays in the cache and is served to every request with the same arguments until it is revalidated or evicted. The mistake here is one of logic more than code: the second request looks up a result with the same arguments and takes it without checking which tenant it was made for. So the result looks right and belongs to the wrong customer. The advisory itself says that not nesting a `use cache` function inside `unstable_cache` is a complete workaround if you can't update now. ## What is the HttpOnly cookie issue on Edge routes? Edge routes that set a cookie with `NextResponse.cookies.set()` copied the cookie into an internal header named `x-middleware-set-cookie`, and JavaScript on the same site can read that header. So the `HttpOnly` flag, which you set to keep JavaScript away from the session cookie, no longer protected it on those routes. According to [advisory GHSA-f3mh-rxg3-f5g2](https://github.com/vercel/next.js/security/advisories/GHSA-f3mh-rxg3-f5g2), the flaw affects App Router Edge Route Handlers and Pages Router Edge API routes. The official post makes clear it is not a way to run code on its own: the attacker needs JavaScript already running on the same origin, meaning a separate XSS bug. In the reproduction, Node.js Route Handlers and cookies set through `cookies().set()` were not affected. If you want to check the rest of your session cookie settings, we have an article on [checking session cookie flags: HttpOnly, Secure and SameSite](/articles/session-cookie-flags-check). ## How do you know if your app needs the update? Your app needs the update if its `next` version is older than the fixed version on its branch. In order: 1. Open the project folder and see which version is actually installed: ```bash npm ls next ``` 2. Update to the fixed version on your branch, as the post says: ```bash npm install next@16.4.5 npm install next@15.5.29 ``` The first is for the 16 branch and the second for 15.5, not both. 3. Search your code for the places these flaws touch, so you know what to test after the update: ```bash grep -rn "use cache\|unstable_cache\|cookies.set\|dangerouslyAllowSVG" app pages src ``` 4. Build and deploy, then test the pages the search found, especially the ones that show tenant data. ## Where should you start now? Start with the app that serves more than one customer, or the one that sets the session cookie from an Edge route: those lose the most if they wait. And if you read about the [previous Next.js security update](/articles/nextjs-16-4-1-security-update), this one comes after it, so the version you moved to then is not enough. If your app keeps customer data apart and you are not sure that wall holds, [a penetration test with Muhassan](/muhassan) tries those limits the way an attacker would. Which `next` version is running in your production right now? ## FAQ **If my site runs on Vercel, do I still need to update?** Yes. The fix is in the next package version in your project, so you need to bump it and deploy again. Two of the seven flaws only affect self-hosted apps. **My app never uses use cache. Am I safe?** From the cache flaws, yes, but the release fixes others too: cookies on Edge routes, image optimization, and self-hosted apps. Updating is easier than checking each one. **Is there a workaround for the cache flaw if I can't update now?** Yes. The advisory says that not nesting a use cache function inside unstable_cache is a complete workaround. That covers the first flaw only; the others need the update.