Critical libheif Vulnerability Could Enable Remote Code Execution Through WordPress Image Uploads

A critical heap-buffer-overflow vulnerability in libheif could allow authenticated WordPress users to achieve remote code execution by uploading a specially crafted HEIC image through the standard Media Library workflow.

The issue, tracked as GHSA-x8r2-mggj-j6wr, affects the library’s uncompressed-image (unci) decoder and has been fixed in libheif 1.23.3.

In affected WordPress deployments, uploaded HEIC files can be passed from WordPress through PHP’s Imagick extension and ImageMagick to libheif, where vulnerable image parsing occurs inside the PHP-FPM worker process.

The flaw exists in libheif’s mixed-interleave YCbCr decoding path. A malicious image can declare the Cb chroma component as 16-bit while declaring Cr as 8-bit.

Although libheif allocates the Cr image plane for one byte per sample, vulnerable code uses the Cb component’s two-byte width while writing both chroma channels.

This creates a file-controlled out-of-bounds write beyond the Cr allocation, enabling heap corruption.

Researchers at Fortbridge demonstrated that the memory corruption can be chained into authenticated remote code execution on two highly specific WordPress environments: Ubuntu 26.04 with WordPress 7.1.1, PHP-FPM 8.5.4, ImageMagick 7.1.2.18 and libheif 1.21.2; and Debian 13 with WordPress 7.0, PHP-FPM 8.4.24, ImageMagick 7.1.1.43 and libheif 1.19.8.

The proof of concept executed commands as the www-data PHP-FPM account after a WordPress Author uploaded malicious HEIC content.

The attack requires an authenticated WordPress account with the upload_files capability, typically an Author-level role or higher.

However, deployments that allow guest uploads or expose the same image-processing route through plugins could potentially broaden the risk, depending on their configuration.

The exploit chain does not rely on a single malicious upload. It first uses specially constructed HEIC images to leak address information from WordPress-generated image derivatives.

Those derived images can expose memory contents through pixels after WordPress processes and recompresses the upload as JPEG.

Fortbridge said the disclosure component builds on a separate libheif flaw, GHSA-2jg2-4ch7-h545, involving out-of-bounds reads and writes in derived-image and pixel-plane handling.

That issue affects versions through 1.23.1 and was fixed in libheif 1.23.2.

By reconstructing leaked values from returned pixels, the exploit identifies loaded module addresses, including libc, libheif and ImageMagick components.

It then selects a profile matching the precise operating system, library versions, allocator behavior and object layout of the target server before generating an ASLR-adjusted unci payload.

This requirement makes the published chain highly environment-specific rather than universally reliable.

Still, the research establishes that controlled heap corruption in an image decoder can be transformed into execution within real WordPress/PHP-FPM workflows, rather than merely causing a denial-of-service condition.

In lab testing, Fortbridge reported successful command execution in six of eight fresh Ubuntu PHP-FPM parent-process runs and 22 of 24 Debian runs.

Fortbridge finding demonstrates, how a seemingly routine web feature image upload and thumbnail generation can expose applications to a deeper native-code attack surface.

libheif Vulnerability

The researchers used PHP-FPM worker scheduling techniques to reserve a worker for memory disclosure, heap calibration and the final trigger.

The result is important because image-processing stacks often include native libraries that sit outside the usual web-application threat model.

Traditional WordPress hardening strong passwords, plugin patching and role management does not independently protect a vulnerable ImageMagick access or libheif dependency that processes attacker-controlled media.

libheif maintainers classified the mixed-interleave issue as critical and urged all users to upgrade.

Version 1.23.3 is API- and ABI-compatible with version 1.23.2, making it a direct replacement for affected deployments.

Administrators should upgrade libheif to version 1.23.3 or later, or install the latest vendor-provided security package that incorporates the upstream fix.

Debian issued a security update for stable systems addressing multiple libheif vulnerabilities, including GHSA-x8r2-mggj-j6wr, in version 1.23.4-1~deb13u1.

Organizations should also restart PHP-FPM after patching because long-running worker processes may retain the vulnerable library in memory.

Where HEIC and AVIF uploads are not required, administrators should disable or reject those formats before native decoding occurs.

Image processing should be isolated in a least-privileged service with restricted network access, no application secrets and tightly controlled writable directories.

Defenders should investigate repeated PHP-FPM worker exits, HTTP 503 errors during image uploads, and suspicious HEIC files containing unci, iden, crop, overlay or grid image relationships.

While a crash does not prove exploitation, repeated failures during image processing should be treated as a potential security event.

Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.