Next.js 15 Reached End of Life on 21 October 2026: How to Move to 16

Next.js 15 reached the end of Maintenance LTS on 21 October 2026, two years after 15.0.0 shipped. Only 16.x now has committed security fixes. The last 15.x release is 15.5.28. If you run Next.js 15, upgrade to 15.5.28 and sharp 0.35.5 today, then move to 16.4.3 or later on a dated plan.

The timing is not abstract. One day after the cutoff, on 22 October, Vercel published four new Next.js advisories, two of them critical remote code execution bugs. One of those, in the Image Optimization API, also affects 15.x. It was fixed in 15.5.28, released a week before the cutoff, so 15.x users have a fix this time. The next one is not promised.

This guide is for teams that run Next.js 15 or older in production. It covers what the support policy says and what it means now that the date has passed, the exact release and advisory history of the 15.x line, how many installs are still on 15, how to find every Next.js app in a repository or a fleet, what to do this week, and the main steps of the move to Next.js 16 with the commands for each.

The short answer

Next.js 15.x left Maintenance LTS on 21 October 2026. The support policy keeps each major in Maintenance LTS for two years after its initial release, and 15.0.0 was released on 21 October 2024. From 22 October, the only line with a commitment to security fixes is 16.x, currently 16.4.3.

The last 15.x release is 15.5.28, published to npm at 17:36 UTC on 14 October 2026. It fixes a critical unauthenticated remote code execution bug in the Image Optimization API (GHSA-2464-fhr4-w9xw) and a high severity denial of service in Server Actions (GHSA-p3m5-59mp-jv5r). Both advisories were published on 22 October.

Vercel may still patch 15.x "in rare circumstances", as it did for 14.x in December 2025. That is an exception, not a plan.

What to do: move every 15.x app to 15.5.28 now, confirm sharp resolves to 0.35.5 or later, and schedule each app's move to 16. Anything still on 14.x or older has been out of support for a year or more and should go first.

What happened

The end of 15.x support was predictable from the day 16.0.0 shipped. What makes it worth a closer look is how much security work the 15.x line was still receiving right up to the cutoff, and what landed the day after.

Timeline

What changed since our first draft on 20 October

We first drafted this post on 20 October, the day before the cutoff. Four things have moved since then.

1. Four new advisories on 22 October. Two are critical remote code execution bugs. GHSA-2464-fhr4-w9xw affects both 15.x and 16.x and is fixed in 15.5.28 and 16.4.1. GHSA-673q-mjm6-r5xr affects only 16.x, in use cache functions that return typed arrays, and is fixed in 16.4.1. A high severity Server Actions denial of service (GHSA-p3m5-59mp-jv5r, CVE-2026-94482) affects both lines. A medium use cache leak (GHSA-h694-7cp9-m8p3, CVE-2026-103004) affects 16.3 only. GitHub's database now holds 44 reviewed Next.js advisories published in 2026, up from 40 when we first counted.
2. A new 16.x release. 16.4.3 was published on 23 October. Its release notes describe it as backporting bug fixes, such as keeping OpenTelemetry request traces together, with no security advisories attached.
3. The download numbers moved. In the week npm reported on 24 October, 15.x was 19.3% of Next.js downloads, down from 20.0% the week before, while total weekly downloads rose to about 46 million.
4. The support page has not been updated yet. As of 24 October, nextjs.org still lists 15.x as Maintenance LTS under Supported Versions. The policy text, which keeps each major in maintenance for two years after its initial release, puts the end at 21 October 2026, and endoflife.date records the same date. We treat the policy text as authoritative and expect the table to catch up.

What the support policy says

The Next.js support policy has two phases for each major release.

Active LTS lasts until the next major ships. During it, the release gets new features, bug fixes, performance work and security patches.

Maintenance LTS starts when the next major ships. In this phase Next.js commits to shipping "only critical bug fixes and essential security updates." Each major stays in Maintenance LTS for two years following its initial release. Maintenance updates land as semver-minor releases, even if they are breaking changes. The policy also says that, depending on severity, Vercel will in rare circumstances patch versions outside the policy.

Applied to the current lines:

Two details in the policy matter more than they first appear.

