Next.js Vulnerability: 8 Days Dependabot Stayed Silent

On 14 October 2026, Next.js released 16.4.1 and 15.5.28 to fix three vulnerabilities: two remote code executions rated 9.5 out of 10 (CVSS v4) and a denial of service rated 8.2. The three matching GitHub advisories only entered the reviewed database — the one Dependabot and most dependency scanners read — on 22 October, between 15:50 and 16:42 UTC. For those eight days, an app on 16.4.0 carried a critical flaw and nothing lit up. What to do now: check your version, then move to 16.4.1 or 15.5.28.

Are you affected?

Three advisories, two severity levels, and version ranges that don't line up neatly. Here is what GitHub publishes.

Where that leaves you:

• On the 16 line, at 16.4.0 or below: all three apply. The use cache RCE needs a use cache function that returns multiple typed arrays, but the advisory is clear that no workaround exists and you should upgrade even if your code has nothing like that.
• On the 13 to 15 lines, at 15.5.27 or below: the Image Optimization RCE and the denial of service apply. The use cache flaw does not exist before 16.
• On the 10 to 12 lines: only the Image Optimization RCE applies, and it starts at 10.0.0. The denial of service starts at 13.0.0.
• Pages Router, no Server Actions: the denial of service does not apply, the advisory says so outright. The two RCEs still do.

Two commands to find out where you stand, from your project root:

npm ls next
node -p "require('next/package.json').version"

npm ls next also lists nested copies. If a dependency ships its own version of Next, it shows up in the tree — and that copy is often the one still sitting on 16.4.0 while your package.json says something else.

Fix it in 5 minutes

One command per step, in order.

1. Start by looking at the state of your repo: a version jump on Next sometimes breaks a build detail, and you want a way back.

git status

2. Install the fixed version for your line.

npm install next@16.4.1

If you're on 15:

npm install next@15.5.28

3. Check what is actually installed, not what package.json promises.

npm ls next

Expected: a single version, either 16.4.1 or 15.5.28. If an old copy survives in the tree, run npm dedupe and run the command again.

4. You can also ask the OSV database directly what it knows about your version:

curl -s -X POST https://api.osv.dev/v1/query -d '{"package":{"name":"next","ecosystem":"npm"},"version":"16.4.0"}'

Three entries for 16.4.0, an empty response for 16.4.1. It's the same mechanism that feeds Dependabot, and it's what explains the eight days I get to further down.

5. If you're stuck on an older line, you still have half a net for the Image Optimization RCE. That flaw comes from how sharp handles SVGs, and the advisory offers a workaround: sharp 0.35.5 or later is not affected.

npm ls sharp
npm install sharp@^0.35.5

That workaround covers this one advisory. It does nothing for the use cache RCE or the denial of service.

6. Rebuild and redeploy. An updated node_modules without a build changes nothing in production.

npm run build

After deploying, confirm the version being served: a startup log, a health endpoint, or an env value you print. A local build proves nothing about what's running.

One detail that matters: no fixed release exists on the 10 through 14 lines. The only versions that close these flaws are 15.5.28 and 16.4.1. On 14.x there is no saving npm install next@14.x.y — only a migration, or the sharp workaround in the meantime.

The prompt for your coding agent

Fix the three Next.js vulnerabilities published on 14 October 2026 (GHSA-2464-fhr4-w9xw, GHSA-673q-mjm6-r5xr, GHSA-p3m5-59mp-jv5r) in this project.

1. Read the "next" dependency version in package.json, then:
   - 16.x -> npm install next@16.4.1
   - 15.x -> npm install next@15.5.28
   - 14.x or older -> no fixed release exists on that line. Install next@15.5.28 (or 16.4.1) and fix build errors one at a time without changing business logic. Until then, apply the workaround in step 3.

2. Verify before moving on:
   - "npm ls next" must return a single version, >= 15.5.28 or >= 16.4.1;
   - no copy of next at 16.4.0 or below may remain in the dependency tree.

3. If the project is stuck on a version below 15.5.28, make sure "npm ls sharp" returns >= 0.35.5. That workaround only covers the Image Optimization flaw (GHSA-2464-fhr4-w9xw), nothing else.

4. Run "npm run build", then list the files you changed and any behavior change you noticed. Don't touch application code beyond what the build requires.

The 8 days your scanners stayed silent

The timeline, in UTC, reads straight out of primary sources: the fix commits, the Next.js release notes, and the three advisories.

