Next.js security releases since July: every fix, whether your app is affected, and what upgrading involves

The short version

• On 13 July Next.js moved to a formal security release programme: roughly one pre-announced release a month, plus emergency releases for anything urgent. [1]
• Five have shipped (20 or 21 July, 25 August, 22 September, 30 September, 14 October) and a sixth is announced for 3 November, covering seven medium-severity issues. [1][2][3]
• Between them: four unauthenticated remote code execution flaws rated critical, a high-severity bypass of middleware checks, and four request-forgery flaws. The ledger below lists all of them.
• Only two lines get fixes. Next.js 16 is Active LTS and 15 is Maintenance LTS, with 15's security releases extended to 31 January 2027. Version 14 and earlier are end of life. [4]
• The latest fixed versions are Next.js 16.4.1 and Next.js 15.5.28. [5]
• If you are on 14, the move to 15.5.28 means React 19 and a change to how requests are read. That is a project, not a patch.

Five-minute triage: are you exposed?

Reading the results:

• Red. Next.js 14 or earlier, or any version below the latest fix on its line, with no one named. Act this week.
• Amber. On a fixed version, but you do not know which features you use, or the container can reach more than it needs to. Fix this month.
• Green. On 16.4.1 or later (or 15.5.28), the advisories checked against your features, an owner named. You are covered until the next release, and the next one is on 3 November.

What leaving it can cost

What the flaws let an attacker do

Take the four unauthenticated remote code execution flaws first. They let someone who has never logged in run code on the machine that serves your app:

• 25 August, a flaw in the underlying libheif library used by sharp, triggered when Next.js optimises an attacker-controlled AVIF image. The patched releases disable AVIF optimisation until an upstream fix arrives. [6]
• 25 August, CVE-2026-75604, on servers using a Windows filesystem, when an app uses both the Pages Router and the App Router without Cache Components. Next.js says there is no known workaround. [6]
• 22 September, in the Node.js ImageResponse (next/og) through Satori, in versions from 16.2.0 up to 16.3.6. Next.js 15 is not affected, nor is the Edge ImageResponse. [7]
• 14 October, two more: an RCE in App Router apps using Cache Components when a use cache function returns multiple typed arrays, with no known workaround, and CVE-2026-96889 in image optimisation on glibc-based Linux. [5]

Then there are the ones that do not need code execution to hurt. A middleware bypass (CVE-2026-64642) means the checks your middleware performs, such as logins and role checks, can be skipped. [8] Request forgery in rewrites(), in Server Actions on custom servers and in image optimisation lets an attacker make your server send requests for them, and the September advisory names private IP ranges as the example. [8][9] On a cloud host, private ranges include the metadata service that hands out credentials.

On exploitation: I checked CISA's Known Exploited Vulnerabilities catalogue on 30 October. The two 2026 flaws that have CVE numbers and critical RCE, CVE-2026-75604 and CVE-2026-96889, are not in it. [10] These are patched critical flaws, not confirmed attacks. That is a statement about 30 October. The precedent is December 2025, when CISA listed the React Server Components flaw (React2Shell, CVE-2025-55182) two days after it was disclosed. [10][11]

What a foothold turns into

The biggest recent example of one foothold growing is Binance, which lost about $6.36 billion on 29 October after a compromised DevOps laptop led, through further points of breach, to a service container that could submit withdrawals. [12] I've told that story in full in the PHP2Shell piece, and it is not a Next.js story.

What carries over is the container. Most Next.js apps run in one, and a server-side flaw hands an attacker whatever that container holds: database URLs, API keys, payment keys, cloud credentials. Two things decide the damage. How fast the version moves, and how much the container can reach.

What a clean-up consists of

If code ran on your server, the job is not "upgrade and carry on":

1. Establish when it started, from logs that may not go back far enough.
2. Rebuild the deployment from a clean image, do not repair it.
3. Rotate every secret that container could read, then every system those secrets opened.
4. Review the data it could reach. If personal data was exposed, UK GDPR requires telling the ICO within 72 hours of becoming aware, unless the breach is unlikely to risk people's rights. [17] If card data is involved, your card acquirer expects to hear.
5. Trade with a degraded or offline app while that happens.

IBM's 2025 report puts the average UK breach at £3.78 million for organisations not using AI and automation in security, and £3.11 million for those that do. Its sample is 600 mostly large organisations, so your figure will be far smaller, but it is the only UK cost figure I could verify. [13]

How many apps are in scope