First, Maintenance LTS is not "every fix." It covers critical bugs and essential security updates. Through 2026, Vercel was generous with that scope: it shipped 23 stable 15.x releases between 26 January and 14 October. But a maintenance line never got features, and some fixes for problems that existed only in new 16.x features had no 15.x equivalent, because 15.x did not have the code.

Second, the 16.x clock is already running. 16.0.0 shipped on 21 October 2025. If Next.js 17 ships on a similar annual rhythm, 16.x will enter Maintenance LTS when it does, and its two-year window still ends around 21 October 2027. A team that moves from 15 to 16 this quarter gets roughly a year of supported runway, not two. There is no 17.x stable or release candidate on npm today; the canary dist-tag points at 16.5.0-canary.26 and the preview tag at a 16.3 preview.

Who is affected

Being on an unsupported version does not mean you are exploitable today. It means that when the next vulnerability is found in code that 15.x shares with 16.x, there is no commitment that a 15.x release will follow. Over 2026, most of the high and critical Next.js bugs were in shared code: the Image Optimization API, Server Actions, middleware and proxy routing, rewrites and the React Server Components transport.

Technical details

This section holds the exact data behind the summary: release history, the 2026 advisory record for 15.x, the advisories published after the cutoff, npm install share by version, and the Next.js 16 runtime floor.

Release history of the 15.x line in 2026

npm records 82 stable 15.x releases in total, from 15.0.0 on 21 October 2024 to 15.5.28 on 14 October 2026. In 2026 alone there were 23. The dates come from the npm registry's time field.

Two patterns stand out. From February 2026 onward, fixes landed only on the 15.5 minor, so anyone pinned to 15.3 or 15.4 stopped receiving fixes in January unless they moved to 15.5. And the npm backport dist-tag now points at 15.5.28, while older minor tags such as next-15-3 (15.3.9) and next-15-2 (15.2.9) froze in January.

Every 2026 Next.js advisory, with its 15.x fix

GitHub's advisory database lists 44 reviewed advisories for the next package published between 1 January and 24 October 2026: 5 critical, 15 high, 20 medium and 4 low. Thirty two of them name a stable 15.x patched version. The other 12 list only a 16.x fix; we look at those in the next section.

Severity labels are GitHub's. Where GitHub shows a CVSS score we give it; many 2026 records carry a severity label without a score.

The 12 advisories with no 15.x fix

Not every 16.x-only advisory means 15.x was left exposed. Reading the affected ranges on each record:

• Six cover features or builds tied to 16.x, or never shipped in a stable 15. GHSA-673q-mjm6-r5xr and GHSA-h694-7cp9-m8p3 concern use cache, as does GHSA-3w37-wq28-93x7. GHSA-vcvr-r3jv-pc5j affects next/og ImageResponse from 16.2.0. GHSA-39w2-rjm5-chcv is the development server's MCP endpoint. GHSA-5f7q-jpqc-wp7h affected only 15.x canary builds, never a stable 15 release.
• Five list an affected range starting at 16.0.0 or 16.0.1 without saying why 15.x is excluded: the three March CSRF and resume buffering advisories, the July Turbopack single locale proxy bypass (GHSA-6gpp-xcg3-4w24) and the 7 October Image Optimization SSRF (GHSA-cjq9-62q9-8jv4). The record's range is the authority, and it does not include 15.x.
• One record disagrees with its release notes. The GitHub release notes for 15.5.27 list GHSA-f87g-xv8r-7p7x (metadata image route disclosure) among its fixes, but the advisory record's affected range covers only 16.x. If you are on 15.x, 15.5.27 or later contains the fix either way.

We did not test whether any 16.x-only bug also reproduces on 15.x, and we do not suggest it does. The point is narrower: after 21 October, the question "does this new bug affect 15.x, and will there be a fix" no longer has a committed answer.

The first advisory after the cutoff: GHSA-2464-fhr4-w9xw

The critical SVG advisory published on 22 October is a good illustration of what maintenance coverage was worth, and what it depends on.

