Malicious HEIC Images Can Trigger Remote Code Execution on WordPress Servers

A malicious HEIC image can become a route to remote code execution on a WordPress server. Researchers have demonstrated an attack chain that turns a normal Media Library upload into code execution in the PHP-FPM process that runs the site.

The risk comes from libheif, a widely used component that reads HEIC, HEIF and AVIF files. When WordPress sends an uploaded image to ImageMagick for resizing, a specially crafted file can reach the vulnerable decoder and corrupt memory instead of producing an image.

Fortbridge researchers identified a repeatable path that combines the image parsing flaw with leaked memory data from WordPress-generated JPEG derivatives.

Their testing shows why image uploads deserve the same scrutiny as other server-side input, particularly where a site accepts modern phone-photo formats. This highlights a gap between upload controls and native libraries.

The demonstrated scenario requires a logged-in WordPress user with the upload_files permission, normally an Author or higher. Fortbridge did not test unauthenticated guest uploads or document an active malware campaign.

The findings demonstrate laboratory exploitation, not a confirmed outbreak affecting WordPress sites worldwide. Fortbridge said in a report shared with Cyber Security News (CSN) that the chain was validated on two precise Linux software stacks.

Malicious HEIC Images Can Trigger Remote Code Execution

The primary bug, tracked as GHSA-x8r2-mggj-j6wr, affects libheif’s uncompressed image decoder. A malicious file can declare two color channels with different byte widths.

The decoder then reserves too little space for one channel but writes data using the larger width, allowing attacker-controlled bytes to flow beyond the intended memory area.

That overflow can alter nearby program data. In the tested chain, it changes a C++ object reference and later redirects a virtual function call during decoder cleanup.

Put simply, the image is built to make the image-processing service follow an attacker-selected instruction path rather than its normal cleanup routine. Reliable exploitation is difficult because modern servers randomize memory locations after a process starts.

The researchers first upload separate disclosure images, then study pixels in resized JPEG files returned by WordPress. Those pixels reveal enough memory information to identify the running library build and tailor a final trigger to it.

Fortbridge built the chain, while Alex Thomas and Wordfence discovered the overflow. This is not a generic exploit for every WordPress installation.

The validated profiles were Ubuntu 26.04 with WordPress 7.1.1, PHP-FPM 8.5.4, ImageMagick 7.1.2.18 and libheif 1.21.2, plus Debian 13 with WordPress 7.0, PHP-FPM 8.4.24, ImageMagick 7.1.1.43 and libheif 1.19.8.

Package changes can break the chain, but the work reinforces concerns raised in earlier HEIF decoder research about risky image-processing pipelines.

Mitigation

Fortbridge reported successful code execution in six of eight fresh Ubuntu PHP-FPM parent processes and 22 of 24 Debian parent processes under its controlled profiles.

The code would run as the PHP-FPM account, which was www-data in the laboratory, demonstrating execution with the web service’s permissions. A worker crash alone was not counted as proof of successful exploitation.

Administrators should update libheif immediately. GHSA-x8r2-mggj-j6wr affects versions 1.18.0 through 1.23.2 and is fixed in 1.23.3.

A related disclosure issue, GHSA-2jg2-4ch7-h545, is fixed in 1.23.2. Teams should install distribution security updates and verify the library actually loaded by the image stack.

Sites that do not need HEIC or AVIF uploads should block them before native decoding. Operators can also remove the uncompressed codec from custom libheif builds, process untrusted media in isolated low-privilege services, restrict outbound network access, and keep application secrets outside image workers.

These safeguards align with lessons from a WordPress Imagick upload flaw and a recent ImageMagick RCE proof, where server-side conversion created the dangerous boundary.

Defenders should investigate repeated PHP-FPM worker exits and HTTP 503 responses that follow HEIC uploads, especially files containing unci, iden, crop, overlay, or grid relationships.

Restricting writable web paths and disabling script execution in upload directories will not remove the memory bug, but it can reduce the damage after a successful compromise. The report did not identify an active exploitation campaign.

Indicators of compromise (IoCs):-

Type	Indicator	Description
File name	rce-proof.txt	Debian proof path used by the Fortbridge validation chain to confirm code execution.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

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