Next.js 16.4.1 fixes two critical RCEs: one has no CVE id or workaround, GitHub's feed lagged 8 days (read 25 Oct 2026)

Three minutes after the package, the advisory; eight days later, the database

The Next.js 16.4.1 package reached the npm registry at 17:43:55 UTC on 14 October 2026. Vercel's advisory for its critical use cache flaw, GHSA-673q-mjm6-r5xr, was published 3 minutes 11 seconds later (derived from the registry's publish time and the advisory's own timestamp). GitHub's Advisory Database, the list that Dependabot alerts are generated from, published the same advisory on 22 October at 16:42 UTC, 7 days 22 hours 55 minutes after the Next.js advisory (derived). On Sunday 25 October the advisory still has no CVE id, and Vercel says there is no known workaround.

That sequence does not establish that anyone was attacked, that a particular scanner failed a particular customer, or that any given application could be reached. Vercel's post says nothing about exploitation either way. CISA's Known Exploited Vulnerabilities catalogue, version 2026.10.23, lists none of the ids in this story, and a missing listing is not evidence that nothing is happening. What the sequence does show is how far behind the fix the places defenders usually look were. That is a measurable gap, not an opinion.

The story as first reported said two of the three issues had no CVE id, and that the SVG flaw scored 9.5 in one place and 7.8 in another. Reading the primaries changes parts of that. The Server Actions denial of service received CVE-2026-94482 on 22 October. The SVG flaw's id, CVE-2026-96889, was assigned by Red Hat on 23 September to the librsvg library, three weeks before the Next.js release, and it carries a different score because it scores a different thing. Only the use cache flaw has no id at all. Each difference is set out below.

Everything here was read between about 17:46 and 18:16 UTC on Sunday 25 October 2026, from Vercel's own post and advisories, the React and sharp advisories, the librsvg advisory, the CVE and NVD records, the GitHub Advisory Database, the npm registry and the public Next.js source. A CVE id, a database listing or a host statement can appear within hours, so each claim of that kind carries its read time. The Hacker News report of 15 October was read as a secondary source. The Cloud Security Alliance note named in the first reports could not be read, because its site put up a browser check that this site did not attempt to pass. This site covered the first week of the story on 15 October, and the August image decoder flaw in an earlier briefing. This one adds the record that was not yet there on 15 October.

The sequence, and the clocks that follow from it

The diagram shows the four stages. The table under it gives each event with its time and where it was read. All times are UTC. Day and hour counts are derived by this site from the printed timestamps (calc.py in the folder shows the arithmetic).

Zoom

Two things in the table are easy to miss. First, Vercel's own words for the 14 October release are an out of band update, yet it was announced six days earlier, and two of its three fixes had been postponed from the 30 September scheduled release. Second, the fix for the SVG flaw's underlying library, sharp 0.35.5, was on npm 17 days 3 hours 57 minutes before next 16.4.1 (derived). Anyone who had sharp as a direct dependency and watched its advisory could have known on 6 October, 8 days before the Next.js release. Anyone who relied on Next.js to bring the fix had to wait for 14 October.

The three issues: stated and not stated

The table keeps what Vercel and React state apart from what they leave out. "Not stated" means not found in the advisory, the Vercel post or the linked records, all read in full. It does not mean the information does not exist.

Vercel's post pairs two of its advisories with React advisories: GHSA-673q with GHSA-xqc2, and GHSA-p3m5 with GHSA-h3gv. The fix commit for the first, as listed on the Next.js advisory, changes files under the copy of the React server packages that Next.js bundles (packages/next/src/compiled/react-server-dom-*, read from the commit's file list). That is why upgrading a standalone React package in your tree does not close the Next.js flaw, and why an application on another framework that uses those packages has its own, separate upgrade path (inference from the commit; this site did not diff the packages).

Which versions are in range, and where the sources disagree