• Summary on the record: unauthenticated remote code execution in the Image Optimization API when SVG files are used.
• Impact, per the advisory: a memory-related vulnerability in an upstream library used for image optimization can lead to possible RCE when Next.js runs on glibc-based Linux.
• Affected: next from 10.0.0 through 15.5.27, and 16.0.0 through 16.4.0.
• Fixed: 15.5.28 and 16.4.1, both released on 14 October 2026.
• Score: CVSS 4.0 base score 9.5, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. The record shows no CVSS 3 score.
• Workaround in the advisory: make sure the version of sharp used by Next.js is 0.35.5 or later. Fresh installs get a fixed sharp automatically.
• Upstream reference: the advisory links NVD's record for CVE-2026-96889, a librsvg use-after-free when SVG documents with nested XML includes declare duplicate entities. CVE.org shows Red Hat as the assigning CNA, published 23 September 2026, CVSS 3.1 base score 7.8. The Next.js advisory itself lists no CVE ID.
• Credits on the record: GitHub users randomguy6407 and rafabd1, as finders.
• Fix commits referenced: 5e3b687b5edb868b064bdc058d768a7021e7f6ad and 9571ec899f063df6533351bec390ccb2cc0af6a3 in vercel/next.js.

The sharp detail is the one most teams will miss. The optionalDependencies entry for sharp in next@15.5.28 is ^0.34.3 || ^0.35.5. A fresh install resolves the newest matching version, which is 0.35.5. An existing lockfile that already pins sharp 0.34.5 still satisfies that range, so npm install next@15.5.28 can leave the old sharp in place. In 16.4.1 and later, the range is ^0.35.5, which closes that gap. Check sharp explicitly after upgrading:

npm ls sharp
# or
pnpm why sharp
yarn why sharp

If the output shows any 0.34.x, or 0.35.4 or earlier, update it:

npm install sharp@0.35.5

Install share by version

npm publishes per-version download counts for the most recent week. For the week reported on 24 October 2026, next had 45,962,626 downloads:

Inside the 15.x share:

And on the supported line, 71.3% of 16.x downloads were for versions below 16.4.1, which means they predate the 22 October critical fixes.

These counts include CI runs, caches and mirrors, so they are a rough signal of install activity, not a count of apps. They still say something useful: a fifth of Next.js installs are on a line that just lost support, and most of those are not even on the last release of that line. The single most downloaded 14.x version, 14.2.35, still drew 1,342,335 downloads in the week.

Runtime floor for Next.js 16

The Node.js minimum is lower than you should actually use. The Node.js release schedule ended Node.js 20 on 30 April 2026. Node.js 22 is in maintenance until 30 April 2027, Node.js 24 entered maintenance on 20 October 2026 and runs to 30 April 2028, and Node.js 26 becomes LTS on 28 October 2026. For a Next.js 16 move today, Node.js 24 is the practical target, with 22 as the fallback.

Known exploited context

CISA's Known Exploited Vulnerabilities catalog (version 2026.10.23) lists CVE-2025-55182, the React Server Components remote code execution bug, added on 5 December 2025. Next.js shipped its fix under GHSA-9qr9-h5gf-34mp with a CVSS score of 10.0 and patched releases 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 and 16.0.7. That episode was the clearest case for maintenance coverage: 15.x users had a same-week fix for an actively exploited bug. None of the 2026 Next.js advisories appear in the KEV catalog as of 23 October.

Affected and fixed versions at a glance

Find every Next.js app

In a monorepo, or across a folder of cloned repositories, the slow part is knowing where Next.js is and which version each app actually resolves. Declared ranges such as ^15.5.0 can resolve to very different versions depending on when the lockfile was written.

The script below walks a directory, skips node_modules, and for each package.json that depends on Next.js reads the resolved version of next and sharp from package-lock.json, pnpm-lock.yaml or yarn.lock. If there is no lockfile it falls back to the declared range and says so. It uses only the Python standard library.

#!/usr/bin/env python3
"""Find every Next.js app under a directory and report its support status.

Next.js 15.x left Maintenance LTS on 21 October 2026. Only 16.x is supported
now. For each package.json that depends on next, this reads the resolved
version of next and sharp from package-lock.json, pnpm-lock.yaml or yarn.lock
(falling back to the package.json range) and prints a status line.
Skips node_modules. Standard library only.

Usage: python3 next_support_check.py ~/code
"""
import json
import pathlib
import re
import sys

