The latest Next.js security release deserves particular attention because it addresses two separate critical vulnerabilities that can lead to unauthenticated remote code execution, but through completely different attack paths. One affects applications hosted on Windows systems and is tracked as CVE-2026-75604, while the second originates deeper in the software supply chain through the `libheif` image-processing library used indirectly by Next.js when optimizing AVIF images. Both vulnerabilities are fixed in Next.js 15.5.24 and 16.3.3. The most important point for defenders is that neither vulnerability requires an attacker to possess a legitimate application account, and successful exploitation could potentially allow code execution within the context of the affected Next.js server. At the time of disclosure on August 27, 2026, there were no confirmed reports of exploitation in the wild, but the AVIF vulnerability already had sufficient technical information and proof-of-concept material available to make delayed remediation an unnecessarily adventurous decision.

CVE-2026-75604 carries a critical severity rating with a CVSS score of 9.0 and affects Next.js applications hosted on servers using a Windows filesystem. The vulnerability affects applications using both the Pages Router and App Router without Cache Components. Affected releases include Next.js versions from 13.4 through 15.5.23 and versions 16.0 through 16.3.2. Linux and macOS deployments are not affected by this particular vulnerability, which is an important qualification because the headline description of “Next.js remote code execution” could otherwise create the impression that every Next.js server is equally exposed.

The underlying issue in CVE-2026-75604 involves path traversal behavior on Windows-hosted systems. Path traversal vulnerabilities occur when attacker-controlled input influences filesystem paths without sufficient normalization or boundary enforcement. Windows path handling presents additional complexities because drive letters, backslashes, alternative path representations and filesystem normalization rules can behave differently from Unix-style environments. When application logic assumes one interpretation of a path while the underlying operating system interprets it differently, an attacker may be able to escape the directory boundary the developer expected to enforce.

What makes CVE-2026-75604 especially serious is that the consequence is not restricted to reading an unintended file. Under affected configurations, the vulnerability can ultimately result in unauthenticated remote code execution. Once an internet-facing application vulnerability crosses from filesystem manipulation into code execution, the security impact changes considerably. An attacker may potentially gain the ability to execute commands under the identity of the Next.js application process and then begin exploring the environment for credentials, application secrets, database access, cloud tokens or opportunities for additional privilege escalation.

Vercel has stated that there is no known workaround for affected Windows-hosted applications and has advised customers to upgrade immediately. This distinction is important. Security teams occasionally respond to critical vulnerabilities by placing additional validation in a reverse proxy, adding a WAF signature or attempting to block a particular request pattern. Those controls may still provide additional protection, but where the vendor explicitly states that no reliable workaround exists, they should not become substitutes for installing the corrected framework version.

The second vulnerability is arguably even more interesting because the vulnerable code does not originate directly inside the core Next.js implementation. Next.js uses the `sharp` image-processing package for its Image Optimization functionality, and `sharp` in turn depends upon the `libheif` library for handling formats such as AVIF. A critical heap-buffer-overflow vulnerability in `libheif` can therefore propagate upward through this dependency chain until it becomes remotely exploitable through a Next.js application.

This is a textbook example of software supply-chain risk at the dependency level. An application developer may never call `libheif` directly, may not even know that the library exists inside the deployed dependency tree, and may have written no unsafe memory-management code whatsoever. Yet the application can still become vulnerable because a high-level framework depends on another package that depends on a native library containing a memory-corruption flaw. Modern application security therefore cannot stop at reviewing the code written by the application team. The security boundary increasingly includes thousands of lines of code maintained by people the organization has never met.

The AVIF issue affects Next.js versions from 10.0.0 through 15.5.23 and Next.js 16.x releases through 16.3.2. However, not every application using these versions is automatically exploitable. Next.js does not enable AVIF optimization by default. The vulnerable path becomes relevant when the application explicitly configures `image/avif` as an image format in `next.config.js` and subsequently processes attacker-controlled AVIF content through the Image Optimization API. This configuration requirement is critical when assessing exposure because vulnerability management should distinguish between software that merely contains vulnerable code and deployments where attackers can actually reach the vulnerable functionality.

The underlying `libheif` flaw involves a heap buffer overflow during processing of specially constructed AVIF image structures. Researchers found that a malicious image could contain carefully arranged identity-derivation and auxiliary-item references that cause the decoder to construct multiple Alpha-plane entries using different bit depths. The image-scaling logic allocates memory based on one representation but subsequently processes data from another representation requiring larger storage. The resulting mismatch causes values to be written beyond the allocated heap buffer.