The question "which versions are vulnerable" has a clean answer for 16.x and a messy one for everything older. Counting published stable releases on the registry (derived): 284 of 424 fall in the SVG range, 226 in the Server Actions range and 43 in the use cache range. Every 16.x release up to 16.4.0 is in all three. Every 15.x release up to 15.5.27 is in the first two, and Vercel lists none for the third. Releases 16.4.1, 16.4.2 and 16.4.3 are fixed: the 16.4.2 release notes link a comparison from v16.4.1, so it builds on the fix (this site did not diff the code).

Lines 10 to 14 are the awkward case. The SVG advisory's range starts at 10.0.0 and the Server Actions range at 13.0.0, yet the only patched versions either lists are 15.5.28 and 16.4.1. No patched 14.x, 13.x, 12.x, 11.x or 10.x release is named, and the newest 14.x on the registry is 14.2.35, from 11 December 2025 (derived, 46 stable 14.x releases). Vercel's support policy page lists 16.x as Active LTS and 15.x as Maintenance LTS, and 14.x and older as unsupported. It adds that in rare cases it patches outside that policy, and it did not here. The page also says each major stays in Maintenance LTS "for two years following the initial release" and gives 21 October 2024 as the 15.x release date. If that two years counts from that date, it ended four days before this read, a week after 15.5.28 shipped. The page states no end date for 15.x, so this is a question to put to Vercel, not a finding.

One library bug, three scores: 9.5, 8.9 and 7.8

The 9.5 and the 7.8 come from different scoring systems, and they also score different objects. The vectors are printed in full in the technical details below. The table shows the metrics that decide the difference.

Red Hat scored the library as opened by a person on a machine, so the vector is local and needs user interaction. Its own statement says exploitation "requires user interaction, such as opening a malicious SVG file". Vercel scored the framework as a server that decodes images in response to web requests, so the vector is network with no interaction. The sharp maintainers sit between: local, no interaction. Their earlier advisory for an AVIF decoder flaw states the logic outright: the library's score used a network vector, "however sharp does not provide any networking features", so they scored it lower. That sentence explains the 8.9, though it is about a different flaw.

A derived check, using the CVSS 3.1 formula: Red Hat's vector reproduces 7.8 here. Changing only the attack vector to network gives 8.8. Changing only user interaction to none gives 8.4. Changing both gives 9.8. So within one version those two metrics alone account for the gap: 7.8 becomes 9.8, which sits close to Vercel's 9.5. That 9.5 is a version 4.0 score, and scores from 3.1 and 4.0 are not on one scale, so the comparison is a guide to cause and not a like for like match.

CISA's enrichment of the CVE record, dated 25 September, adds a different kind of rating for the library flaw. It records exploitation as poc, automatable as no and technical impact as total, and it tags the librsvg issue link with the reference tag exploit. In CISA's decision guide the value Public PoC means a typical public proof of concept exists, or the vulnerability has a well known method of exploitation. This site did not open the librsvg issue (the host refused the request) and describes none of it. Vercel's post is silent on proof of concept code, so the report that Vercel has not confirmed a public proof of concept is accurate but incomplete: CISA's record says one exists for the library flaw, which is not the same as one for the Next.js code path.

Which ids exist, and who can see them

Tools find flaws by id. These three flaws have an uneven set of ids, and the set changed between 14 and 25 October.