LAST_15 = (15, 5, 28)     # last 15.x release, 14 Oct 2026
FIXED_16 = (16, 4, 1)     # first 16.x with the 22 Oct 2026 advisories fixed
SHARP_OK = (0, 35, 5)     # sharp floor named in GHSA-2464-fhr4-w9xw


def vtuple(v):
    m = re.search(r"(\d+)\.(\d+)\.(\d+)", v or "")
    return tuple(int(x) for x in m.groups()) if m else None


def from_lockfiles(project, name):
    lock = project / "package-lock.json"
    if lock.exists():
        data = json.loads(lock.read_text())
        pkg = data.get("packages", {}).get(f"node_modules/{name}", {})
        if pkg.get("version"):
            return pkg["version"], "package-lock.json"
    pnpm = project / "pnpm-lock.yaml"
    if pnpm.exists():
        m = re.search(rf"^\s+/?{re.escape(name)}@(\d+\.\d+\.\d+)", pnpm.read_text(), re.M)
        if m:
            return m.group(1), "pnpm-lock.yaml"
    yarn = project / "yarn.lock"
    if yarn.exists():
        m = re.search(rf'^"?{re.escape(name)}@[^\n]*\n\s+version:? "?(\d+\.\d+\.\d+)', yarn.read_text(), re.M)
        if m:
            return m.group(1), "yarn.lock"
    return None, None


def version_of(project, name, declared):
    v, src = from_lockfiles(project, name)
    if v:
        return v, src
    rng = {**declared.get("devDependencies", {}), **declared.get("dependencies", {})}.get(name)
    return (rng, "package.json range") if rng else (None, None)


def status(next_v, sharp_v):
    t = vtuple(next_v)
    if t is None:
        return "?    cannot read a version"
    if t[0] >= 16:
        msg = "ok   16.x is supported" if t >= FIXED_16 else "FIX  16.x but below 16.4.1"
    elif t[0] == 15:
        msg = "PLAN 15.x out of support since 21 Oct 2026"
        if t < LAST_15:
            msg = "FIX  15.x and below 15.5.28; upgrade now, then plan 16"
    else:
        return f"FAIL {t[0]}.x has been out of support for longer"
    s = vtuple(sharp_v)
    if s and s < SHARP_OK:
        msg += f"; sharp {sharp_v} is below 0.35.5"
    return msg


def main(root):
    for pj in sorted(pathlib.Path(root).rglob("package.json")):
        if "node_modules" in pj.parts:
            continue
        declared = json.loads(pj.read_text())
        nv, src = version_of(pj.parent, "next", declared)
        if not nv:
            continue
        sv, _ = version_of(pj.parent, "sharp", declared)
        print(f"{str(pj.parent):<16} next {nv:<9} ({src:<18}) {status(nv, sv)}")


if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else ".")

We ran it on a sample monorepo with six packages: five apps covering each case, and one shared library that does not depend on Next.js and is correctly skipped.

$ python3 next_support_check.py apps
apps/admin       next 15.3.4    (package.json range) FIX  15.x and below 15.5.28; upgrade now, then plan 16
apps/blog        next 16.3.8    (yarn.lock         ) FIX  16.x but below 16.4.1
apps/docs        next 15.5.28   (package-lock.json ) PLAN 15.x out of support since 21 Oct 2026; sharp 0.34.5 is below 0.35.5
apps/marketing   next 14.2.35   (package.json range) FAIL 14.x has been out of support for longer
apps/shop        next 16.4.3    (pnpm-lock.yaml    ) ok   16.x is supported

Read the output in this order. apps/marketing is two majors behind and has had no committed fixes for a year. apps/admin is on 15.3, a minor that stopped getting fixes in January, and is missing every 2026 fix that 15.5 received. apps/docs looks fine at first glance, on the last 15.x release, but its lockfile still pins sharp 0.34.5, which is exactly the case the 22 October advisory's workaround is about. apps/blog is on the supported line but below 16.4.1. Only apps/shop needs nothing.

The pnpm and yarn parsing is deliberately simple and matches the common lockfile layouts. For anything unusual, the package manager itself is the authority:

# Resolved version in the current project
node -p "require('next/package.json').version"
npm ls next sharp
pnpm why next
yarn why next

# Inside a built container image
docker run --rm --entrypoint node your-image:tag -p "require('next/package.json').version"

For a standalone build (output: 'standalone'), the traced node_modules inside .next/standalone is what ships, so check the version there rather than in the source tree.

What to do this week

1. Inventory. Run the script above, or your SBOM tooling, across every repository that might hold a Next.js app, including marketing sites, docs portals and internal tools. Write down each app, its resolved version, who owns it and whether it is internet facing.
2. Fix 16.x apps below 16.4.1. These are on the supported line and need only a patch upgrade: npm install next@16.4.3, then run your tests and deploy.
3. Move every 15.x app to 15.5.28. This is a drop-in patch upgrade on the 15.5 minor, and a minor upgrade from 15.0 to 15.4: npm install next@15.5.28. Read the 15.5 release notes if you are coming from an older minor, then test and deploy.
4. Check sharp on every app, on 15.x and 16.x alike: npm ls sharp. Move anything below 0.35.5 to 0.35.5. Rebuild container images afterwards, because sharp ships native libvips binaries per platform.
5. Rank the move to 16 by exposure. Put internet-facing apps that self-host image optimization, run on Windows servers, use middleware for access control or use Server Actions with custom servers first. Those are the areas where 2026's high and critical bugs clustered.
6. Give every app still on 15 a date and an owner. Record it as accepted risk until it moves. Our guide to managing end-of-life software dependencies covers how to run that register.
7. Stop new apps starting on 15. Add a policy or CI check that fails when next resolves below 16, so the problem does not grow while you work through the backlog.

Moving to Next.js 16

The Next.js 16 upgrade guide is the reference. What follows is the order we would do it in, with the commands, and the points where apps usually break.

Step 1: check runtimes before touching code

node -v          # needs 20.9.0 or later; use 24.x in practice
npx tsc -v       # needs 5.1.0 or later

Check CI images, Dockerfiles, serverless runtime settings and developer machines. A Node.js 18 build agent will fail as soon as next@16 is installed. If you are moving Node.js too, do that first, deploy it on Next.js 15.5.28, and only then upgrade Next.js. Two changes at once make failures harder to read.

Step 2: run the upgrade codemod

The guide's recommended route is either the agent-assisted upgrade CLI or the codemod:

# Codemod route
npx @next/codemod@canary upgrade latest

# pnpm, yarn and bun equivalents
pnpm dlx @next/codemod@canary upgrade latest
yarn dlx @next/codemod@canary upgrade latest
bunx @next/codemod@canary upgrade latest

The guide also documents npx next@canary upgrade --agent=latest, which prepares the migration guides and codemod command for a coding agent and asks it to apply and verify the changes. Either way, review every change as a normal pull request.

Per the guide, the upgrade codemod moves experimental.turbopack to the top-level turbopack key, migrates next lint to the ESLint CLI, renames middleware to proxy, removes the unstable_ prefix from stabilized APIs and removes the experimental_ppr route segment config. It does not run every migration codemod.

Step 3: make request APIs async

Next.js 15 made cookies, headers, draftMode, params and searchParams async but kept temporary synchronous access. Next.js 16 removes that compatibility. If your code still reads them synchronously, run the dedicated codemod:

npx @next/codemod@canary next-async-request-api .
npx next typegen

next typegen generates the global type helpers for async params and searchParams. The same change applies to params in opengraph-image, twitter-image, icon and apple-icon, and the id parameter for sitemap is now async as well. Expect to touch every dynamic route.

Step 4: rename middleware to proxy, carefully

The middleware file and export names are deprecated in favor of proxy:

git mv middleware.ts proxy.ts

// proxy.ts
export function proxy(request: Request) {
  // same logic as your old middleware
}

Configuration flags that contained the word middleware are renamed too, for example skipMiddlewareUrlNormalize becomes skipProxyUrlNormalize.

The important caveat in the guide: proxy runs on the Node.js runtime only, and that cannot be configured. If your middleware runs on the edge runtime, keep using middleware for now rather than renaming it blindly. The guide's own migration checklist says edge middleware should not be renamed to proxy without thought.

