A working exploit chain demonstrates how a specially crafted HEIC image uploaded through the WordPress Media Library can lead to remote code execution (RCE) on specific server configurations. The vulnerability originates in libheif, a native C++ library used by ImageMagick when the PHP Imagick extension processes HEIC images. WordPress core itself is not affected. Wordfence discovered and reported the underlying heap buffer overflow, which the libheif project addressed in version 1.23.3 on September 1, 2026, with a critical severity rating. On October 5, 2026, Fortbridge published a working end-to-end exploit demonstrating code execution against specific Ubuntu and Debian configurations.
This article examines how the vulnerability progresses from an out-of-bounds memory operation in the image decoder to command execution under the web server's account. It breaks down the vulnerable decoder logic, explains how the exploit extracts memory addresses from images served back by WordPress, and identifies the configuration requirements that determine whether a server is exposed. It also covers where the fix must be applied and which server-side controls can help reduce the attack surface.
1. A Chroma Width Mismatch in the unci Decoder
The vulnerability, tracked as GHSA-x8r2-mggj-j6wr, affects libheif's decoder for ISO/IEC 23001-17 uncompressed images, known as unci. The issue occurs in the mixed-interleave YCbCr decoding path, where an image can specify a 16-bit Cb component and an 8-bit Cr component.
The decoder allocates the Cr plane using one byte per sample but processes both chroma components through a shared loop that advances their destination pointers according to the two-byte Cb sample width. As a result, Cr writes extend beyond the allocated buffer, causing a heap buffer overflow. The libheif 1.23.3 release notes confirm that the input file controls both the bytes written and the extent of the overflow.
According to Fortbridge's analysis, certain heap layouts place the overflowing Cr plane close to either a vector of plane pointers or a decoder object. If the overflow reaches the decoder object, it can overwrite its first machine word, replacing the virtual table (vtable) pointer. During decoder teardown, a subsequent virtual function call may then follow the overwritten pointer, potentially redirecting execution to an attacker-controlled address.
2. Leaking Addresses Through Returned Image Pixels
Hijacking a virtual function call is not sufficient on its own. The exploit also needs valid library and heap addresses to redirect execution successfully. Address Space Layout Randomization (ASLR) changes memory locations between PHP-FPM parent processes, making these addresses difficult to predict.
Fortbridge's exploit uses a second libheif vulnerability, fixed in version 1.23.2, to obtain the required addresses. In this flaw, an identity-derived image can report dimensions larger than its backing pixel plane. A subsequent crop operation then copies neighbouring heap memory into the resulting image, exposing data beyond the intended image buffer.
WordPress introduces another challenge because it stores generated image derivatives as lossy JPEG files. To preserve the leaked information through this conversion, the exploit constructs a disclosure image that encodes each leaked byte as an 8 × 8 pixel block. It then processes the returned JPEG to reconstruct the original byte values and recover 64-bit memory pointers.
The exploit does not proceed simply because it can read memory. It must recover pointers matching a known native library build and establish the corresponding libc base address. Fortbridge reports successful execution only when a separate request returns the output of the id command running under the www-data account.
3. Upload Permissions and Server Builds Determine Exposure
The tested exploit chain requires a WordPress account with the upload_files capability, which WordPress grants by default to users with the Author role and above. The server must also have the PHP Imagick extension installed and use an ImageMagick build with HEIF support.
The vulnerable unci decoding path is present only when libheif is compiled with WITH_UNCOMPRESSED_CODEC=ON. According to the upstream security advisory, affected versions range from libheif 1.18.0 through 1.23.2.
Fortbridge validated the exploit against two specific server configurations: libheif 1.21.2 on Ubuntu and libheif 1.19.8 on Debian. The reported success rates were 6 out of 8 and 22 out of 24 fresh PHP-FPM parent processes, respectively.
These results are based on controlled laboratory testing, not evidence of successful exploitation across all WordPress installations. Exploitability depends on the exact library build, heap layout and worker process configuration. Therefore, accepting HEIC uploads alone does not establish that a WordPress site is vulnerable to this RCE. However, a compromised Author account on a server with a matching vulnerable configuration could provide an attacker with a path from image upload to command execution.
4. Patching libheif and Reducing the Image Decoding Attack Surface
Updating WordPress alone does not address this vulnerability because the flaw resides in the underlying libheif library. Remediation requires installing a patched package supplied by the operating system distribution or hosting provider. However, some distributions backport security fixes into older package versions, so the upstream version number alone cannot establish whether a system is vulnerable. Administrators should verify the installed package's security status and identify which libheif library the image-processing stack actually loads.
Where HEIC and AVIF uploads are not required, restricting these formats can prevent untrusted files from reaching the affected decoding code. Additional safeguards include processing untrusted images through an isolated, least-privileged service, preventing script execution in upload directories, and monitoring PHP-FPM child-process crashes and HTTP 503 responses following image uploads.
The underlying risk is not limited to accepting an image file. It depends on whether that file reaches vulnerable native code during server-side processing. Web application penetration testing can trace uploaded files through image-processing components and identify whether vulnerable libraries are reachable. Manual testing can then confirm whether a weakness is actually exploitable within the specific server environment.
Image uploads can expose publishing systems to vulnerabilities in the native libraries used to process them. Understanding which libraries handle uploaded files, keeping those dependencies patched, and isolating image-processing operations can help reduce the risk of exploitation.
To assess your organization's exposure to related security risks, Scan your organization's exposure, explore Laburity's security services, or book a consultation.