Of the five critical advisories in the Next.js repository in 2026, two have no CVE id at read: this one and the AVIF flaw of 25 August (derived from the repository's advisory list). The longer pattern is in the lag. All five reached the GitHub Advisory Database between 7.91 and 14.21 days after the Next.js repository published them (derived). GitHub's own documentation for Dependabot alerts says alerts fire when a vulnerability is added to the Advisory Database, that "New vulnerabilities may take time to appear" there, and that only advisories reviewed by GitHub trigger alerts. The delay is therefore inside the documented limits of the tool, which is the point: the limit is documented and still surprising.

The npm registry's bulk advisory endpoint, the one the npm audit command is documented to query, answered at 18:04 UTC on 25 October with all three Next.js advisories for next 16.4.0, two of them for 15.5.27, none for 16.4.1 or 15.5.28, and sharp's librsvg advisory for sharp 0.35.4 and 0.34.5. So the claim in the 15 October coverage, that npm audit was silent on two of them, is no longer true. The Hacker News said so on 15 October. This site could not test that day, and the 22 October listing date is consistent with it. Inference, labelled: a tool keyed only to CVE ids or to NVD product records would have found nothing for use cache, would have matched CVE-2026-96889 to Red Hat's librsvg2 packages rather than to an npm package, and would have found the denial of service only from 22 October.

Five friendly names, and what the record shows

A label can stand in for a control. Five appear in this story.

Interests, in one sentence each. Vercel maintains Next.js and sells the hosting it runs best on, and its own platform statement for October was not found. Netlify and Pantheon sell hosting for Next.js applications and each has a commercial interest in how exposed its platform looks. Red Hat sells support for the Linux distributions that ship librsvg2, and its score describes that use. The sharp maintainers publish a free library and scored its exposure. None of this suggests the facts are wrong. It tells you whose framing each number carries.

The sharp range on the 15.5 line, and a workaround that may not hold

Vercel's advisory says that upgrading Next.js "will ensure package managers automatically provide a fixed version of sharp". The registry metadata shows that this is true for 16.4.1 and only partly true for 15.5.28. next 16.4.1 asks for sharp ^0.35.5. next 15.5.28 asks for sharp ^0.34.3 || ^0.35.5, which still admits the 0.34 line. sharp's advisory lists every version below 0.35.5 as vulnerable, and 0.34.5, from November 2025, is the last 0.34 release. A semver check with npm's own library (npm 11.12.1) confirms that 0.34.5 satisfies the 15.5.28 range and does not satisfy the 16.4.1 range. A fresh install resolves to the highest match, 0.35.5. An existing lockfile that already pins 0.34.5 is not forced to move by a range that still accepts it. That is the package manager's documented behaviour, and this site did not run an install to confirm it. The Hacker News made the same observation on 15 October.

Two nuances follow, both derived from registry data. First, npm's audit endpoint still flags sharp 0.34.5 through sharp's own advisory, so an audit of the tree shows the gap even when the Next.js check is clean. Second, sharp 0.35.5 requires Node 20.9.0 or later, while sharp 0.34.5 and next 15.5.28 both accept Node 18. A deployment on Node 18 and the 15.5 line therefore cannot reach the fixed sharp without also changing Node.

The block workaround needs more care. sharp's advisory suggests calling sharp.block on the SVG loader. Next.js's own code does the opposite when it first loads sharp: it blocks every loader, then unblocks a list that includes the SVG loader (the lines are in the technical details). sharp's documentation describes block and unblock as runtime settings that act on libvips operations. If the later call wins, an application's earlier block would be undone inside a Next.js process (inference from the source and the documentation; this site did not test it, because testing means installing native binaries). Treat the upgrade as the control and the block as something to verify, not assume.

One more observation from the same source file, offered as an open question and not as a finding. In the v16.4.0 source, an SVG that the optimizer detects is refused unless dangerouslyAllowSVG is true, and when it is true the SVG type sits on a bypass list that returns the original bytes without passing them to sharp. This site could not trace a decode of an SVG by librsvg through that path. That does not contradict Vercel: the path may be another one (Netlify names next/og), the content type detection may differ from the file's own, and this site tested nothing. It does mean the advisory's title and the code this site read do not obviously match, and Vercel has not said which path it means. A team that has dangerouslyAllowSVG off should not read that as proof of safety until Vercel does.

What the hosts, Singapore and the NCSC say

A host that patches for you is not the same as a host that says it has. Of the two host statements read, Pantheon says it patched nothing on the customer's behalf, and Netlify says one path is not exercised on its platform. Neither says the customer's own build is fixed. On any platform that builds your application, the fixed artefact is the thing to confirm, and preview deployments count.

Technical details

These are the artifacts the primary sources publish, copied exactly and attributed in each caption. Each block is explained in plain words above it. Anything this site worked out is marked derived. The primaries print no working exploit, and none is reproduced here. They also print no log line, request signature or detection rule for any of the three flaws, and this briefing does not invent one.

Block 1 is the upgrade instruction from Vercel's post. The comments are Vercel's. Run it for each application, then rebuild and redeploy, because the package file in a checkout is not the artefact that is serving requests. Source: Vercel's post of 14 October 2026, read 25 October 2026.

npm install next@15.5.28 # for 15.5
npm install next@16.4.1 # for 16.4

Block 2 is the text of the use cache advisory as Vercel published it in its repository, with the version ranges and the score fields. This is the flaw with no CVE id and no workaround. The only condition printed is an App Router application with Cache Components and a use cache function that returns multiple typed arrays. Source: the vercel/next.js repository advisory, read 25 October 2026.

## Impact

A vulnerability in applications using App router with Cache Component can lead to remote code execution. The application needs to have a `use cache` function that returns multiple typed arrays.

## Workaround

There is no known workaround for affected applications with such `use cache` functions. You should upgrade immediately even if your application does not have similar functions.

Package and versions (as printed):
  next vulnerable >=16.0.0 <= 16.4.0 patched 16.4.1
CVSS v4 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:N
CVSS v4 score: 9.5
CVE id: none

Block 3 is React's advisory for the same flaw. It lists the three packages and the patched releases, and it carries the extra condition that Vercel's text omits: an attacker controlled value. Note the typo as printed in its text, 19.0.09. The structured field, and the registry, say 19.0.9. Anyone running another framework on these packages uses this block, not block 1. Source: the React repository advisory, read 25 October 2026.

### Impact

Crafted payloads targeting frameworks supporting React Server Components can lead to remote code execution. This only affects extremely rare cases where responses transport multiple typed arrays and an attacker-controlled value.

We recommend updating immediately.

The vulnerability exists in versions 19.0.0 through 19.0.8, 19.1.0 through 19.1.9, 19.2.0 through 19.2.8 and 19.3.0 of:

- react-server-dom-webpack
- react-server-dom-parcel
- react-server-dom-turbopack

### Patches

Fixes were back ported to versions 19.0.09, 19.1.10, 19.2.9, and 19.3.1.

If you are using any of the above packages please upgrade to any of the fixed versions immediately.

If your app’s React code does not use a server, your app is not affected by this vulnerability. If your app does not use a framework, bundler, or bundler plugin that supports React Server Components, your app is not affected by this vulnerability.

Patched versions (structured field): 19.0.9, 19.1.10, 19.2.9, 19.3.1
CVSS v4 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:N
CVSS v4 score: 9.5
CVE id: none

Block 4 is the SVG advisory. It names no setting and no code path, only an upstream memory flaw and the condition glibc based Linux. Its workaround is a dependency version, sharp 0.35.5 or later. Source: the vercel/next.js repository advisory, read 25 October 2026.

<!-- https://linear.app/vercel/issue/NSEC-386 -->

## Impact

A memory-related vulnerability has been discovered in an upstream library used for Image Optimization can lead to possible remote code execution (RCE) when Next.js runs on glibc-based Linux.

## Workaround

Ensure the version of `sharp` used by Next.js is greater than or equal to `0.35.5`. Fresh installs automatically get a fixed version fo `sharp`.
Upgrading Next.js to the patched versions will ensure package managers automatically provide a fixed version of `sharp` to Next.js.

Package and versions (as printed):
  next vulnerable >= 10.0.0  <= 15.5.27 patched 15.5.28
  next vulnerable > 16.0.0 <= 16.4.0 patched 16.4.1
CVSS v4 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
CVSS v4 score: 9.5
CVE id: CVE-2026-96889

Block 5 is the denial of service advisory, with the CVE id it gained on 22 October. The repository page still showed no CVE id on its own advisory record, while CVE.org and GitHub's database showed CVE-2026-94482. Source: the vercel/next.js repository advisory and CVE.org, read 25 October 2026.

<!-- https://linear.app/vercel/issue/NSEC-359 -->

## Impact

Crafted requests targeting Next.js applications using App Router with at least one Server Action can lead to excessive CPU usage blocking processing of further requests in the same process.

## Workarounds

No workaround exists besides upgrading. Applications using Pages Router or not using Server Actions are not vulnerable.

Package and versions (as printed):
  next vulnerable >=13.0.0 <= 15.5.27 patched 15.5.28
  next vulnerable >= 16.0.0 <= 16.4.0 patched 16.4.1
CVSS v4 vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
CVSS v4 score: 8.2
CVE id: CVE-2026-94482 (CVE.org, 22 October 2026)

Block 6 is sharp's own advisory for the library flaw. It is the only primary that says how to block SVG decoding in code, what the patched librsvg version is, and that the Node binary matters. The binary condition is the one most teams will not know about: sharp warns that the official Node.js binaries are not built as Position Independent Executables. The advisory's last line points to the librsvg issue, which this site did not open. Source: the lovell/sharp repository advisory, read 25 October 2026.

### Impact

A memory-related vulnerability has been discovered and fixed in the upstream librsvg dependency. When certain runtime-specific conditions apply, this vulnerability can lead to possible remote code execution (RCE) on glibc-based Linux.

### Patches

#### Using prebuilt binaries provided by sharp?

Most people rely on the prebuilt binaries provided by sharp.

Please upgrade sharp to the latest version, currently 0.35.5, which provides librsvg 2.63.2.

#### Using a globally-installed librsvg?

Please ensure you are using the latest librsvg 2.63.2.

### Workarounds

Add the following to your code to prevent sharp from decoding SVG images.
```js
sharp.block({ operation: ["VipsForeignLoadSvg"] });
```

To avoid RCE, ensure you are using a `node` executable binary compiled as a Position Independent Executable (PIE). Most Linux package managers already use this security-hardening feature however be warned that the "official" Node.js binaries do not.

### References

- [CVE-2026-96889](https://www.cve.org/CVERecord?id=CVE-2026-96889)
- https://gitlab.gnome.org/GNOME/librsvg/-/work_items/1241

Block 7 is the library advisory from the Rust security database. It lists the librsvg releases that contain the fix and gives the aliases that tie the library flaw to the Next.js advisory. Red Hat's page says the flaw was fixed upstream in 2.63.1, while RustSec and sharp name 2.63.2: the three sources do not agree on the first fixed release. Source: rustsec.org and the Red Hat CVE page, read 25 October 2026.

Package: librsvg (crates.io)
Aliases: CVE-2026-96889, GHSA-cpvr-w4j5-2mpg
Patched:
  >=2.63.2
  >=2.62.4, <2.62.90
  >=2.61.5, <2.61.90
  >=2.60.3, <2.61.0
  >=2.57.5, <2.57.90

Librsvg uses libxml2, a C library, to parse XML.  When librsvg parses
an SVG document which has a nested Xinclude, an XML entity declaration
with a duplicate name as an existing one can cause a use-after-free error.

Block 8 collects the scores and ratings for the library flaw in one place: Red Hat's CVSS 3.1 vector and rating, Red Hat's statement and mitigation line, and CISA's enrichment. The values are printed as the records give them. Sources: CVE.org, the NVD and Red Hat, read 25 October 2026.

CVSS 3.1 vector (Red Hat): CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
CVSS 3.1 base score: 7.8 HIGH
Red Hat severity rating: Important
CWE: CWE-416 Use After Free

SSVC (CISA-ADP, role CISA Coordinator, 2026-09-25T17:53:42Z):
  Exploitation: poc
  Automatable: no
  Technical Impact: total

Red Hat statement: Exploitation requires user interaction, such as opening a malicious SVG file. The issue has been fixed upstream in version 2.63.1.
Red Hat mitigation: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.

Block 9 is the package metadata that explains the sharp range gap. It is a plain listing of fields from the registry's published records, laid out by this site (the values are as printed, the layout is derived). Source: registry.npmjs.org, read 25 October 2026.

next@15.5.27  optionalDependencies.sharp = ^0.34.3 || ^0.35.4
next@15.5.28  optionalDependencies.sharp = ^0.34.3 || ^0.35.5
next@16.4.0  optionalDependencies.sharp = ^0.35.4
next@16.4.1  optionalDependencies.sharp = ^0.35.5

sharp@0.34.5  engines.node = ^18.17.0 || ^20.3.0 || >=21.0.0
sharp@0.35.4  engines.node = >=20.9.0
sharp@0.35.5  engines.node = >=20.9.0
next@15.5.28  engines.node = ^18.18.0 || ^19.8.0 || >= 20.0.0
next@16.4.1   engines.node = >=20.9.0

Block 10 is the public Next.js source that matters for the SVG question. The first part is how Next.js prepares sharp: it blocks every loader and then unblocks a list that includes the SVG loader. The second is the check that refuses an SVG unless dangerouslyAllowSVG is true. The third is the bypass list that returns an SVG's bytes unchanged. Whether these lines are the whole story for the flaw is the open question in the section above. Source: the public vercel/next.js repository at tag v16.4.0, read 25 October 2026.

const ANIMATABLE_TYPES = [WEBP, PNG, GIF]
const BYPASS_TYPES = [SVG, ICO, ICNS, BMP, JXL, HEIC]
// ...
  try {
    _sharp = require('sharp') as typeof import('sharp').default
    _sharp.block({ operation: ['VipsForeignLoad'] })
    _sharp.unblock({
      operation: [
        'VipsForeignLoadHeif', // avif
        'VipsForeignLoadJpeg',
        'VipsForeignLoadNsgif',
        'VipsForeignLoadPng',
        'VipsForeignLoadSvg',
        'VipsForeignLoadTiff',
        'VipsForeignLoadWebp',
      ],
    })
// ...
  if (
    upstreamType.startsWith('image/svg') &&
    !nextConfig.images.dangerouslyAllowSVG
  ) {
    opts.logger?.error(
      `The requested resource "${href}" has type "${upstreamType}" but dangerouslyAllowSVG is disabled. Consider adding the "unoptimized" property to the <Image>.`
    )
    throw new ImageError(
      400,
      '"url" parameter is valid but image type is not allowed'
    )
// ...
  if (BYPASS_TYPES.includes(upstreamType)) {
    return {
      buffer: upstreamBuffer,
      contentType: upstreamType,
      maxAge,
      etag: upstreamEtag,
      upstreamEtag,
    }

Block 11 is the Next.js documentation's own configuration for SVG, and the setting name that the 30 September advisory gives for Cache Components. These are the settings to search for in a repository. The docs print the first pair of settings together as the recommended safeguards when SVG is allowed. Sources: the Next.js documentation and the 30 September 2026 advisory, read 25 October 2026.

// next.config.js, from the Next.js docs (dangerouslyAllowSVG):
module.exports = {
  images: {
    dangerouslyAllowSVG: true,
    contentDispositionType: 'attachment',
    contentSecurityPolicy: "default-src 'self'; script-src 'none'; sandbox;",
  },
}

// From the GHSA-h694-7cp9-m8p3 text: Cache Components enabled
cacheComponents: true

Block 12 is the pattern that Vercel's 22 September advisory printed for the earlier next/og flaw: attacker controlled text passed into SVG content. Netlify says the October SVG flaw is also reachable through ImageResponse. This is a different advisory (CVE-2026-94545, fixed in 16.3.6) and is shown only so a defender knows the shape to search for. It is not a payload. The Hacker News reports a researcher tying the October librsvg flaw to the September one. No primary read says so: Vercel's September post names Satori and speaks of other upstream dependencies. Source: the vercel/next.js repository advisory of 22 September 2026, read 25 October 2026.

import { ImageResponse } from 'next/og'

export async function GET(request: Request) {
  const value = new URL(request.url).searchParams.get('value') ?? ''

  return new ImageResponse(
    <svg width="1200" height="630">
      <title>{value}</title>
    </svg>
  )
}

Block 13 is a set of defensive commands. They are not from any primary: this site wrote them, marked derived, from the registry and tool documentation. The sharp.versions call is the one sharp's own documentation shows for reading the bundled library versions. The registry query is the bulk advisory endpoint that npm documents for npm audit. The last line reads whether the Node binary is a Position Independent Executable, the condition sharp's advisory raises: EXEC means it is not and DYN means it is (derived reading of readelf output, Linux only). None was run against a project by this site.

# 1. Which Next.js and sharp are actually resolved, including inside containers and CI images
npm ls next sharp --all
npm explain sharp
# pnpm why sharp   or   yarn why sharp

# 2. Which React server packages a non-Next framework resolves
npm ls react-server-dom-webpack react-server-dom-turbopack react-server-dom-parcel --all

# 3. The bundled library versions inside the running process (sharp documentation)
node -e "console.log(require('sharp').versions)"

# 4. Where the features are used in the repository
grep -rn "use cache" app src 2>/dev/null
grep -rn "cacheComponents\|dangerouslyAllowSVG\|next/og\|ImageResponse" . --include=*.js --include=*.ts --include=*.tsx --include=*.mjs --exclude-dir=node_modules

# 5. Ask the registry what it knows (the bulk advisory endpoint npm documents)
curl -s -X POST -H "Content-Type: application/json" -d '{"next":["16.4.0"]}' https://registry.npmjs.org/-/npm/v1/security/advisories/bulk

# 6. Is the Node binary a Position Independent Executable (Linux)
readelf -h "$(command -v node)" | grep Type

What a defender can hunt for, as inference and not from a primary: sustained full CPU on a Next.js worker process, which is how Vercel describes the denial of service, and crashes or restarts of the Node process after requests to image or og endpoints, which is how Netlify describes the effect on its platform. No indicator of compromise, domain, hash or address is published for any of the three flaws, so there is nothing to defang here.

The UK: three clocks, and what each leaves open

UK guidance gives two different numbers of days for the same update, and a third source gives none. The 14 October release is already past the shorter one. Both numbers count from 14 October, the day the fixed package was available, and the dates are derived from that.

The three clocks disagree by design: 5 days, 14 days, and no number at all. A flaw with no CVE id does not change any of them. Cyber Essentials counts the vendor's word critical, and Vercel gave it. The harder question for a UK organisation is not which clock applies but whether its asset list contains the application at all, including the preview deployments Netlify says stay reachable until deleted.

What to do, in the order worth doing

What could not be verified

• The Cloud Security Alliance note. Its site returned a browser check, which this site did not pass. Its figures, including the CVSS 9.5 and the missing CVE ids, were checked against the primaries instead.
• The librsvg issue. The host refused the request, so the content that CISA tags as an exploit was not read and is not described.
• Researcher and exploit claims. The Hacker News says a researcher ties the librsvg flaw to the September next/og flaw and that a working exploit for that flaw has been published. No primary read confirms either.
• Which fixes were postponed. Vercel's posts do not say. The link to the SVG and Server Actions flaws is inference.
• The vulnerable path. Vercel's advisory names none. The public source read does not show it. Nothing was tested.
• The block workaround and lockfile behaviour. Not tested, because testing needs native packages installed. The reasoning rests on the source, the registry metadata and the documentation.
• Vercel platform and other hosts. No October statement from Vercel's own platform, Cloudflare or AWS was found.
• Exploitation. None found in the primaries read. Absence is not proof.
• The Maintenance LTS end date for 15.x. The support page states no date.
• Time stamps. Read between 17:46 and 18:16 UTC on 25 October 2026. A CVE id, a listing, a score or a host statement could change within hours.

The question that exposes the gap

If a critical flaw is fixed in a release your scanner cannot name, because it has no CVE id and the advisory feed is a week behind, who in your organisation is subscribed to the place where it was actually published, and how many days did it take them the last time?

Key facts