Because five of 2026's high severity Next.js advisories were middleware or proxy bypasses, write tests for your access rules before the rename and run them after it. Do not rely on middleware or proxy as the only authorization check for sensitive routes; check authorization again where the data is read.

Step 5: review the next/image defaults

Several image defaults changed in 16, and some of them change behavior you may depend on:

Two of those are security improvements worth keeping: blocking local IP optimization and capping redirects both reduce SSRF exposure through the image optimizer. If you set dangerouslyAllowLocalIP to true to get an internal image host working, limit it to private deployments. With the new qualities default, a quality prop that is not in the list is coerced to the nearest allowed value, and direct /_next/image requests with unsupported q values return 400.

Step 6: Turbopack by default

next dev and next build use Turbopack by default in 16. If your project has a custom webpack configuration, or a plugin adds one, next build will fail on purpose. You can build with Turbopack and ignore the webpack config, migrate the config to Turbopack options, or keep Webpack with next build --webpack. Sass imports that use the legacy ~ prefix for node_modules are not supported by Turbopack; change the import or add a turbopack.resolveAlias.

Step 7: remove what is gone

• AMP support is removed entirely, including the amp config, next/amp and useAmp.
• next lint is removed, and next build no longer lints. Use ESLint or Biome directly. eslint-config-next@16 requires ESLint 9 or later.
• serverRuntimeConfig and publicRuntimeConfig are removed. Use environment variables, with NEXT_PUBLIC_ for client values, and call connection() before reading process.env if you need runtime rather than build-time values.
• experimental.dynamicIO and experimental.useCache are removed in favor of top-level cacheComponents. Enabling cacheComponents is not a rename and can surface new build errors, so remove the old flags unless you are actively adopting Cache Components.
• unstable_rootParams is replaced by next/root-params.
• Parallel route slots now require an explicit default.js; builds fail without it.
• revalidateTag now takes a second cacheLife profile argument, for example revalidateTag('posts', 'max').

Step 8: test the paths that break quietly

A green build is not the end. Before you ship, check that:

• protected routes still reject unauthenticated requests after the proxy rename;
• image URLs with custom qualities, query strings or redirects still load;
• pages that rely on cached responses behave correctly with the new image TTL and caching APIs;
• process.argv checks for 'dev' in your Next config are replaced, because the config is no longer loaded twice in development;
• smooth scrolling behaves as designers expect, since 16 no longer overrides scroll-behavior during navigation unless you add data-scroll-behavior="smooth" to the html element.

Then deploy to a staging environment with production-like traffic for a few days before the production cutover.

If an app cannot move yet

Some apps will not move to 16 this quarter. For those, reduce exposure while the clock runs.

• Stay on 15.5.28 with sharp 0.35.5. There will be no newer 15.x unless Vercel makes an exception.
• Turn off what you do not use. If an app does not need on-demand image optimization, images: { unoptimized: true } in next.config.js removes the image optimizer from the request path. Six of the 32 advisories with 15.x fixes this year, including two of the three critical ones, were in image optimization or the image cache.
• Narrow images.remotePatterns to the exact hosts and paths you serve, instead of broad wildcards.
• Avoid Windows hosting for internet-facing 15.x apps, given GHSA-p293-qw3h-jr36.
• Put authorization in the data layer, not only in middleware.
• Watch the advisory feed for next and treat any new advisory that lists only a 16.x fix as a trigger to re-check your 15.x apps against its description.

What would have helped

Next.js 15 ending is not an incident. It is a dated event that was public for a year. The teams having a calm week are the ones that already did a few ordinary things.

A real inventory of framework versions. Knowing which apps run which resolved version, from lockfiles or SBOMs, not from memory, turns "who is still on 15?" into a query. The download data suggests most 15.x installs are not on the last 15.x release, which is the kind of drift an inventory exposes.

Patch upgrades as routine, not projects. The 15.5.x line shipped 23 releases in 2026. Teams with automated dependency pull requests and good tests took each one in a day. Teams that batch upgrades quarterly were exposed to the August critical RCEs for weeks.

A rule that new apps start on the supported major. A CI policy that rejects next below the current major stops the backlog from growing.