I found no published exposure count for the 2026 Next.js flaws. The advisories give versions and conditions, not populations, so I will not invent one. The nearest real figures: for the December 2025 React flaw, Censys counted just over 2.15 million internet-facing instances that may be affected, across React Server Components and frameworks such as Next.js, Waku, React Router and RedwoodSDK. It did not filter by version, so not all of them were vulnerable. [11] And the population is growing: W3Techs says Next.js went from 1.9% of all websites to 3.7% in a year. [14] More installs means more estates to patch each month, and fewer of them have a named owner.

Next.js security releases: what each one fixed

Every row is from the Next.js release post for that date. "Affected if" is the condition the advisory gives, so you can match it against your triage answers.

Two details change what you should do. The first: the July fixes were released on 16.2.11 and 15.5.21, and by October the lines had moved on, so a team that "patched in July" and stopped is behind on a critical RCE. The second: the 22 September fix did not touch 15.x at all, which means a team on 15 is not exposed to that one. Read the right-hand column before you panic or relax.

Which versions get fixed

Next.js's support policy sets the lines: [4]

• Next.js 16: Active LTS. New features, bug fixes and security patches. It stays Active until the next major version is released.
• Next.js 15: Maintenance LTS. Critical bug fixes and essential security updates. Next.js says it extended 15's support beyond its original 21 October 2026 end date and will keep publishing security releases for 15 through 31 January 2027. Maintenance updates land as semver-minor releases, even if they are breaking.
• Next.js 14 and earlier: end of life, no support. The policy adds that in rare circumstances, depending on severity, Next.js will patch versions outside its LTS policy.

For you, that means three things. A fix for 14 is not planned, so the only route is to move up. A move to 15 buys until 31 January 2027, about three months, which is a stepping stone and not a destination. And because the August image-optimisation flaw affects versions back to 10.0.0, an app on 14 is exposed to it with nowhere to patch to inside its own line. [6]

What fixing it involves

1. The stopgap, for today

If you cannot upgrade this week, these reduce exposure and do not remove it:

• sharp 0.35.5 or later. Next.js names this as the workaround for CVE-2026-96889. [5] Check with npm ls sharp. Upgrading Next.js to a fixed version brings a fixed sharp with it.
• Tighten images.remotePatterns. The September request-forgery flaw only applies if remote patterns are configured, and a narrow allow-list is safer than a broad one. [9]
• Never expose next dev. The development server's endpoint discloses project paths, source snippets and logs to a malicious page the developer visits. [9]
• Use your host's firewall rules. Next.js says it coordinates with hosting providers so mitigations such as firewall rules protect apps that have not yet patched. [1] That buys time. It is not a patch.
• Reduce what the container can reach, which is where Binance's story lands. Run as a non-root user, remove secrets the app does not need, scope the cloud role to the minimum, and block the container from the cloud metadata address. These are my recommendations, not Next.js's.

2. Choosing the target

If the app has a future, plan for 16 and treat 15.5.28 as the first step, not the finish.

3. Next.js 14 to 15

From Next.js's upgrade guide: [15]

• React 19 is the minimum. useFormState becomes useActionState. Peer-dependency conflicts with other packages are common, and the guide has a recovery checklist.
• Request APIs become asynchronous. cookies(), headers(), draftMode(), params and searchParams must be awaited. A codemod does most of it, and anything it cannot do is left as UnsafeUnwrapped casts or error comments that you must resolve.
• Caching defaults flip. fetch requests are no longer cached by default, GET route handlers are no longer cached by default, and page segments are no longer reused from the client cache on navigation. This is the one that changes cost and speed in production without any error.
• Smaller changes: experimental-edge now errors and must be edge, @next/font is removed in favour of next/font, two experimental options are renamed (bundlePagesRouterDependencies, serverExternalPackages), and NextRequest loses geo and ip, which your host provides instead.
• The upgrade codemod is npx @next/codemod@canary upgrade latest.

4. Next.js 15 to 16

From the 16 guide: [16]

• Node.js 20.9 or later, TypeScript 5.1 or later, and recent browsers.
• Turbopack by default. If your project has a custom webpack configuration, next build fails until you move it to Turbopack options, or pass --webpack. A plugin that adds a webpack option can cause this without you writing one.
• Synchronous access to the request APIs is removed, not just deprecated.
• middleware becomes proxy. The Edge runtime is not supported in proxy, which runs on Node.js. If you rely on Edge middleware, you keep middleware and plan separately.
• next/image defaults tighten: minimumCacheTTL goes from 60 seconds to 4 hours, images.qualities defaults to [75] only (other values are coerced), local IP optimisation is blocked unless you allow it, redirects are capped at 3, and local images with query strings need localPatterns. A direct /_next/image request with an unsupported q returns 400.
• Parallel route slots need a default.js, or the build fails.
• Removals: next lint, AMP, serverRuntimeConfig and publicRuntimeConfig, several devIndicators options and experimental.dynamicIO.
• Caching APIs change: revalidateTag now needs a second argument, and cacheLife and cacheTag lose their unstable_ prefix. Enabling cacheComponents is not a rename. It can surface build errors and needs the Cache Components model.
• Codemods: npx @next/codemod@canary upgrade latest, and npx @next/codemod@canary next-async-request-api . if you still read the request APIs synchronously.

