Next.js 16 'use cache' Migration: Replacing Implicit Caching and unstable_cache Without a Cross-Tenant Leak

The deprecation matters for hiring conversations too. If you are reviewing a codebase that still leans on implicit fetch caching, that is a real migration cost, not a one-line swap.

How does a cached function leak one tenant's data to another?

It leaks when a request-scoped value, like the current user's tenant ID, is read from inside the cached function instead of passed in as an argument. The cache key never sees that value, so the first tenant's result gets stored under a key that the second tenant matches exactly.

Here is the failure, reduced to its core. This compiles, passes a single-tenant test, and ships.

'use cache'
import { cookies } from 'next/headers'
import { db } from '@/lib/db'

// BROKEN: reads tenant from request context inside the cached fn
export async function getDashboardStats() {
  const tenantId = (await cookies()).get('tenant')?.value
  return db.stats.findMany({ where: { tenantId } })
}

The intent is "cache stats per tenant." What actually happens: the function takes no arguments, so its cache key is effectively constant across all callers. Tenant A loads the dashboard, the result is computed and stored. Tenant B loads the same route, hits the same empty-argument cache entry, and gets Tenant A's numbers. No error. No 500. Just one customer looking at another customer's revenue.

This is the bug nobody screenshots, because by the time you notice, the evidence is a confused support ticket, not a stack trace. I have walked into exactly this during an app-rescue engagement, and the team had been blaming a "flaky CDN" for two weeks.

The closure trap is subtle because reading cookies() or headers() inside 'use cache' should be a hard error, and in current 16.x it generally is flagged. But the more dangerous variants slip through: a value captured from a module-level singleton that was set per-request, an ORM client bound to a tenant at import time, or a helper that itself reads context two calls deep. The directive only protects you at the boundary it can see.

What is the correct function-scope-first migration pattern?

Make tenant identity an explicit, serializable argument and resolve all request-scoped values in the caller, never inside the cached function. The cached function should be a pure-ish unit: same arguments in, same data out, with no hidden dependence on who is asking.

// cache.ts, the cached unit knows nothing about the request
'use cache'
import { cacheTag, cacheLife } from 'next/cache'
import { db } from '@/lib/db'

export async function getDashboardStats(tenantId: string) {
  cacheTag(`stats:${tenantId}`)
  cacheLife('minutes')
  return db.stats.findMany({ where: { tenantId } })
}

// page.tsx, the caller resolves identity, then passes it in
import { cookies } from 'next/headers'
import { getDashboardStats } from './cache'

export default async function Page() {
  const tenantId = (await cookies()).get('tenant')?.value
  if (!tenantId) throw new Error('No tenant in request')

  // tenantId is now part of the cache key
  const stats = await getDashboardStats(tenantId)
  return <Dashboard stats={stats} />
}

Now tenantId is a serializable argument, so it participates in the cache key. Tenant A and Tenant B compute and store under different keys. The cacheTag gives you targeted invalidation: when Tenant A's data changes, you call revalidateTag('stats:' + tenantId) and you do not blow away everyone else's cache.

A few rules I hold to during the migration, in order of how often they save me:

• The cached function takes everything it needs as arguments. If it needs the tenant, the tenant is a parameter.


• Resolve cookies(), headers(), auth(), and any session lookup in the caller, above the cache boundary.


• Every argument that distinguishes one tenant from another must be serializable. Functions, class instances, and bound clients do not serialize, so they do not key correctly.


• Tag with the tenant ID so invalidation is surgical.

What about the May 2026 cache-poisoning advisory?

The 7 May 2026 advisory, fixed in 16.2.6, is a separate class of problem from the closure bug, but they compound, so treat the patch as non-optional before you trust any caching layer. Upgrade to 16.2.6 or later first, then audit your own cache keys.

The distinction is worth keeping straight. The closure leak is a mistake in your code: you forgot to key on the tenant. Cache poisoning is a framework-level issue where an attacker can influence what gets stored under a cache entry through crafted requests. If you have both an unpatched runtime and sloppy cache keys, you have given an attacker a much larger surface, because now untrusted input can decide what fills a cache that you are also mis-keying.

My sequencing on every project right now:

1. Pin to 16.2.6 or later. Do not migrate 'use cache' on an older 16.x and assume you will upgrade "soon."


2. Re-run the function-scope audit below against the patched runtime.


3. Only then turn cacheComponents on in production.

What does a multi-tenant cache audit checklist look like?

Grep for the directive, then for every cached function ask one question: does this function's output depend on anything not in its argument list? If yes, you have a leak waiting to happen. Here is the checklist I run, top to bottom.

First, find every cache boundary.

## every file that opts into caching
rg -l "['\"]use cache['\"]" --type ts --type tsx

## every legacy call still to be migrated
rg -n "unstable_cache" --type ts --type tsx

Then, for each 'use cache' function, walk this table.