A specially prepared HEIC image can do far more than fail to render on a WordPress site. Security researchers have demonstrated a chain that takes an ordinary Media Library upload, passes it through the site’s native image-processing stack, and ultimately executes code inside the PHP-FPM process. The work shows how a seemingly narrow bug in an image decoder can become a practical server compromise when it is combined with information disclosure and predictable application behavior.

The chain is not being described as a mass exploitation campaign, and it does not provide anonymous visitors with a universal route into every WordPress installation. In the tested scenario, the attacker first needs a logged-in account with the upload_files capability, normally an Author-level role or above. Even with that limitation, the result matters because compromised contributor accounts are common and image uploads are often treated as lower risk than executable files.

How the image reaches vulnerable native code

WordPress commonly relies on ImageMagick to create thumbnails and other derivatives after an image is uploaded. ImageMagick, in turn, can call libheif to decode HEIC, HEIF and AVIF content. The primary weakness, tracked as GHSA-x8r2-mggj-j6wr, sits in libheif’s uncompressed image decoder. A malicious file can describe color channels with inconsistent byte widths, causing the decoder to reserve too little memory before writing attacker-controlled data beyond the intended buffer.

That memory corruption can damage a nearby C++ object reference. During cleanup, the altered reference can redirect a virtual function call toward an attacker-chosen path. In plain terms, the decoder is manipulated into following hostile instructions while it believes it is finishing routine image processing. Successful code runs with the permissions of the PHP-FPM service account, identified as www-data in the researchers’ laboratory.

Memory disclosure makes the chain reliable

Modern Linux protections randomize where libraries are loaded, so a memory-corruption bug alone is not necessarily dependable. The researchers overcame that obstacle by uploading separate disclosure images and examining pixels in JPEG derivatives produced by WordPress. Those output images leaked enough process memory to identify the running library layout and prepare a final trigger for the specific stack.

Fortbridge validated the method on two tightly defined environments: an Ubuntu 26.04 system running WordPress 7.1.1 and a Debian 13 system running WordPress 7.0, each with particular PHP-FPM, ImageMagick and libheif builds. Code execution succeeded in six of eight fresh Ubuntu parent processes and 22 of 24 Debian parent processes. Those figures demonstrate repeatability under controlled conditions, but package or build differences can still disrupt the chain.

What WordPress administrators should do

The direct fix is to update libheif. Versions 1.18.0 through 1.23.2 are affected by the overflow, with the correction available in 1.23.3. A related disclosure weakness is fixed in 1.23.2. Administrators should install their distribution’s security packages and confirm which library the active ImageMagick installation actually loads; updating an unused copy does not protect the production image worker.

• Block HEIC, HEIF and AVIF uploads when the formats are not operationally required.
• Process untrusted media in an isolated, low-privilege service with restricted outbound access.
• Keep application credentials and other secrets outside the image-processing environment.
• Prevent script execution in upload directories and minimize writable web paths.
• Review who holds upload permissions and remove access that is no longer necessary.

Detection should focus on the processing layer

Defenders should investigate repeated PHP-FPM worker exits or HTTP 503 responses that occur immediately after HEIC uploads. Files containing unusual unci, iden, crop, overlay or grid relationships deserve added scrutiny. A worker crash is not proof of code execution, but a cluster of failures around image conversion can reveal attempted exploitation.

Restricting upload directories reduces consequences but does not repair the native memory flaw. The broader lesson is that an uploaded image remains untrusted code-like input once a complex decoder begins parsing it. WordPress security reviews therefore need to include the operating system libraries behind media conversion, not just plugins, themes and the core application.