According to the technical analysis, approximately 16 KB of data can be written beyond the intended allocation under the demonstrated conditions. That is considerably more significant than a simple one- or two-byte memory corruption. Large controlled memory overwrites can provide attackers with additional opportunities to manipulate application state, pointers or adjacent heap structures in ways that can eventually influence execution flow.

The researchers responsible for the discovery demonstrated heap corruption and also reported successfully achieving remote code execution against multiple applications. The publicly released proof of concept demonstrates the underlying memory corruption, although the claim of full RCE across multiple applications had not been independently corroborated at the time of reporting. That distinction is worth preserving because cybersecurity analysis should separate demonstrated technical behavior from broader exploitation claims. The vulnerability is serious enough without embellishment.

What makes the AVIF vulnerability particularly concerning is that image-processing functionality is frequently exposed to untrusted content by design. Applications resize profile photographs, product images, uploaded media and externally referenced content automatically. Developers quite reasonably expect the image-processing library to decode an image rather than turn the JPEG-versus-AVIF discussion into a remote shell. When parsers written in memory-unsafe languages receive attacker-controlled binary formats, however, they become attractive exploitation targets because malformed files can manipulate complex internal data structures before the application has any opportunity to reason about their contents.

This is not unique to AVIF. Image decoders, video codecs, document parsers, compression libraries and font engines have historically produced some of the most interesting memory-corruption vulnerabilities because these components must interpret complicated attacker-controlled binary structures. Modern web frameworks often expose such functionality through convenient high-level APIs, which means an underlying parser flaw can suddenly become remotely reachable from an HTTP request.

The Next.js Image Optimization API demonstrates this architectural relationship clearly. From the application developer's perspective, the feature simply accepts an image and generates an appropriately optimized version. Internally, however, multiple software layers participate in the operation: Next.js invokes image-processing functionality, `sharp` performs transformations, and native libraries parse the underlying format. The security of the final HTTP endpoint therefore depends on every layer handling malicious input correctly.

Vercel's immediate remediation is noteworthy because the patched Next.js versions disable AVIF optimization entirely while the upstream `libheif` fix propagates through the dependency ecosystem. This is a practical example of reducing functionality temporarily to eliminate an attack surface. Rather than waiting for every dependency and packaging layer to incorporate the final upstream correction, the framework disables the vulnerable processing path.

There is a useful broader security lesson in that decision. Organizations sometimes resist disabling functionality because users may notice the reduction in capability. From a security perspective, however, temporarily serving another image format is vastly preferable to maintaining a potentially exploitable unauthenticated RCE path merely because somebody values a slightly more efficient picture of a product catalogue. Security engineering occasionally involves accepting minor inconvenience so that servers remain under the ownership of the organization operating them.

Applications that do not explicitly enable AVIF optimization are not affected by the AVIF attack path, but they may still be affected by CVE-2026-75604 if hosted on Windows and using the relevant Next.js router configuration. Conversely, a Linux-hosted application is not affected by the Windows path-traversal issue but may remain vulnerable to the AVIF problem if AVIF optimization is enabled. This is why administrators need to evaluate the vulnerabilities separately rather than treating them as a single Next.js security issue.

The simplest remediation is therefore to upgrade to Next.js 15.5.24 for deployments remaining on the Maintenance LTS branch or Next.js 16.3.3 for deployments using the Active LTS branch. Organizations that already installed the July 2026 Next.js security updates still need to install the August releases. Security patching is, regrettably, not a loyalty program where installing last month's update earns immunity from this month's vulnerabilities.

Organizations should also verify that deployment artifacts actually contain the patched version after upgrading. JavaScript environments can contain multiple lockfiles, cached build artifacts, containers and deployment pipelines capable of preserving older dependencies longer than expected. Updating `package.json` in a source repository does not guarantee that every production instance immediately begins running the corrected framework.

Containerized deployments should be rebuilt rather than simply restarting existing containers. Old images containing vulnerable Next.js versions may otherwise remain in container registries and can accidentally be redeployed later. Organizations should identify and retire outdated images, particularly where automated rollback mechanisms might restore them during an operational incident.

The dependency nature of the AVIF vulnerability provides another strong argument for maintaining a Software Bill of Materials. When a vulnerability is announced in `libheif`, many application owners may reasonably conclude that they do not use the library because they never installed it directly. An SBOM or reliable dependency-analysis platform can reveal that `libheif` entered the environment indirectly through `sharp`, which entered through Next.js. Without that visibility, organizations may remain vulnerable simply because nobody realizes that the affected code exists inside their application stack.