• 8 October, 18:00 — Next.js announces an out-of-band release for 14 October: three flaws in upstream dependencies, two critical, one high. Two of the fixes had been postponed from the September release because of upstream coordination.
• 14 October, 15:27 — the fix commits land. One bumps sharp on both LTS lines, the other touches the Server Component transport protocol.
• 14 October, 17:47 — releases 15.5.28 (17:47:49) and 16.4.1 (17:47:59) go out. Their release notes already list the three GHSA identifiers.
• 14 October, 18:00 — the Next.js security post details impact, versions and install commands.
• 22 October, 15:50:34 — first advisory (denial of service) in GitHub's reviewed database.
• 22 October, 15:52:53 — second advisory (Image Optimization RCE).
• 22 October, 16:42:31 — third advisory (use cache RCE). The whole publication window lasts 52 minutes.

Between the fix commit (14 October, 15:27) and the first published advisory (22 October, 15:50), eight days and 22 minutes went by. Between the fixed release going out (14 October, 17:47) and that same advisory: seven days and 22 hours. Either way, the technical information existed — it just wasn't where the tooling looks.

This is not a paperwork detail, it's the mechanism that decides whether you get an alert. GitHub's documentation is explicit: Dependabot notifies you when a GitHub-reviewed advisory reports a vulnerability in a package you depend on, and unreviewed advisories trigger no alert at all. As long as those three entries weren't in the database, Dependabot had nothing to tell you. The OSV API didn't return them either: their publication date there is 22 October. Tools that read OSV — osv-scanner, Trivy, Grype and others — sat in the same blind spot.

The practical result: for eight days, an app on next 16.4.0 carried a remote code execution rated 9.5 out of 10, and its security dashboard stayed quiet.

Why the gap? Publishing an advisory and adding it to the reviewed database are two separate steps. GitHub reviews each advisory before including it: full description, ecosystem, version ranges. On an out-of-band release from a framework as widely deployed as Next.js, that review lands after publication, and the gap is measured in days.

What that means for your process: one source is not enough. The GitHub database is excellent for coverage and slow on emergency releases. Framework release notes publish the same day, fixed versions included. If your monitoring only watches reviewed advisories, you have an eight-day blind spot on every out-of-band release. Here, you didn't need to wait for the alert: the patch had been out since 14 October.

If you want to see how this kind of vulnerable dependency is handled on the tooling side, the features page lists the checks and what they return. And if you went through the Next.js middleware flaw from March 2025, CVE-2025-29927 follows the same pattern: the fix ships before the ecosystem has the right identifiers in place.

Frequently asked questions

Am I affected if I'm on Next.js 15?

Two of the three, yes. The Image Optimization RCE hits 15.5.27 and below, the denial of service hits 13.0.0 through 15.5.27. The use cache RCE only covers 16.0.0 to 16.4.0. Version 15.5.28 fixes the two that apply to you.

Does a vulnerability need a CVE ID?

No. GHSA-673q-mjm6-r5xr carries no CVE at all and is still a critical remote code execution rated 9.5. A tool that only looks for CVE identifiers will never see it. It's also why this article doesn't slap one CVE across the three advisories: neither RCE carries a CVE identifier in the GitHub advisory, and only the denial of service has one (CVE-2026-94482).

Is CVE-2026-96889 a Next.js flaw?

Not exactly. The Next.js security post pairs that CVE with advisory GHSA-2464-fhr4-w9xw, but the CVE itself describes a flaw in librsvg: a use-after-free when an SVG document contains nested XML inclusions with duplicate entity declarations. Red Hat published it on 23 September 2026 with a CVSS 3.1 score of 7.8. Next.js inherits the problem through its image pipeline, which goes through sharp. Don't look for that CVE on the use cache advisory: it isn't there.

Is updating sharp enough?

For the Image Optimization RCE alone, yes, provided the version actually resolved is 0.35.5 or later. It covers neither the use cache RCE nor the denial of service. For those two, the advisory says no workaround exists: upgrading Next.js is the only fix.

Why did no scanner alert me for eight days?

Because a published advisory and a reviewed advisory are not the same entry. Until GitHub has reviewed it, it isn't in the database Dependabot and OSV-reading tools rely on. The three timestamps on 22 October, between 15:50 and 16:42 UTC, mark the end of that blind spot, not the start of the vulnerability.

Sources

• Next.js Security Update for Upstream Vulnerabilities — 14 October 2026
• Upcoming Next.js Security Update for Upstream Vulnerabilities — 8 October 2026
• Release v16.4.1 — vercel/next.js
• Release v15.5.28 — vercel/next.js
• GitHub Security Advisory — GHSA-2464-fhr4-w9xw
• GitHub Security Advisory — GHSA-673q-mjm6-r5xr
• GitHub Security Advisory — GHSA-p3m5-59mp-jv5r
• CVE-2026-96889 — librsvg, use-after-free via nested XIncludes
• CVE-2026-94482 — Next.js, denial of service in the App Router
• OSV — GHSA-2464-fhr4-w9xw, github_reviewed_at field
• GitHub Docs — About the GitHub Advisory Database

An app with clean dependencies can still leak elsewhere. The quick scan looks at your site the way a stranger would and hands you the proof, request included.