Two critical, unauthenticated remote code execution vulnerabilities landed in Next.js's August 2026 security release. One hits Windows-hosted servers with no available workaround, the other hits AVIF image optimization, and only self-hosted deployments are exposed.
On August 25, 2026, Vercel shipped Next.js 16.3.3 and 15.5.24, and moved the release forward by a day after finding an additional critical severity vulnerability in one of the framework's upstream dependencies. Both fixed issues are unauthenticated remote code execution, the most serious class a web framework can carry, meaning an attacker needs no valid session, no credentials, and no prior foothold to run arbitrary code on an affected server. One flaw scores a CVSS of 9.0, the other 9.5. Neither had a confirmed public exploit as of two days after disclosure, but that window closes fast once a patch diff is public, because reversing a fix into a working exploit is now a routine exercise for a motivated attacker.
This is the second release under Vercel's formal monthly security program, announced in July 2026 explicitly in response to what the company called a rising volume of vulnerability research driven by LLM-assisted discovery. The first scheduled release, on July 21, patched nine issues spanning denial of service, server-side request forgery, and a middleware bypass class. Next.js and its React Server Components layer have carried a run of severe disclosures over the past two years, including a March 2025 middleware bypass that let unauthenticated attackers skip authorization checks entirely, and a December 2025 React Server Components deserialization flaw with a maximum CVSS of 10.0 that was actively exploited within hours of disclosure. Framework-level RCE in Next.js is no longer a rare event worth a one-off scramble. It is a recurring operational reality that self-hosted teams need a standing process for, not an improvised one.
Next.js optimizes images server-side through its built-in Image component, which relies on the sharp package, which in turn relies on the libheif C library to decode AVIF files. The vulnerability here, tracked as GHSA-2xp9-vwfh-vxw4 on the Next.js side and GHSA-g89c-p67h-r497 in libheif itself, carries a CVSS v4 score of 9.5. It is a heap buffer overflow triggered by a specially crafted AVIF file containing nested identity-derivation and auxiliary item references. That structure tricks libheif into building a decoded image with two separate alpha plane entries at different bit depths. The scaler allocates a destination buffer sized for the first, 8-bit entry, then writes 16-bit sample values from the second entry into that same undersized buffer, overwriting roughly 16,384 bytes past the allocation boundary. The researchers who disclosed the underlying libheif bug published a Python proof of concept that reproduces the corruption under an address sanitizer build, and stated they achieved remote code execution against multiple applications, a claim that has not been independently corroborated but should be treated as credible given the mechanism.
Exposure here is conditional rather than universal. A Next.js application is only vulnerable if its next.config.js explicitly adds image/avif to the images.formats configuration, since AVIF optimization is opt-in, not a default. If your configuration has never mentioned AVIF, this specific flaw does not touch you. The patched releases take the blunt but correct approach of disabling AVIF optimization entirely, across every application regardless of configuration, until libheif ships a fix upstream. As of two days after the Next.js patch, libheif's maintainers had not yet published that fix. The affected version range is wide: Next.js 10.0.0 through 15.5.23, and every 16.x release through 16.3.2, which covers essentially the entire lifetime of the image optimization feature as it exists today.
The second vulnerability, CVE-2026-75604, carries a CVSS of 9.0 and affects applications that use both the Pages Router and the App Router together without Cache Components, when the Next.js server process runs on a Windows filesystem. Linux and macOS deployments are entirely unaffected by this specific issue, which narrows the exposed population considerably but does not make it small. Windows-hosted Node.js applications are common in enterprises standardized on Windows Server for compliance or internal tooling reasons, and in consultancy engagements we still regularly find internal admin panels and partner-facing tools built on Next.js and deployed behind IIS or a Windows-based container host precisely because that is what the rest of the organization's infrastructure already runs on.
Vercel's own advisory states plainly that there is no known workaround for affected Windows-hosted applications, and that teams running one should upgrade immediately. The affected range spans Next.js 13.4 through 15.5.23 and 16.0 through 16.3.2. Vercel did not disclose the specific attack mechanism in its advisory, which is standard practice for a fresh critical disclosure, giving the patch time to propagate before a working exploit chain becomes public knowledge. The researchers credited with responsible disclosure, evolutionstorm and B0RI, reported it through Vercel's open source bug bounty program rather than publishing details independently.
Applications hosted on Vercel's own managed platform required no action and were confirmed protected from both vulnerabilities before the public disclosure even went out. That is not marketing framing, it is a direct structural consequence of how the platform serves image optimization and executes the Next.js runtime, and it is worth naming plainly because it is the actual trade-off at the center of this story. A managed platform absorbs framework-level zero-days as an operating cost baked into the service. Self-hosting keeps every part of that response, detection, patch application, deployment, and verification, squarely on your own team's on-call rotation, on your own timeline, with your own judgment about what counts as urgent.
None of that is an argument that self-hosting Next.js is the wrong call. Plenty of good reasons exist to run your own infrastructure: cost at scale, data residency requirements, integration with existing internal platforms, or contractual obligations that a managed vendor cannot satisfy. What it does mean is that self-hosting carries a specific, recurring maintenance obligation that has to be actively staffed and monitored, not assumed away as someone else's problem, because for a self-hosted Next.js deployment, nobody else's problem is exactly what it becomes the moment a critical advisory drops.
Vercel's move to a disclosed, cadenced monthly security release is itself a signal worth reading correctly. It is not evidence that Next.js has become less secure, it is evidence that the volume of vulnerability research aimed at popular frameworks has grown faster than ad hoc disclosure could keep up with, and that teams running these frameworks in production should now expect a steady, predictable cadence of critical patches rather than treating each one as a surprising, isolated event. That expectation should shape how engineering organizations plan patch response, and it is also a fast, high-signal check when evaluating someone else's infrastructure. When we assess a software acquisition target that self-hosts a framework like Next.js as part of our technical due diligence work, one of the first things we check is not whether the target's stack is current today, it is how quickly their team has historically applied the last two or three critical framework patches once they were public. That single data point tells you more about operational discipline than almost anything else in a codebase.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.