Post cover image
The scan behind this post: all 15 of my Next.js apps locked a version below the 14 October fix. Screenshot by the author, arranged into a cover.

October 18, 2026

Next.js Fixed Two Critical Holes on 14 October. All 15 of My Apps Ran an Unpatched Version.

I checked every Next.js app I own against the three conditions in the advisories. One returns the exact kind of data the worst bug needs.

By Noor Mohammad

5 min read

One of my Next.js apps has a cached function that hands back three ArrayBuffers. On 14 October, the Next.js team shipped a fix for a critical bug in exactly that kind of function, and wrote that "there is no known workaround for affected applications."

The function loads fonts for share images in arena, a side project of mine, and it has been in the repo that way since 30 September. When I read the advisory I didn't know how many of my other apps were in the same spot, so I wrote a scanner, ran it read-only across my GitHub folder, and counted.

The short version: all 15 of my own Next.js apps were on a version older than the fix. That number sounds worse than it is, and also better than it is, depending on which of the three bugs you're looking at.

Three bugs, three different triggers

The Next.js security post covers three issues, patched in 16.4.1 and 15.5.28. They don't hit the same apps.

A crop of the Next.js blog post dated 14 Oct 2026, titled "Next.js Security Update for Upstream Vulnerabilities". It says updates are available in v16.4.1 (Active LTS) and v15.5.28 (Maintenance LTS), and shows a terminal box with "npm install next@15.5.28 # for 15.5" and "npm install next@16.4.1 # for 16.4".

The first is an unauthenticated remote code execution in use cache functions "returning typed arrays", rated Critical, 9.5 on CVSS v4. Its advisory limits it to apps on the App Router with Cache Components, on versions 16.0.0 through 16.4.0, and says to upgrade even if you don't have such a function.

The second is another 9.5, in the Image Optimization API. This one comes from the image library underneath and only applies "when Next.js runs on glibc-based Linux". It reaches all the way back to 10.0.0, and the workaround is making sure sharp is 0.35.5 or later.

The third is a denial of service rated High, 8.2. It needs the App Router and "at least one Server Action", and it covers every version from 13.0.0. Apps that only use the Pages Router are fine.

That 13.0.0 matters if you're on an older major. The newest 14.x on npm is 14.2.35, published in December 2025. There is no patched 13 or 14. The fix lives in 15.5.28 and 16.4.1, and npm's latest was already 16.4.2 by 15 October.

What the scan found

The script reads each repo's lockfile for the locked next and sharp versions. It counts use cache directives and "use server" files in the source, checks next.config for cacheComponents, and looks at Dockerfiles and vercel.json to see how each app ships. It never opens .env files and prints counts, not code. I left out one client project; this is my own code only. All the scripts and outputs will be in a gist (GIST LINK TO ADD BEFORE SUBMITTING).

$ python3 -I exposure_scan.py
repos with Next.js 13-16 in a lockfile (client work excluded): 15
on a version inside the advisories' ranges (fixed in 16.4.1 / 15.5.28): 15

repo                  next (locked)             sharp            use cache server act.  app/  ships as
arena                 16.3.8                    0.35.5               5+cfg           2   yes  vercel.json
backpack-blog         16.2.7                    0.34.5                   0           1   yes  no Dockerfile or vercel.json
beauty-booth          16.3.5                    0.35.4                   0          26   yes  vercel.json
developer-portfolio   16.3.4                    0.35.4                   0           1   yes  no Dockerfile or vercel.json
fashion-ecommerce     16.3.4                    0.35.4                   0           8   yes  no Dockerfile or vercel.json
grovia                16.3.5                    0.35.4                   0          26   yes  vercel.json
kona-web              16.2.7                    0.34.5               2+cfg           0   yes  vercel.json
mailforge             16.2.7                    0.34.5                   0          16   yes  no Dockerfile or vercel.json
nomad                 16.2.7                    0.34.5                   0           0   yes  no Dockerfile or vercel.json
prime-store           16.2.11                   0.34.5                   0           0   yes  no Dockerfile or vercel.json
reactbd_2025          16.2.4                    0.34.5                   0          28   yes  vercel.json
shopcart-pro          16.4.0                    0.35.5                   0           9   yes  vercel.json
staybnb               16.3.2                    0.34.5, 0.35.3           0           0   yes  vercel.json
voltmart              16.2.4                    0.34.5                   0           9   yes  vercel.json
zenvex                16.2.3                    0.34.5                   0           0   yes  vercel.json

