Three critical vulnerabilities, 44 hours, and no scanner alert

A next release with a critical remote-code-execution fix is not exactly obscure. The advisories were public. The patches were public. One of them pointed directly to its underlying libheif root cause, where the vulnerable function and the malformed-file structure were documented.

And still, 44 hours later, most of the scanner feeds we checked were not reporting them.

An affected version is a reason to investigate. It is not, by itself, a verdict or an emergency patch ticket. The question is: can an attacker use this vulnerability against this service, in this deployment? A temporary WAF mitigation is not a closed finding.

Three critical advisories, one dependency chain

The AVIF issue is not a separate mystery inside Next.js. Next.js uses sharp for image optimization, and the vulnerable image-processing path reaches libheif. The libheif advisory describes the root cause: a crafted HEIC, HEIF, or AVIF file with nested iden and auxl item references can create duplicate Alpha planes, causing 16-bit data to be written into an 8-bit Alpha allocation.

The CVSS scores describe the maximum impact if the preconditions hold. They do not tell you whether those preconditions hold in your service. A public 9.8 in a dormant decoder is not the same thing as a public 9.8 on an internet-facing upload route.

The 44-hour scanner gap

We checked the public sources behind common dependency-security workflows at 2026-08-26 21:55 UTC.

The gap matters because time to exploit is collapsing. A day or two of missing alerts is now enough time for somebody else to read the disclosure, study the patch, and start looking for exposed targets.

CVE-2026-75604: Windows Next.js cache RCE

The Next.js advisory describes a path traversal in FileSystemCache.getFilePath that can lead to unauthenticated RCE when the server is hosted on a Windows filesystem. It affects applications using the Pages or App Router without Cache Components.

For the advisory's unauthenticated internet-attacker model, work through these checks in order.

GHSA-2xp9-vwfh-vxw4: AVIF through Image Optimization

The Next.js AVIF advisory has no operating-system precondition. The important question is whether an attacker can cause the built-in Image Optimization path to process a crafted AVIF.

For the advisory's unauthenticated internet-attacker model, work through these checks in order.

GHSA-g89c-p67h-r497: libheif is broader than Next.js

The libheif advisory affects applications using heif_decode_image() on versions through 1.23.1. Next.js image optimization is one route to this decoder; it is not the only one. Image upload services, media pipelines, desktop tools, and applications using libraries that bundle libheif can all deserve review.

Use the lowest-privilege party that can submit a media file as the attacker model.

Visual recap: the three exploitability checks

Here is a visual recap of the conditions that must hold for each deployment.

What Konvu did

We identified customer deployments that resolved affected Next.js or libheif versions, then ran the relevant table against each production service. The output says exactly where the table stopped: Vercel protection, a non-Windows runtime, a custom image loader, no attacker-controlled file, a temporary Cloudflare mitigation—or a complete exploit path.

That turns a public critical disclosure into an action our customer needs to take. For a complete exploit path, Konvu can submit a fix PR that checks for breaking changes, or give a coding agent a detailed remediation plan to pick up. When a condition is false, the finding is closed for that deployment with the evidence that keeps it closed. When Cloudflare is the only thing blocking the path, it stays open as a remediation action.

What to do now

1. Start at step 1 of the relevant table for every service with an affected runtime dependency.
2. Stop at the first failed condition and keep the evidence with the finding.
3. If Cloudflare's Managed Rule is the only blocker, treat the service as mitigated — still fix; do not close the finding.
4. Treat a fully matched, unmitigated path as urgent remediation; investigate unknown conditions instead of guessing.
5. Re-run the table if the service's hosting, configuration, or input path changes.

Running self-hosted Next.js, an image-upload service, or a libheif-backed media pipeline? Check whether these three vulnerabilities are exploitable in your environment.

For the broader controls needed to make this kind of decision routine, use our AI Application Security Checklist.

FAQ

Do I need to patch Next.js if my scanner shows no alert?

It tells you nothing about whether this deployment is exploitable. Apply the relevant condition table. If the exploit path is present, treat the service as urgent remediation. If a required condition is proved false, keep that evidence with the finding rather than creating emergency work for that deployment.

Are all affected Next.js applications exploitable?

No. The Windows issue requires a Windows filesystem and the affected router/cache conditions. The AVIF issue requires an attacker-controlled AVIF to reach the built-in Image Optimization path. Vercel-hosted applications are protected. Cloudflare's Managed Ruleset can temporarily reduce exposure to both paths when the origin cannot be bypassed, but it is not a reason to defer the update.

Why did Dependabot and npm audit not alert on these vulnerabilities?

At the timestamp documented in this post, the corresponding records were absent from the GitHub advisory data and the npm audit response we checked. These tools depend on advisory data arriving and being normalized; public vendor advisories can appear first.

Does a libheif dependency mean my application is remotely exploitable?

Not by itself. You need an affected runtime copy, a real HEIC, HEIF, or AVIF decode path, and an attacker-controlled file that reaches it. The absence of a public finding in a scanner does not answer those questions either.