The guide closes with a point that matters more than any single change: a green build alone does not close runtime findings. You have to run the paths that earn money.

5. Release and prove it

• Build in CI on the new version, run the tests, then run staging against production-shaped data and walk the paths that earn money: sign-up or checkout, the admin, any form that posts, image-heavy pages and anything behind login.
• Check the deployed version, not the repository: the node -p command above, run in the artifact you actually deploy.
• Review the container after the upgrade. Which secrets and cloud permissions does it hold?
• Write down the date, the version, who confirmed it and how, and where the next advisory notice will be read.
• Keep the rollback ready until a normal week of traffic has passed.

What makes it hours and what makes it weeks

What you can do yourself, and what needs a developer

Do today, yourself:

• Run the triage and write the answers down.
• Check the deployed version and npm ls sharp.
• Look at your hosting platform's security notices and firewall settings.
• Apply the stopgaps you can, and remove secrets the container does not need.
• Find out who is named against the monthly upgrade.

Needs a developer:

• Any move off Next.js 14 or earlier.
• Any app using Server Actions, Cache Components or a custom server on a version that is behind.
• An app where the original developer has gone.
• Anything handling payments or personal data without tests.
• Reviewing what the container can reach, and proving the fix.

What I would do, and how it starts

I'm DC. I have 18 years in this work, I have audited 110 sites, and I do all of it myself. For a Next.js product it goes like this.

1. A free 30-minute call. You tell me what the app does, where it runs and who built it. I tell you what the first step is.
2. A first read, at a published price. The backend audit covers custom applications in Next.js and Node: £1,200 at grey box (read-only access to the code and accounts) or £1,500 at white box (the servers and database too), excluding VAT, five to ten working days from kickoff with a firm date before it starts. You get a written report in plain terms, ranked by what each finding costs you, with file and line references. It would cover the version, the features that put you in range of each advisory in the ledger, and what the container can reach. You own the report and can hand it to your own developer.
3. A written scope and price for the upgrade, before any work starts. Priced on the value of the work, with a deposit before work begins. A move from 14 to 16 is a project, quoted per app, not part of a monthly retainer's time.
4. The work. Staging first, tests, the move through 15.5.28 and then 16 where it makes sense, the release, a review of the container's access, and a note of what changed.
5. Keeping it done. A retainer keeps a healthy stack current inside an agreed amount of monthly time, and a version move is quoted separately. For Laravel and PHP products that is the SaaS maintenance retainer, priced per product.

If the app was left half-finished by a previous team, the project takeover service starts with the same first read. For Next.js front ends in front of a headless CMS, see headless CMS and Next.js builds, and for products built from scratch, bespoke builds. If you have nobody senior to own these decisions at all, an interim or fractional CTO covers that gap.

What I need from you to start: the repository access you are happy to give (read-only is enough for the audit), where it is hosted, who deploys it, and the one or two paths that must not break.

The first step is a free call. If you would rather write it down first, use the contact page.

Related services

A Next.js app is usually bespoke work, and the bespoke builds page sets out how I take one over and keep it patched. For a shop on Next.js, the Shopify developer page covers the storefront side. To find out which versions and features you are really running, start with the backend audit.

Questions people ask

We host on Vercel. Are we covered? Partly. Some flaws, such as the September cache poisoning of static and incremental pages in self-hosted apps, do not affect apps on Vercel. [9] Others depend on your code and features, so you still need to be on a fixed version and to check the advisories against what you use.

Is the 3 November release an emergency? It is rated medium, with seven issues, so plan it. [3] The point of the schedule is that you know a month ahead.

Can we stay on Next.js 14? There is no patched 14. The August image flaw reaches back to version 10, and the fixed versions Next.js lists are 15.5.24 and 16.3.3. [6]

Is 15 good enough? It is patched, and its security releases are guaranteed to 31 January 2027. [4] For anything that will run past that, plan for 16.

Will the upgrade change how fast the app is, or what it costs to host? It can, in both directions. The caching defaults changed in 15, and the image defaults changed in 16. Check performance and hosting cost on staging before the release.

Does a retainer cover the upgrade? No. A retainer keeps a healthy stack current inside an agreed amount of monthly time. A version move off 14 is a project, quoted on its own.