Transitive dependencies are one of the major challenges in modern software security. Developers typically understand their direct dependencies reasonably well, but each of those packages may introduce additional dependencies containing native components, parsers or networking libraries. A contemporary web application can therefore contain hundreds or thousands of packages whose security ultimately contributes to the application's overall risk.

This is also why vulnerability-management processes should map vulnerabilities to reachable functionality rather than simply producing package inventories. The presence of `libheif` establishes potential exposure, but whether an attacker can reach it through AVIF optimization determines exploitability in the Next.js scenario. Reachability analysis can therefore help security teams prioritize vulnerabilities much more effectively than treating every vulnerable dependency as equally dangerous.

The Windows vulnerability presents a different asset-management challenge because hosting platform becomes part of exposure analysis. Security teams need to know not just which applications run Next.js but whether those applications are deployed to Windows, Linux, managed Vercel infrastructure, serverless environments or other platforms. Runtime architecture is part of vulnerability context.

Vercel has stated that applications hosted on its own platform are protected against both vulnerabilities and do not require an emergency upgrade for protection from these specific attack paths, although keeping dependencies current remains sensible. Other hosting providers may provide their own protections depending on implementation. Netlify, for example, indicated that its Next.js sites are not affected by the Windows issue because functions run on Linux and that its image architecture does not invoke the vulnerable Next.js Image Optimization path.

This illustrates another important aspect of cloud security: the same framework version can have different practical exposure depending on where and how it is deployed. Managed platforms may intercept certain functionality, terminate requests at an edge layer or replace framework-native components with platform implementations. Vulnerability assessment therefore needs deployment context rather than relying exclusively on package-version scanning.

Cloudflare also released emergency WAF protections targeting both Next.js vulnerabilities. WAF rules can provide valuable additional protection against known exploitation patterns, particularly while organizations complete upgrades. However, WAF mitigation should again be treated as defense in depth rather than a permanent substitute for removing vulnerable code. Memory-corruption vulnerabilities and complex path-manipulation flaws may admit alternative payloads that evolve as researchers and attackers understand the issue more deeply.

This is especially relevant because the AVIF proof-of-concept information is already available. Once technical details and working malformed files become public, security researchers, exploit developers and attackers can all begin experimenting with variants. Initial signatures may reliably detect the published proof of concept while missing modifications that reach the same vulnerable code path through slightly different binary structures.

Organizations exposing Next.js Image Optimization to user-controlled content should therefore monitor unusual requests to `/_next/image`, especially requests referencing AVIF content or unexpected remote resources. High volumes of malformed-image requests, repeated image-processing crashes or unexplained application restarts should be investigated. A memory-corruption exploit that does not immediately achieve RCE may still trigger process crashes during development or failed exploitation attempts.

Application crash telemetry can become an important security signal in situations like this. Operations teams may normally classify an isolated image-processing crash as a reliability problem and simply restart the service. If a critical parser vulnerability has just been disclosed, repeated crashes triggered by external image requests should instead be treated as potential exploitation attempts.

Endpoint and runtime telemetry can provide another detection layer. If a Next.js process unexpectedly spawns command shells, scripting interpreters or unfamiliar binaries after handling web requests, that behavior should receive immediate investigation. Web application servers generally have predictable process trees. A Node.js application suddenly creating PowerShell, `cmd.exe`, shell processes or downloading executables is rarely expressing a healthy interest in systems administration.

Outbound communication should similarly be monitored. Successful remote code execution is generally only the beginning of an attack. The attacker may attempt to retrieve secondary payloads, connect to command-and-control infrastructure or exfiltrate credentials and application data. Restricting application-server egress to genuinely required destinations can substantially reduce what an attacker can accomplish after code execution.

This matters particularly in cloud environments because Next.js applications often have access to environment variables containing database credentials, API secrets, signing keys and cloud tokens. Remote code execution within the application process may allow an attacker to retrieve those values immediately. The compromise can therefore spread beyond the web server even if the process itself operates without operating-system administrator privileges.

Secrets management becomes a crucial secondary control. Applications should receive only the credentials genuinely required for their function, and those credentials should be scoped as narrowly as possible. Database accounts should not automatically have administrative rights, cloud identities should use least privilege, and long-lived static keys should be avoided where workload identity mechanisms are available.

