CVE-2026-32740: RCE in Next.js via AVIF image processing

CVE-2026-32740: RCE in Next.js via AVIF image processing

Adrian Tiron, a researcher at Fortbridge, demonstrated how a memory corruption vulnerability in libheif can lead to remote code execution in a deliberately vulnerable Next.js application using sharp. The research is notable for demonstrating a complete exploitation chain with ASLR, NX, and PIE enabled.

What Is the Vulnerability? CVE-2026-32740 is a heap-buffer overflow in HeifPixelImage::copy_image_to(), a function in libheif responsible for assembling decoded HEIF/AVIF image tiles into a grid. For the subsampled Cb and Cr color channels, the function independently rounds the destination row and the number of rows to copy. With specially crafted AVIF tiles, these calculations can cause a row to be written beyond the allocated chroma buffer. The researchers constructed an AVIF image with four vertically stacked tiles, each 33 pixels high, on a 116 × 132-pixel canvas. The final tile caused one extra chroma row to be copied beyond the buffer boundary, providing a controlled 58-byte out-of-bounds write.

How Was the Overflow Turned Into RCE? Memory corruption alone would normally cause a crash. The researcher developed a multi-stage exploitation chain: • Bypassing ASLR through an information leak. A separate crafted AVIF caused sharp to return a PNG containing pointers from uninitialized native memory in its alpha-channel data. By matching four leaked pointers against a known native-stack profile, the exploit recovered the randomized base address of libvips. • Turning the overflow into a constrained arbitrary-address write. The 58-byte overflow corrupted the lower two bytes of a right-child pointer in a std::map red-black-tree node used by libheif to store image-plane metadata. This redirected the lookup for the Cr channel to a forged map node containing a controlled ImagePlane descriptor. The descriptor specified the destination address for subsequent pixel copies, creating a constrained write-what-where primitive. • Hijacking execution through the GOT. The exploit used the controlled pixel write to overwrite memcpy@GOT with the address of libvips' internal g_module_open_full routine. The next call through the same GOT entry transferred execution to that routine, which wraps dlopen and can load a native shared library. • Executing a command. The attacker had previously uploaded an ELF shared library disguised as an image named uploads/x.jpg. When the GModule loader opened this file, the library's constructor executed /usr/bin/id and returned its output to the attacker's listener. The exploit did not require a ROP chain or knowledge of the randomized Node.js executable address. The required code address was calculated from the leaked libvips base.

Experiment Results The PoC was tested against a deliberately vulnerable application using: • Next.js: 15.5.23 • sharp: 0.34.4 • libvips: 8.17.2 • libheif: 1.20.2 The two Linux x86-64 test environments used different PIE-enabled Node.js builds: version 25.8.1 on Ubuntu and version 20.19.2 on Debian 13. All 20 exploitation attempts succeeded: ten against fresh Ubuntu processes and ten against fresh Debian processes. In every run, ASLR randomized the libvips base address, and the exploit recovered the corresponding address through the PNG information leak.

Limitations The demonstrated chain requires a vulnerable AVIF-processing route, access to the converted image output, and an upload mechanism that preserves an attacker-controlled ELF shared library at a predictable path accessible to the native loader. The exploit also depends on exact native-library builds, allocator behavior, and memory layouts. Different versions or configurations may require a new, independently verified exploit profile. These results demonstrate RCE under the documented application conditions, not universal exploitation of every Next.js or sharp deployment.

Mitigation Fortbridge recommends upgrading libheif to version 1.22.0 or later and ensuring that the patched library is actually included in the native dependencies loaded by sharp and libvips. Updating only the top-level JavaScript package may leave a vulnerable bundled library in place. Additional defenses include validating uploaded files by their actual content, generating server-side filenames, keeping uploads outside the application working directory, and processing images in isolated, least-privileged workers.

Article: https://fortbridge.co.uk/research/cve-2026-32740-nextjs-sharp-libheif-rce/

PoC: https://github.com/FORTBRIDGE-UK/libheif-grid-nextjs-rce