Vercel Ships Next.js 16.4.1 Fixing Two Critical RCE Flaws

Vercel released Next.js 16.4.1 and 15.5.28 to fix two critical unauthenticated remote code execution flaws and a high-severity denial-of-service bug in apps.
Table of Contents
    Add a header to begin generating the table of contents

    Vercel released an out-of-band Next.js update on October 14 that fixes two critical unauthenticated remote code execution flaws and a high-severity denial-of-service bug. The patched versions are Next.js 16.4.1 and 15.5.28.

    Two Unauthenticated Code Execution Flaws in a Single Release

    Both critical flaws can be exploited without logging in, which Vercel says means any public application on an affected version that uses the vulnerable features could be at risk. Vercel reports no exploitation in the wild, and no public proof-of-concept has been confirmed. The company urged developers to upgrade immediately “even if your application does not have similar functions.”

    Versions before 16.4.1 and 15.5.28 are affected. The release is out-of-band, meaning it arrived outside Vercel’s normal schedule.

    GHSA-673q-mjm6-r5xr: Cache Components and Typed Arrays

    The first flaw, tracked as GHSA-673q-mjm6-r5xr, affects App Router applications that use Cache Components. Remote code execution becomes possible when a function marked with “use cache” returns multiple typed arrays. The root cause lies in React rather than in Next.js itself, and a related advisory exists upstream. Vercel says there is no workaround, so upgrading is the only fix.

    CVE-2026-96889: A Memory Bug in the sharp Image Library

    The second flaw, CVE-2026-96889, is a memory bug in the upstream sharp image library. It leads to remote code execution when Next.js runs on glibc-based Linux. Because the flaw sits in a dependency, applications can inherit it through the framework’s image handling without any code of their own that calls the library directly.

    The Third Fix: A Denial-of-Service Bug in Server Actions

    The release also addresses a high-severity denial-of-service flaw. Crafted requests can drive high CPU usage in App Router applications that use Server Actions, and they block further requests in the same process. Unlike the two code execution flaws, this one affects availability rather than integrity, but a single process that stops serving requests can take a whole application offline.

    Why Upstream React and sharp Dependencies Delayed Two Next.js Fixes

    Two of the fixes had been delayed from September while upstream dependencies caught up. The delay reflects how a framework that bundles or depends on React and sharp cannot ship a complete fix until those projects publish their own. Vercel’s patched release lands after that wait.

    The delay also means the interval between Vercel’s awareness of at least some of the issues and the public release was longer than usual for a framework fix. Vercel has not said whether it observed any attempts against the flaws during the gap, and it reports none in the wild.

    Why a Framework Flaw Reaches So Many Applications

    Next.js is a React-based framework, so a vulnerability in this layer reaches every application built on an affected version, regardless of what business logic those applications run. The two code execution flaws require no authentication, which removes the usual constraint that limits how many deployments an attacker can reach. Applications are exposed only if they use the specific features involved, such as Cache Components with “use cache” functions or the sharp-backed image path on glibc Linux, but those are common configurations.

    Vercel’s instruction to upgrade even without similar functions is a blanket recommendation, and the lack of a workaround for the first flaw leaves no narrower option for that issue. Vercel reports that no public proof-of-concept is confirmed, so no exploit code for either critical flaw is known at the time of the release. The company also reports no exploitation in the wild for any of the three bugs. Because the denial-of-service bug needs only crafted requests to App Router applications that use Server Actions, it too requires no login, and a single process that blocks further requests can leave an application unresponsive. The sources do not say how many applications use Cache Components or Server Actions, so the number of exposed deployments is not established.

    Related Posts