Fix Next.js 16.2.6 Bfcache Back-Button Freeze

Last updated: July 2026

TL;DR

Next.js 16.2.6 breaks bfcache restoration on client-side navigation. Hit the browser's Back button after a route change. The page restores instantly. But every script goes dead. No clicks work. No errors show in the console.

It only started after upgrading to 16.2.6. Rolling back to 16.2.5 removes it right away.

• Root cause: the router fails to reattach to next/script and Route Handler state during bfcache restore

• Two fixes: pin to next@16.2.5, or add a pageshow/persisted listener that forces router.refresh()

• If you pin back to 16.2.5, check your CVE-2026-23870 patch status first

You ship a client-side route change. It looks fine. You click Back.

The page snaps back instantly. No flicker. No loading spinner. Bfcache doing its job.

Then you click a button. Nothing happens.

You check the console. Nothing there either. No error. No warning. No stack trace. Just a page that looks alive and isn't.

You refresh. It works again. You go forward, then back. Dead again.

This is the Next.js 16.2.6 bfcache bug. If you upgraded recently, it isn't your code. It's a router regression. There's no official patch yet. Just a GitHub issue and two workarounds.

What's Actually Happening in the Next.js 16.2.6 Bfcache Bug

This is tracked upstream as issue #93905. It was opened May 17, 2026. It's tagged Route Handlers and Script (next/script).

The reporter's repro is simple. Client-navigate to any route. Hit Back. Try to interact with anything that needs JavaScript. Scripts don't run. No errors log.

The bug shows up in next dev and in next build. It hits Chrome and Edge alike. It started the moment the reporter moved to 16.2.6.

Rolling back to the prior release makes it disappear right away. That's a strong signal. This is a router-level regression, not an app bug. That's also why the issue got labeled against next/script and Route Handlers, not anything user-facing.

Why bfcache Makes This Confusing

Bfcache is the browser's back/forward cache. It stores a full in-memory snapshot of a page when you navigate away. Hit Back, and the browser restores that snapshot straight from memory. No network request. No fresh render.

That's normally a win. Instant restores feel native.

Here's the catch. Next.js's client router has to reattach itself when a page comes back from bfcache. It re-registers event listeners. It re-runs script loaders. It reconnects to whatever state the Route Handler layer expects.

In 16.2.6, that reattachment silently fails. The DOM is there. The listeners aren't. Nothing throws, because nothing crashed. The router just never rewires itself.

Minimal Reproduction

Here's a simple way to trigger it. Use a client component with a next/script tag set to afterInteractive.

jsx

// Wrong: this breaks after back-navigation on Next.js 16.2.6
'use client';

import Script from 'next/script';
import { useState } from 'react';

export default function Page() {
  const [count, setCount] = useState(0);

  return (
    <>
      <Script src="/tracker.js" strategy="afterInteractive" />
      <button onClick={() => setCount(count + 1)}>
        Clicked {count} times
      </button>
    </>
  );
}

1. Load this page directly.

2. Client-navigate to any other route.

3. Click Back.

4. Click the button.

On 16.2.5, the counter still increments. On 16.2.6, nothing happens. No re-render. No console output.

Fix 1: Pin Back to next@16.2.5

The fastest fix is the rollback the original reporter already confirmed:

bash

# Correct: pin to the last known-good patch version
npm install next@16.2.5

This is the right call if:

• You don't need anything specific 16.2.6 shipped

• You want the freeze gone today, with zero code changes

• You can track the open issue and re-upgrade later

It's the wrong call in one common case. Some teams upgraded to 16.2.6 specifically for the May 2026 security release. They can't cleanly downgrade past it. More on that below.

Fix 2: Force a Reattach with pageshow and persisted

Can't downgrade? You can work around this yourself. The browser tells you exactly when a page was restored from bfcache. The pageshow event fires. Its event.persisted property is true.

You can use that signal to force the router to re-sync.

jsx

// Wrong: relying on the router to reattach itself after bfcache restore
'use client';

export default function Page() {
  // no bfcache handling - breaks silently on 16.2.6
  return <YourPageContent />;
}

jsx

// Correct: detect bfcache restoration and force a refresh
'use client';

import { useEffect } from 'react';
import { useRouter } from 'next/navigation';

export default function Page() {
  const router = useRouter();

  useEffect(() => {
    function handlePageShow(event) {
      if (event.persisted) {
        router.refresh();
      }
    }

    window.addEventListener('pageshow', handlePageShow);
    return () => window.removeEventListener('pageshow', handlePageShow);
  }, [router]);

  return <YourPageContent />;
}

Why This Works

event.persisted is only true when a page comes from bfcache. It stays false on a normal load. So this listener stays silent most of the time. It only fires on the exact case that's broken.