use cache RCE (needs Cache Components + use cache): 2 repos: arena, kona-web
Server Actions DoS (App Router + at least one Server Action): 10 repos
image RCE needs glibc Linux: repos with a glibc Node Docker image: 0: none
repos whose locked sharp is already >= 0.35.5: 2
repos that set dangerouslyAllowSVG: 0

My first pass at this got the count wrong. A quick grep for next@ across the lockfiles reported 16 repos, with versions like 17.0.16 and 26.4.5 mixed in. Those weren't Next.js at all, just other packages whose names end in "next", plus the client project. The script above parses each lockfile format properly and drops anything outside 13 to 16.

shopcart-pro is the one that stings. It was on 16.4.0, released 6 October, one version before the fix.

The function that returns three ArrayBuffers

Two apps use Cache Components, so only those two can have the worst bug. A second script lists every use cache function in them and flags any file that mentions a typed array:

$ python3 -I use_cache_check.py arena kona-web
arena: 5 files with a 'use cache' directive (7 directives); cacheComponents: true in next.config.ts
  src/app/sitemap.ts  directives 1  typed array mentioned: no
  src/lib/og.ts  directives 1  typed array mentioned: YES
  src/lib/server/share.ts  directives 1  typed array mentioned: no
  src/lib/server/bradley-terry.ts  directives 1  typed array mentioned: no
  src/lib/server/leaderboard.ts  directives 3  typed array mentioned: no
kona-web: 2 files with a 'use cache' directive (2 directives); cacheComponents: true in apps/web/next.config.ts, apps/admin/next.config.ts
  apps/web/src/server/catalog.ts  directives 1  typed array mentioned: no
  apps/web/src/i18n/get-dictionary.ts  directives 1  typed array mentioned: no

src/lib/og.ts is the font loader from the top of this post. It's a use cache function, cached for the life of the deploy, that reads three .woff files and returns each one as an ArrayBuffer for the share-card renderer. The comment above it even says why: plain ArrayBuffers "survive the cache's serialization". That's the risky shape.

This is where I'm unsure, and I'd rather say it plainly. The advisory says "typed arrays", and an ArrayBuffer isn't technically a typed array. It's the memory a typed array sits on. I don't know whether this exact function is exploitable, and the advisory doesn't spell out the payload. It does say to upgrade anyway, so I'm not going to argue with it over a definition.

kona-web's two cached functions return a product catalog and a dictionary of translations. Neither touches binary data.

Ten apps with Server Actions

The denial of service is less dramatic and much more widespread. Ten of my fifteen apps have at least one "use server" file. The most are in reactbd_2025, with 28 files, and grovia and beauty-booth, with 26 each.

The advisory describes a crafted request that makes the server burn CPU. While it does, the same process can't serve anyone else. The advisory's own words: "No workaround exists besides upgrading." This is the one I'd patch first on anything with real users. It doesn't take a clever attacker. It takes someone who has read the same advisory.

The image bug needs Linux, and none of mine ship on it

None of my apps runs in a glibc-based Docker image. Nine deploy to Vercel through vercel.json, and the other six have no deploy config in the repo at all. By the advisory's own wording, the image bug shouldn't reach a laptop or a Mac.

I can't tell you whether that makes the Vercel ones safe. Vercel's own image optimizer runs on Vercel's machines, not in my function. Vercel's changelog for that week says nothing about this advisory, and neither does the advisory say anything about Vercel. Only two of my repos already lock sharp 0.35.5. The other thirteen sit on 0.34.5, 0.35.3 or 0.35.4, so anyone who self-hosts one of them on Linux is relying on the patch.

One bias to own: most of what I build runs on Next.js, so I'd like this to be small. It mostly is, as long as you upgrade.

The upgrade, in the order I'd do it

Start with whatever has Server Actions and real users, then anything with Cache Components, then the rest. For each repo:

npm install next@16.4.2
pnpm up next@16.4.2 --recursive

Then check that the lockfile actually moved, and that sharp came along:

npm ls next sharp

On 15.x, the line is npm install next@15.5.28. On 13 or 14, there's no patch on your major, so you're moving to 15.5.28 at least.

If you want to know which bug applies before you upgrade, three searches in your src or app folder answer it in a minute:

grep -rln "use cache" --include="*.ts" --include="*.tsx" .
grep -rln "use server" --include="*.ts" --include="*.tsx" .
grep -rn "ArrayBuffer\|Uint8Array" --include="*.ts" --include="*.tsx" . | grep -v node_modules

If the first and third find the same file, open it before you do anything else today.