Organizations should also ensure that sensitive environment variables are not unnecessarily copied into build artifacts. Modern JavaScript deployment processes can blur boundaries between development, build and runtime environments. A compromised runtime should not automatically expose deployment credentials, source-control tokens or unrelated infrastructure secrets.

The Windows RCE vulnerability reinforces the value of running internet-facing applications under dedicated low-privilege service identities. If an attacker achieves execution through Next.js, the privileges of that process immediately influence the blast radius. An application running as a local or domain administrator converts framework RCE directly into highly privileged system compromise. An application running as a restricted service identity forces the attacker to find an additional privilege-escalation path.

Filesystem permissions should follow the same principle. Web applications generally require read access to their application files and limited write access to specific temporary or cache directories. Granting broad write access across the application directory increases opportunities for persistence after compromise. Attackers who can modify application code may survive service restarts or implant backdoors that continue operating even after the original vulnerability is patched.

Network segmentation can further restrict post-exploitation movement. A public Next.js application should not automatically have unrestricted connectivity to internal databases, domain controllers, management systems and administrative interfaces. Application traffic should be limited to documented backend dependencies through explicit policy. This converts server compromise from unrestricted internal network access into a considerably more constrained problem.

The vulnerabilities also show why web application security cannot be reduced entirely to secure coding practices within the application team. An organization could implement excellent authentication, authorization, input validation and output encoding while still becoming vulnerable through a memory-management defect inside a native image library several dependency levels below the application. Security therefore needs multiple layers: secure development, dependency management, sandboxing, process isolation, network controls and runtime detection.

The AVIF vulnerability is particularly illustrative because modern development increasingly depends on native components hidden beneath memory-safe or managed-language applications. Developers may write JavaScript or TypeScript and reasonably assume that memory corruption is not part of their immediate threat model. But packages such as image processors frequently call native C or C++ libraries for performance, quietly reintroducing traditional memory-safety risks beneath the abstraction.

This is one reason dependency security should include native components rather than examining only npm packages. The package-manager layer may report `sharp`, but the security-relevant vulnerability may exist within a bundled or dynamically linked library several layers below it. Software composition tools need to understand those relationships if they are to provide meaningful exposure analysis.

The timing of the security release is also notable. Vercel had originally planned the August Next.js security release for August 26 as part of its recently established monthly security-update process. The company moved the release forward to August 25 after identifying the additional critical vulnerability in an upstream dependency. The resulting release therefore addressed both the Windows RCE and the AVIF issue simultaneously.

The formal monthly security-release process itself reflects a broader change in software security. Frameworks such as Next.js have become foundational infrastructure for enormous numbers of internet-facing applications. Coordinated and predictable security updates give organizations an opportunity to plan testing and deployment processes instead of treating every patch as an unexpected emergency. At the same time, truly critical discoveries still need to override the calendar, as this release demonstrates.

Organizations using major frameworks should therefore design development pipelines capable of absorbing security updates quickly. If upgrading a framework requires several weeks of manual testing and organizational approval, the deployment process itself becomes part of the security risk. Automated regression testing, reproducible builds, staged deployment and rapid rollback can allow organizations to patch much faster without sacrificing operational stability.

The release also follows a substantial July 2026 Next.js security update that addressed nine vulnerabilities involving denial of service, server-side request forgery, middleware bypass and other issues. Organizations that updated in July cannot therefore assume their deployments remain current. Framework security increasingly resembles operating-system security: regular patching is becoming part of routine operation rather than an exceptional maintenance activity.

Next.js has also experienced several high-profile security disclosures over the previous two years, including the middleware authorization bypass discovered in March 2025 and the React Server Components vulnerability commonly referred to as React2Shell in December 2025. Those events helped demonstrate how vulnerabilities in widely used framework primitives can quickly affect enormous numbers of applications.

This does not necessarily mean that Next.js is uniquely insecure. Popular software receives substantially more security research because discovering vulnerabilities in a widely deployed framework provides greater impact and recognition. Increased use of automated and AI-assisted vulnerability research is also accelerating the discovery of subtle flaws across major software projects. More vulnerabilities being discovered can therefore indicate increased scrutiny as much as deteriorating engineering quality.

Vercel itself has acknowledged that vulnerability research volume is increasing rapidly, partly driven by LLM-assisted discovery. This trend has important implications for defenders. AI can help researchers analyze large codebases, trace data flows and identify unusual interactions between components faster than traditional manual review. Unfortunately, attackers gain access to many of the same capabilities. The time between vulnerability disclosure and practical exploitation is therefore likely to continue shrinking.