Lifecycle dates on the calendar. Every major's end date was knowable from the day the next major shipped. Putting those dates next to each app, with an owner, is what moves an upgrade from "someday" to a sprint.

Transitive native dependencies in the inventory. The 22 October advisory turned on sharp, which most teams never install directly. Seeing it in the dependency graph is what makes the workaround actionable.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in an agentic mode and a deterministic scanner mode, issues findings as SGZ advisories before they reach public CVE databases, and covers seven package ecosystems. It did not find any of the Next.js advisories discussed here, and we make no claim that it did; every advisory in this post was published by Vercel through GitHub.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service with hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher provenance, Sigstore signatures and public evidence pages; an artifact loses its badge if it regresses. We have not checked whether Gold Registry carries a hardened build of next or sharp, so ask before planning around one. The habit Gold supports, pulling known good, signed components from a curated source and rebuilding quickly, is the same habit that makes a framework line ending a scheduled task rather than a scramble.

Where Safeguard fits

Safeguard does not upgrade Next.js on its own, does not run your tests for you without permission, and does not change the Next.js support policy. Here is where it does help with this kind of work:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with JSON results under ./output). That inventory includes transitive packages such as sharp, and the platform shows which projects contain a given component and version, so "every app on next 15.x, and every app with sharp below 0.35.5" is a query.
• Vulnerability matching against vulnerability databases, so each app's resolved next version is matched to the advisories above.
• Reachability analysis, which ranks the vulnerable code paths your application actually calls, so an app that uses the image optimizer rises above one that does not.
• Policies and gates evaluated in the platform, so a build that resolves next below 16, or sharp below 0.35.5, can fail or warn.
• Autonomous remediation that opens fix pull requests for vulnerable dependencies, such as next 15.3.4 to 15.5.28 or sharp to 0.35.5. It ships off by default.
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You can ask it to run the Next.js 16 codemods, rename middleware to proxy, fix the async request API errors and run the build and tests, approving each step. safeguard exec runs the same kind of task in CI, and the desktop and phone apps can send work to a computer running the CLI and approve each command.

What it does not do: it does not decide whether your edge middleware should become proxy, it cannot make 15.x supported again, and a major framework upgrade still needs your engineers to review and test it.

Common mistakes

Reading the declared range instead of the resolved version. "next": "^15.5.0" says nothing about what your lockfile installed. Check the lockfile or npm ls next.

Upgrading next and assuming sharp followed. In 15.5.28 the sharp range still accepts 0.34.x. Run npm ls sharp after the upgrade.

Upgrading the source tree but not the image. A Docker image built last month still contains last month's node_modules. Rebuild, redeploy and check the version inside the running container.

Running the codemod on Node.js 18. Next.js 16 requires Node.js 20.9 or later, and Node.js 20 itself reached end of life on 30 April 2026. Fix the runtime first.

Renaming edge middleware to proxy. proxy is Node.js only. An edge middleware renamed without thought changes runtime, latency and possibly behavior.

Trusting middleware alone for authorization. Five high severity bypasses in one year is a strong hint. Check access again where data is read.

Pinning an old 15 minor. Fixes stopped landing on 15.0 to 15.4 in January 2026. Being "on 15" was not the same as being on a maintained version even before 21 October.

Treating the support page table as the date. As of 24 October the table still lists 15.x as supported. The policy text sets the date, and the date has passed.

Forgetting the small apps. Marketing sites, docs portals and status pages often run Next.js, are internet facing, and are the last to be upgraded.

Open questions

• Will Vercel publish any further 15.x release? The policy allows out-of-policy patches in rare cases, and 14.x received two in December 2025. There is no announcement either way.
• When will Next.js 17 ship? There is no 17.x release candidate on npm. Its timing decides when 16.x enters Maintenance LTS, though not when that maintenance ends.
• Are any of the 16.x-only advisories reproducible on 15.x? The records' affected ranges say no, and we have not tested otherwise. Watch for updated records.
• Will the support page table be updated? We expect 15.x to move under Unsupported Versions; we will update this post when it does.

FAQ

When did Next.js 15 reach end of life?

