Next.js November fixes: check tenant caches and Edge cookies

If your app uses Next.js, review the November security fixes against its cache and cookie paths, then verify the deployed build. Next.js identifies 16.4.5 and 15.5.29 as the releases containing these fixes. A successful sign-in does not establish that one customer’s cached content stays separate from another’s.

For Netlify deployments, there is a second component to check: the Next.js adapter. Updating the framework alone can leave its Middleware cookie case unresolved.

This guide covers the November 3 release, following the October 27 advance notice. Sources were checked November 10 UTC. It remains useful for apps whose update, cache cleanup or verification is unfinished; this is not a claim of a newly discovered breach. The checks below are editorial recommendations and synthetic examples, not tests we ran against affected applications.

Start with the patch line and the affected feature

The maintainer’s 16.4.5 release record lists seven security fixes. Its 15.5.29 record lists the response-framing, SVG and Edge-cookie fixes. Do not assume every issue affects both lines.

Those are identified fix releases, not a claim that they are the newest versions available. Choose an appropriate compatible release after checking current maintainer guidance. Do not downgrade a newer reviewed deployment to match a number in this article, or change major versions solely to follow an example.

Have the implementation owner make a short applicability table:

Record “unknown” when the generated code or deployment configuration has not been reviewed. A platform name, working preview or dependency declaration is not an answer to these questions.

Three cache paths deserve separate review

The mixed-cache advisory covers Next.js 16.3.0 through 16.4.4 and identifies 16.4.5 as patched. It describes the same root-parameter-reading use cache function being called directly and through unstable_cache(). A cold-fill race can place one routing context’s result into an entry later used by another. The advisory calls that nesting unsupported and says avoiding it is a workaround for this issue.

That workaround does not close the other cache advisories. The nested-cache issue, affecting 16.2.0 through 16.4.4, involves an inner function returning ready data alongside pending asynchronous values. Root-parameter dependencies can be recorded too late for the outer entry. It is fixed in 16.4.5. The incorrectly reused content is generated by the application; the advisory does not describe arbitrary attacker-supplied response content.

The binary-argument issue affects 16.0.0 through 16.4.4 and is also fixed in 16.4.5. Distinct binary arguments, such as Uint8Array or Blob values, can produce matching cache keys. That matters when the application relies on those values to separate accounts or users.

Ask your coding assistant to trace each relevant call from the authenticated request to the cached function and back. Require file locations and a plain explanation of which values separate customers. Keep this review scoped to actual call paths; replacing one cache wrapper everywhere without understanding the data flow can introduce unrelated defects.

Framework patching and application authorization are separate checks. Continue to verify the server’s permission decision before it returns private data. Use the existing vibe-coding security checklist for that broader review, while tracking this framework update as its own task.

Build a tenant-isolation check with fake records

Use an isolated test environment containing no customer data. Create two test tenants with ordinary test users and deliberately different records: for example, Tenant Amber sees AMBER-ONLY, while Tenant Birch sees BIRCH-ONLY.

First establish the expected behavior without relying on the cache. Each account should receive only its allowed record, and an unauthenticated request should follow the application’s intended access policy. If that fails, resolve the application permission problem as well as the dependency update.

Then exercise the real cached page or API through both accounts. Include a fresh deployment or test cache state, repeated requests after entries are populated, and overlapping requests where your test harness supports them. Reverse which tenant requests first. Check the returned data, not just the HTTP status or whether the page loaded.

These are regression checks, not a reliable exploit detector. A passing sequence does not prove that every timing condition was exercised. Retain the patched-package evidence and the code-path review alongside the results. Never use another customer’s account or real records to create a dramatic demonstration.

Check Edge cookies without exposing session values

The cookie advisory identifies affected releases from 15.0.0 through 15.5.28 and 16.0.0 through 16.4.4, with fixes in 15.5.29 and 16.4.5. It concerns Edge routes setting cookies through NextResponse, including App Router handlers and Pages Router Edge API routes. A duplicate internal response header can expose an otherwise HttpOnly cookie value to same-origin JavaScript.

The release explanation requires a sensitive cookie on the affected response and attacker-controlled JavaScript already running on that origin. This is not an independent JavaScript execution vulnerability. Its reproduced leak did not affect Node.js Route Handlers or cookies().set() routes.

Inventory the responses that actually issue sensitive cookies: sign-in, refresh and account transitions where applicable. Have the owner identify the runtime and cookie-setting API for each. Do not infer that a route is safe simply because another route in the same application uses Node.js.

For a controlled check, issue a harmless synthetic cookie through the relevant test route. Inspect whether its marker is duplicated in x-middleware-set-cookie in the response visible to the test client. Keep real sessions out of the fixture and redact cookie values from screenshots and logs. Preserve the required cookie attributes and intended sign-in behavior when checking the patched route; removing HttpOnly is not a remediation.

If you find evidence of an actual sensitive-cookie exposure, involve the authentication owner to assess session invalidation and incident handling. This advisory alone does not establish that a session was stolen or that every user needs the same recovery action.

Netlify owners have adapter and cache work too

Netlify’s November 3 guidance recommends upgrading Next.js and redeploying, plus adapter @netlify/plugin-nextjs 5.16.6. Its default auto-installed adapter picks up the update on redeployment; a pinned adapter needs an explicit update. Netlify says the Middleware cookie case requires the adapter fix.

Its cache guidance is also specific: a new deployment clears previous cached content in the same deploy context. Production, branch deployments and Deploy Previews need separate attention. Responses opted out through Netlify-Cache-ID remain cached after deployment and need an explicit purge. Review retained public previews as well.

Netlify also documents exclusions for some issues and conditions for others. Do not turn those statements into an assurance about every host. Record the host’s actual configuration, adapter and affected deployment contexts.

Give the other three issues an owner

Even if caches and cookies are your immediate concern, do not mark the whole release assessed without checking the remaining paths:

• Fallback-shell poisoning requires a specific self-hosted Cache Components route shape with Partial Prefetching disabled or unset. The described effects include persistent 404s or substituted parameters, not demonstrated data disclosure or script injection.
• Response framing concerns fetched responses forwarded unchanged behind an HTTP/1.1 proxy that queues pipelined responses. Ask the hosting owner about that behavior; “we use a reverse proxy” does not settle applicability.
• SVG rejection bypass reaches a parser the self-hosted image optimizer was configured to exclude. The release explanation preserves the image-source allowlist requirement and does not demonstrate XSS or remote code execution from this finding.

Use ordinary functional tests for relevant pages, responses and permitted images after updating. Do not reproduce malformed-request attacks against production to fill out the checklist.

Close the task with evidence from the deployed app

Record the resolved Next.js package version in the built application, its deployment identifier, the hosting mode and applicable advisories. A read-only package-tree check such as npm ls next --all can help in an npm workspace, but a result from your laptop does not identify the artifact serving users. Obtain the deployment’s own dependency evidence from its controlled build or operational records.

Attach the cache review, synthetic tenant results, cookie-route checks and any host-specific cleanup receipt. Give retained previews and the approved recovery deployment their own status. Do not add a public diagnostic endpoint or dump environment variables just to collect evidence.

These checks establish what was updated and what behavior was observed. They do not establish that no historical disclosure occurred, and a clean external scan cannot replace deployed-version evidence. Keep unresolved applicability, cache retention and incident-response questions assigned to an owner before considering the work complete.