This makes exploitability-aware patching increasingly important. Organizations should not wait automatically for evidence of exploitation in the wild when a critical unauthenticated RCE has public technical details and reachable attack surfaces. By the time threat intelligence confirms widespread exploitation, the useful preventive window may already have closed.

At the same time, security teams should avoid unnecessary panic. The current Next.js vulnerabilities have specific prerequisites. CVE-2026-75604 affects Windows-hosted servers under particular router and cache conditions. The AVIF vulnerability requires the vulnerable image-optimization path and AVIF configuration. Linux systems without AVIF optimization do not suddenly become vulnerable to both issues simply because Next.js appears in `package.json`.

Good vulnerability management therefore requires answering several concrete questions: Which Next.js versions are deployed? Which hosts run Windows? Which applications enable AVIF optimization? Is `/_next/image` reachable with attacker-controlled content? Are applications hosted on managed platforms that replace or protect the affected functionality? Which servers contain valuable credentials or internal network access if exploitation succeeds?

Those questions produce a far more useful risk assessment than simply marking every Next.js application “critical.”

The response should nevertheless remain straightforward: upgrade supported deployments to Next.js 15.5.24 or 16.3.3 as soon as practical, rebuild and redeploy application artifacts, verify that production instances actually run the patched versions, and review potentially exposed systems for suspicious activity. Windows-hosted affected applications should be considered particularly urgent because Vercel has stated that there is no reliable workaround.

Organizations using AVIF optimization should additionally review whether accepting attacker-controlled images is necessary and whether image-processing workloads can be isolated. In high-risk environments, running complex parsers inside separate sandboxed services or containers with limited privileges and network access can reduce the consequences of future parser vulnerabilities.

This architectural approach is valuable beyond Next.js. Whenever applications process untrusted documents, images, archives or media, those parsers should ideally operate with minimal privileges. A vulnerability in a decoder should compromise a restricted processing environment rather than immediately inheriting the full privileges and secrets of the primary application server.

The broader lesson from these two Next.js vulnerabilities is that modern application security increasingly depends on understanding chains of trust. The Windows issue shows how differences in operating-system filesystem semantics can undermine framework security assumptions. The AVIF issue shows how a vulnerability several dependency layers below the framework can become remotely exploitable through a convenient web API. Neither problem fits neatly into the traditional idea that securing a web application simply means validating form fields and protecting login pages.

Modern frameworks are ecosystems. Their security depends on JavaScript code, native libraries, operating-system behavior, cloud deployment architecture, build pipelines and external dependencies all behaving safely together. A weakness anywhere in that chain can eventually surface as an HTTP-accessible attack path.

The most valuable takeaway is therefore not merely “patch Next.js.” That is the immediate action, but the architectural lesson is larger. Organizations need visibility into framework versions, transitive dependencies and deployment environments; they need rapid security-update pipelines; applications should run with minimal operating-system and cloud privileges; internet-facing servers should have restricted network access; and complex parsers handling attacker-controlled files should be isolated wherever practical.

These two vulnerabilities demonstrate why defense in depth remains necessary even for modern application stacks. A patched framework protects against today's known vulnerability. Least privilege limits tomorrow's unknown RCE. Network segmentation restricts lateral movement if execution is achieved. Egress controls make command-and-control harder. Secrets management reduces what attackers can steal. Runtime monitoring provides an opportunity to detect exploitation that preventive controls missed.

The Next.js August 2026 security release ultimately illustrates an uncomfortable reality of software development: a developer can write completely reasonable application code and still inherit a critical remote-code-execution vulnerability from the interaction between a framework, an image-processing package, a C library or the filesystem semantics of the operating system underneath it. The application stack is only as secure as the boundaries between all of those layers.

That is why modern application security needs to move beyond asking, “Does our code contain a vulnerability?” The better question is, “Which components can process attacker-controlled input, what privileges do they possess, what dependencies do they trust, and what happens if one of those assumptions fails?” In the case of these Next.js flaws, answering those questions quickly determines whether the announcement is simply another framework update or a genuinely exposed path to unauthenticated remote code execution.

Credit: Hacktron Vercel has released security patches for two critical-severity vulnerabilities in the Next.js web framework, both of which allow unauthenticated remote code execution, one exploitable via specially crafted AVIF image files and the other through a path traversal flaw affecting servers that use a Windows filesystem. The Windows path traversal, tracked as CVE-2026-75604&

Source: Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE via The Hacker News — published 27 Aug 2026.