On 21 October 2026, two years after 15.0.0 was released on 21 October 2024. The support policy keeps each major in Maintenance LTS for two years after its initial release.

What is the last Next.js 15 release?

15.5.28, published on 14 October 2026. It fixes a critical image optimization RCE (GHSA-2464-fhr4-w9xw) and a high severity Server Actions DoS (GHSA-p3m5-59mp-jv5r).

Is Next.js 15.5.28 safe to run?

It has fixes for every advisory published so far that lists a 15.x patch, provided sharp is 0.35.5 or later. It will not receive committed fixes for anything found from now on, so it is a stopgap, not a destination.

The support page still lists 15.x as supported. Is it?

The table had not been updated as of 24 October. The policy text on the same page sets the end at two years after the initial release, which was 21 October 2026, and endoflife.date records that date too.

Will Vercel still patch Next.js 15?

Possibly, in rare cases. The policy says Vercel may patch versions outside it depending on severity, and it did so for 14.x with 14.2.34 and 14.2.35 on 11 December 2025. There is no commitment.

How long will Next.js 16 be supported?

Under the current policy, 16.x stays in Active LTS until Next.js 17 ships, then in Maintenance LTS until two years after its own initial release, around 21 October 2027.

What Node.js version do I need for Next.js 16?

At least Node.js 20.9.0. Because Node.js 20 itself reached end of life on 30 April 2026, use Node.js 24 or 22 in practice.

Does the upgrade codemod do everything?

No. It handles the Turbopack config move, the next lint migration, the middleware to proxy rename and a few API renames. Async request APIs have their own codemod, and image defaults, removed features and edge middleware need manual review.

Is Next.js 14 still supported?

No. 14.x left Maintenance LTS on 26 October 2025. 14.2.35, released on 11 December 2025 outside the policy, is the last 14.x release, and it misses every 2026 fix.

We deploy on a managed platform. Does this apply to us?

Yes. The platform runs your build, but the Next.js version comes from your package.json and lockfile. A platform does not upgrade your framework major for you.

Fix it without waiting for upstream

For 15.x, upstream has now stopped committing to fixes, which is exactly the gap below. The fastest way out is still the boring one: move the dependency to a version that is fixed and supported, across every app at once.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows a Next.js upgrade. Each is a real Safeguard session, and each intro says how the same flow applies to the work in this guide.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this guide, you would open the CLI in an app still on next 15.3.4 and ask it to move to 15.5.28, pin sharp to 0.35.5 and run the tests, approving each edit and command, then repeat later for the move to 16 with the codemods.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. A Next.js 16 migration fits that shape: pick the app's folder, ask for the upgrade codemod, the async request API codemod and the middleware to proxy rename, and approve or deny each file edit as it comes, with the build and tests as the last step.

Click through it at your own pace, or open it full screen.

This session sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. For a monorepo with many Next.js apps, that is how you get the first inventory: run the scan locally against the repository, then filter the results for next and sharp versions to build the list in "What to do this week."

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For background on two of this year's 16.x advisory batches, see our posts on the Next.js 16.3.8 image SSRF and cache poisoning advisories and the next/og ImageResponse RCE, and for the exploited React bug behind December's emergency patches, CVE-2025-55182 in React Server Components.

Quick check

Sources

• Next.js: Support Policy
• Next.js: How to upgrade to version 16
• npm registry: next package metadata and release times
• npm: next downloads by version, last week
• GitHub Advisory Database: npm advisories affecting next
• GitHub: GHSA-2464-fhr4-w9xw, unauthenticated RCE in Image Optimization API when SVG files are used
• GitHub: vercel/next.js release v15.5.28
• GitHub: vercel/next.js release v16.4.1
• GitHub: vercel/next.js release v16.4.3
• GitHub: vercel/next.js release v15.5.27
• GitHub: vercel/next.js release v15.5.24
• CVE.org: CVE-2026-96889, librsvg use-after-free
• npm registry: sharp package metadata
• CISA: Known Exploited Vulnerabilities catalog
• Node.js Release Working Group: release schedule
• endoflife.date: Next.js

Last reviewed: 24 October 2026. Support pages and advisories change; check the Next.js support policy and the GitHub advisory feed for the latest status.