Seven fixes in Next.js 16.4.5: who needs to update today?
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.
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 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 | 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 | 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 |
A shared page shell poisoned by an unauthenticated request | Self-hosted |
A response delivered to the wrong client | Self-hosted apps returning a fetched |
An | Edge routes that set cookies with |
An SVG image passing as AVIF despite | 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, 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, 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.
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:
Open the project folder and see which version is actually installed:
npm ls nextUpdate to the fixed version on your branch, as the post says:
npm install next@16.4.5 npm install next@15.5.29The first is for the 16 branch and the second for 15.5, not both.
Search your code for the places these flaws touch, so you know what to test after the update:
grep -rn "use cache\|unstable_cache\|cookies.set\|dangerouslyAllowSVG" app pages srcBuild 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, 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 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.
