One CVE, two severities: the Next.js image flaw is critical downstream and moderate upstream

Two advisories, one identifier

On 22 September 2026 Vercel published an out-of-band security release for Next.js, titled "Next.js Security Update for a Critical Upstream Issue" and authored by Josh Story, Karim Rahal and Sebastian Silbermann ^[1]. It shipped 16.3.6 on the Active LTS line and 15.5.26 on Maintenance LTS, and stated that versions from 16.2.0 up to but excluding 16.3.6 are affected, that the issue lies in the Node.js ImageResponse implementation in next/og, that improper escaping in SVG output generated by Satori could lead to remote code execution due to vulnerabilities in other upstream dependencies, and that applications using the Edge ImageResponse implementation are not affected ^[1].

The bulletin points at two advisories: GHSA-vcvr-r3jv-pc5j for Next.js and GHSA-wx4j-mvgx-mqwp for Satori ^[1]. Both are Vercel projects. Both describe the same defect. They carry the same CVE identifier, CVE-2026-94545. They do not carry the same severity.

The Satori advisory rates the issue moderate, CVSS 5.3, affecting npm satori from 0.0.27 through 0.33.4 and fixed in 0.33.5. Its impact statement is explicitly conditional: the consequences depend on how the application consumes the generated SVG, ranging from information disclosure to integrity compromise in downstream systems. It states that no complete workaround exists besides upgrading, and credits the researchers RaghavMaheshwari124 and rafabd1 ^[2]. The Next.js side of the same defect is reported at CVSS 9.5, critical, across every write-up that quotes a score ^{[3][4][5][6][7][8][9][10][11]}. That is a 4.2-point gap between two advisories from one vendor for one CVE.

Neither rating is wrong. Satori is a rendering library; whether improperly escaped SVG becomes code execution depends on what consumes the output. Next.js consumes it in a way that, combined with other upstream dependencies, reaches execution ^[1]. Severity is a property of the deployment, not of the defect. The problem is that a CVE identifier is a single key, and most triage pipelines resolve it to a single number.

Where the number you see comes from

A team whose software composition analysis walks the npm dependency graph sees satori pinned at a moderate 5.3 and queues it with the month’s other moderates. A team tracking framework advisories sees a critical 9.5 and pages someone. Same estate, same package, two different Fridays. One write-up notes a further wrinkle: npm audit may not flag this at all, and manual version verification is required ^[11]. Another observes that the discrepancy between the 9.5 and the 5.3 arises from differing impact assessments rather than from any disagreement about the defect ^[11].

This is not an argument for ignoring CVSS. It is an argument for recording, in the vulnerability register, which advisory a score came from. An entry that reads "CVE-2026-94545, 5.3, moderate" is defensible and also, for a Next.js estate on the Node runtime, wrong in effect.

Version is not exposure

The second problem is that the version string does not answer the question. Exposure requires three conditions together: a Next.js version in the affected range, an ImageResponse route running on the Node.js runtime rather than Edge, and attacker-controlled data reaching SVG content, an attribute or a style ^{[1][4][5][10]}. An application on 16.3.2 that only generates static images from trusted strings is not exposed. An application on 16.3.2 whose Open Graph route builds a card from a query parameter is.

That cannot be answered from a software bill of materials. It requires locating every import of ImageResponse from next/og, establishing which of those routes run on Node, and tracing whether request data reaches the rendered image ^[5][10]. Several analyses make the same point about filtering: input validation alone is not a durable control here, because the escaping failure occurs during serialisation rather than at the application boundary ^[4][6][7].

The remediation path has its own friction. There is no backport to the 16.2 line, so a site on 16.2.x must move minor versions to take the fix ^[5][10]. Next.js 15.x is not affected by the remote code execution issue; 15.5.26 is hardening only ^[1][10]. And because build artefacts embed the resolved dependency, patching the lockfile without rebuilding and redeploying leaves production on the old code ^[6][10].

The attack surface was a presentation requirement

ImageResponse exists to generate Open Graph cards: the preview image a link shows when it is pasted into a chat or a social feed. These routes are unauthenticated by design, because the consumers are crawlers that do not hold credentials. One analysis states the position plainly — Open Graph image routes are public by design, which is why attack complexity is low ^[9]. Many of them take a title, a slug or a profile name straight from the URL, because that is the entire point of a dynamic card.

So the exposed component is a marketing feature. It is rarely in an application threat model, rarely reviewed, frequently added late by whoever was making the site look right in a link preview, and reachable without authentication from anywhere. The affected code has been shipping since Next.js 16.2 was released on 18 March 2026, giving roughly six months of deployment before the fix ^[3][11].

The exposure is horizontal rather than sectoral. One external attack surface analysis found affected properties spread almost evenly across industries — industrials 19.7 per cent, consumer discretionary 14.8 per cent, information technology 11.2 per cent, with the remainder distributed across communications, financials, energy and healthcare — and attributes the flatness to Next.js being a general-purpose framework rather than vertical software ^[5]. There is no sector to warn. Anyone running a modern marketing site is in scope.

As of 23 September no confirmed exploitation and no public proof-of-concept had been reported, though technical details were publicly available by then ^[3][4]. One write-up states that proof-of-concept code was circulating on GitHub ^[10]. That difference is worth watching rather than resolving; either way, the absence of confirmed exploitation on day two is not a scheduling argument.

What to do

• Pin 16.3.6 or later on the 16 line and 15.5.26 on the 15 line, then rebuild and redeploy. A lockfile change that is not rebuilt does not reach production ^[1][6][10].
• Inventory imports of ImageResponse from next/og, and for each route record the runtime and whether request data reaches SVG content, attributes or styles. That inventory, not the version number, is the answer to "are we affected" ^[5][10].
• Where an affected route must take untrusted input, move it to the Edge implementation or remove the untrusted value; treat input filtering as a stopgap, not a fix ^[1][4][10].
• Check for Satori outside Next.js. The affected range runs from 0.0.27 to 0.33.4, so any service rendering untrusted content through the library is in scope and will not appear in a Next.js advisory ^[2].
• Monitor image routes for malformed or unusually long parameters, and watch Node processes behind them for shell spawning, unexpected file creation and outbound connections ^[4][5].
• Record both advisories as one register entry with both scores and the reason they differ, so the next person to read the ticket does not inherit the moderate ^[2][11].

For agencies and small operators across Malaysia and the region the practical obstacle is ownership. Framework-level fixes land on estates where a site was built once, handed over and never rebuilt, and where nobody currently holds the build pipeline. A patch that requires a lockfile bump, a minor version move and a redeploy is not a patch those estates can apply on a two-day clock. Establishing who can rebuild each site is the prerequisite, and it is worth doing before the next critical upstream issue rather than during it.