router.refresh() re-runs the server request for the current route. It re-syncs client state. It rebuilds what the bfcache restore skipped. That's exactly the reattachment step that fails in 16.2.6.

Put this in a shared layout or a top-level client wrapper. Don't repeat it on every page. One listener at the root covers the whole app.

The Trade-Off

This fix isn't free. router.refresh() re-fetches server data for the route. A bfcache restore stops being instant. You trade bfcache's zero-network-request speed for a working page.

For most apps, that's a fair trade. A slightly slower restore beats a frozen one. But check the cost first. If a route does expensive server work on every refresh, test this before shipping it everywhere.

The CVE-2026-23870 Catch With Downgrading

Before you run npm install next@16.2.5, check one more thing.

Next.js 16.2.6 shipped as part of the May 2026 coordinated security release. That release patched 13 advisories. One was a high-severity React Server Components denial-of-service issue. It's tracked as CVE-2026-23870.

Downgrade to 16.2.5, and you undo that patch too. Along with the bfcache fix. Most App Router apps expose a Server Function endpoint, even without writing one directly. That means most App Router apps are back in scope for the DoS vector.

Before pinning back:

• Confirm whether 16.2.5 includes the CVE-2026-23870 fix for your exact dependency versions (next, react-server-dom-webpack, or whichever renderer you use)

• If it predates the fix, use Fix 2 instead of downgrading

• If you must downgrade anyway, track the missing security patch as its own risk

It's an easy detail to miss. Both issues shipped in the same release. The obvious fix for one reopens the other.

Key Takeaways

• The Next.js 16.2.6 bfcache bug freezes all client-side scripts after browser Back navigation, with no console error

• Tracked as GitHub issue #93905, opened May 17, 2026, still open with no merged fix

• Rolling back to the prior patch version removes the freeze right away

• A pageshow listener checking event.persisted, paired with router.refresh(), works around it without downgrading

• 16.2.6 also shipped the CVE-2026-23870 security patch, so downgrading reopens it unless you check your patch status

• This is a young regression, reported about 10 weeks ago. Check the linked issue before you commit to either workaround long-term

FAQ

• Does this affect the Pages Router too, or only the App Router?

  The issue was filed against Route Handlers and next/script. Those are App Router concepts. The reporter's repro uses client-side App Router navigation. Pure Pages Router apps without Route Handlers are less likely to hit this exact failure. Still, test your own back-navigation flow before ruling it out.

• Is this the same thing as the general "Next.js bfcache" caching behavior?

  No. Next.js has its own router-level caching, sometimes called "Router Cache." Internally it's also referenced, confusingly, as "bfCache." That's separate from the browser's real bfcache. This bug is about the browser's actual bfcache restore failing to reattach the Next.js client runtime.

• Will next@16.2.7 fix this automatically?

  There's no merged fix as of this writing. Check the GitHub issue directly. Don't assume a later patch version fixed it. The version you need may change by the time you read this.

• Can I just disable bfcache instead of fixing the reattachment?

  You can send a Cache-Control: no-store header on a route. That opts it out of bfcache entirely. But it removes the instant-restore benefit for every user. Not just the ones hitting this bug. The pageshow workaround only costs speed on the affected restore.

• Does this only happen in development, or does it hit production builds too?

  Both. The original report lists next dev and next build as affected stages. Don't treat this as a dev-only annoyance. Test your production build's back-navigation flow too.

• Why doesn't this throw a console error if scripts are actually failing?

  The reattachment step just doesn't run. It doesn't throw. Nothing crashed from the browser's view. The router's internal wiring is the part left incomplete. That's why it's easy to miss without deliberately testing Back navigation.

• Do I need to add the pageshow listener to every page individually?

  No. Add it once, in a shared client layout or a top-level wrapper. Every route should render through it. One listener at the root covers the whole app.

• Is downgrading to 16.2.5 safe if I've never touched Server Functions directly?

  Probably not safe to assume so. The App Router uses Server Functions and RSC internally, even if you never wrote one yourself. Most App Router apps are in scope for CVE-2026-23870. Check first. Use the pageshow fix instead if you're unsure.

  The Real Fix Here Is Patience, Not a Workaround

This is a regression, not a trade-off. The router should reattach after a bfcache restore. In 16.2.6, it doesn't.

Until Vercel ships a patch, you have two options. Pin to 16.2.5 and lose the May security fix. Or add a pageshow listener and trade bfcache's instant restore for a working page. Neither is elegant. But the pageshow route keeps you patched while you wait.

Watch issue #93905 for a merged fix. Re-test your back-navigation flow on every 16.2.x bump until it closes. Touching Router Cache behavior more broadly? The use cache directive coverage on SkillDham covers another spot where this cache layer misbehaves quietly.