Summary
- Next.js 16.4.1 and 15.5.28 address two critical code-execution flaws and a high-severity availability flaw.
- The first execution flaw requires Next.js 16 Cache Components with a specific typed-array return; the second involves untrusted SVG processing on affected Linux configurations.
- The separate Server Actions vulnerability can exhaust CPU resources in affected App Router deployments; Pages Router applications are not exposed to that issue.
Next.js has released out-of-band security updates for two critical remote-code-execution vulnerabilities and a separate high-severity denial-of-service flaw. The issues affect different upstream components and are reachable only under particular application or hosting conditions.
The 14 October releases, versions 16.4.1 and 15.5.28, carry fixes for the affected supported branches. GHSA-673q-mjm6-r5xr concerns an unusual Next.js 16 App Router Cache Components scenario in which a use cache function returns multiple typed arrays. GHSA-2464-fhr4-w9xw, also tracked as CVE-2026-96889, concerns server-side SVG image processing through the sharp and librsvg stack on glibc-based Linux systems. Neither condition describes every Next.js application.
The Cache Components execution flaw applies to the affected 16.x releases when the specified function-return condition exists; it should not be extended indiscriminately to the 15.x maintenance branch. The SVG issue has a different affected-version range and depends on how untrusted SVG content reaches the image-processing code. Applications using a different image service, an unaffected runtime, or no relevant features may have a different exposure profile even when built with the same framework.
Next.js is a framework for server-rendered and client-side web applications, widely used in public-facing services and internal tools. Its dependency tree includes components that execute on the server, where data handling flaws can carry more serious consequences than browser-only bugs. That makes it important to distinguish the framework’s application logic from upstream image and rendering libraries.
A third advisory, GHSA-p3m5-59mp-jv5r, describes excessive CPU consumption triggered by crafted requests to App Router applications that define at least one Server Action. It affects specified 13.x–16.x releases and can prevent a server process from handling legitimate requests. Pages Router applications, and App Router applications without Server Actions, are not vulnerable to this particular issue. The advisory does not describe data theft or remote code execution through the denial-of-service path.
Hosting provider Netlify has separately assessed which of the reported code paths can be reached on its managed platform, including differences in its image-handling infrastructure. Its deployment-specific mitigations do not establish the same protection for self-hosted instances, other cloud providers, or preview environments. Affected maintainers still need to follow the applicable framework and dependency updates.
The release illustrates an ongoing challenge for application owners: a security issue can emerge within an upstream dependency even when business application code has not changed. The actual deployed bundle, its configuration, and the hosting platform determine whether a known vulnerability is reachable from external traffic.
Updating the package version locally is also different from remediating a production system. Organisations may maintain several branches, preview deployments, regional installations, and cached build artefacts. A patched dependency must be included in the production artefact that is actually serving requests. Vulnerable older preview sites can persist long after the main branch has been updated.
Where untrusted SVGs are processed on the server, the image-handling advisory requires attention to the actual runtime and native libraries, rather than to the presence of an upload form alone. Separately, a Cache Components application only meets the reported critical condition when it returns the relevant typed-array structures. That combination of feature and runtime prerequisites is why a security scanner reporting an installed version does not, by itself, establish exploitability.
The two critical execution paths do not share a common prerequisite. One involves a narrow use cache behaviour in Next.js 16, while the other can arise in SVG processing through upstream graphics libraries on a particular Linux platform. The high-severity Server Actions issue concerns availability instead. The advisories identify fixed Next.js releases, but administrators of applications that manage React Server Components dependencies independently may also need the upstream React security versions. Updating a development dependency without rebuilding and deploying the actual application leaves production exposure unresolved.
The Next.js team had announced plans for an out-of-band release before 14 October. Its publication establishes that patches are available for the three disclosed conditions; the advisories do not establish widespread exploitation of these new issues. Production version checks and the presence of the affected features remain necessary to determine whether a particular service was exposed.
