Critical libheif Flaw Lets HEIC Images Run Code on Servers
On September 1, 2026, the libheif project released version 1.23.3 to close a critical heap buffer overflow in the widely used image library. The flaw was discovered and reported four days earlier by the Wordfence Threat Intelligence team using Wordfence Argus, and libheif maintainer Dirk Farin rated it 9.8 out of 10 on the CVSS scale. In plain terms, a specially crafted HEIC image can write attacker-controlled bytes past the end of a memory buffer, and on a vulnerable server that can lead to reading protected files from the image-processing worker or running code with its permissions. The affected versions are 1.18.0 through 1.23.2 when the library is built with its uncompressed codec enabled, and the fix is in 1.23.3; 1.23.4 is the current upstream security release. This is not a WordPress-only vulnerability.
To understand why this matters for a WordPress site, it helps to know what libheif actually does. iPhone owners have been creating HEIC files since iOS 11 made it the default photo format in 2017, because HEIC stores a better-looking picture in roughly half the space of a JPEG. HEIC is a container format, essentially a box with a packing list describing what is inside and how it was encoded. Almost nobody writes their own code to open it; most Linux systems rely on libheif. WordPress itself does not decode images. When a user uploads a photo, WordPress hands the file to an image editor so it can build thumbnails and extract metadata. On affected servers, the PHP Imagick extension calls ImageMagick, which recognizes HEIF and passes the file down to libheif. That means a C++ library is inside the PHP image-processing worker, parsing bytes that arrived from the Internet with that worker's permissions. The same library also sits under desktop image viewers, photo galleries, self-hosted media servers and thumbnail generators, so any software that opens HEIC files from other people is potentially exposed.
Should a site owner be worried? A CVSS score of 9.8 is close to the maximum and says that when an application exposes this library to untrusted images over the network without requiring a login, the worst-case result is a full server compromise. It does not mean every WordPress site lets strangers upload HEIC files. Wordfence's demonstration against a clean WordPress installation used an ordinary Author account, which is the first role allowed to upload media in a standard WordPress site. Modern systems also make memory-corruption bugs harder to exploit: ASLR shuffles where code and data end up in memory, and RELRO makes some internal tables read-only. Still, Wordfence proved the bug can go further. On one specific WordPress setup running Debian and glibc, a crafted HEIC file let the researchers read a protected file and execute code. A narrower test that copied an uploaded image into another location worked in 29 of 30 attempts against an Apache server that was already running and reusing worker processes. That is strong evidence of real impact but not a universal exploit; the payload depends on the exact libheif build, how the server manages memory, and requests reaching a worker with the right state. An attacker may need a different file for a different environment. If hundreds or thousands of sites use the same hosting image, however, the work done for one may carry over to the others. High-value targets and hosting fleets built from a shared image deserve particular attention.
The finding should not be dismissed just because an exploit must be tailored. HEIF Heist, research by Hacktron that turned several other libheif vulnerabilities into working attacks against real image-processing services, shows how quickly adaptation can happen. Discourse confirmed code execution through an affected image upload, and Vercel confirmed unauthenticated code execution when affected Next.js applications processed a crafted AVIF image. The Wordfence Argus finding is a newer, separate bug with a different root cause and was fixed later; libheif 1.23.2 addressed two critical vulnerabilities featured in HEIF Heist, but this one remained until 1.23.3. Hacktron says adapting its exploits to a new target generally took about one or two days. In other words, "needs to be tailored" is a speed bump rather than a safety control, and patching should be the priority for any application that accepts HEIC or HEIF files from people you do not trust.
For WordPress sites specifically, the usual image-processing path is exposed only if all of these are true at once: the server has the PHP Imagick extension, because WordPress's other image editor cannot read HEIC at all; the ImageMagick installation was packaged with HEIF support; the libheif version is between 1.18.0 and 1.23.2; and that libheif was compiled with its uncompressed codec enabled. That last condition means the version number alone cannot tell you whether you are vulnerable. Wordfence tested nine real configurations on September 5 by asking each one to decode a valid uncompressed HEIF file. The vulnerable set included the official WordPress Docker image (libheif 1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2), and Fedora 44 (1.21.2). The non-vulnerable set included Ubuntu 24.04 LTS (1.17.6), Debian 12 bookworm (1.15.1), Alpine 3.22 (1.19.8), Alpine 3.23 (1.23.0), and AlmaLinux 10 (1.17.6). Debian 13 and Alpine 3.22 both ship libheif 1.19.8, yet one is vulnerable and the other is not, because one enables the uncompressed codec at build time and the other does not. The official WordPress Docker image was exposed out of the box: built on Debian 13, it shipped the Imagick extension, reported HEIC support, and its libheif decoded the vulnerable format, with every condition satisfied and no action by the operator. To check your own site, open Tools, Site Health, Info, Media Handling, which lists the file formats ImageMagick supports. If HEIC is not listed, this particular WordPress Imagick path is not exposed, though other software on the server may still use libheif. If you cannot patch yet, stop accepting these files by removing all four HEIF types WordPress accepts (heic, heif, heics, heifs) from your allowed upload types. Disabling PHP execution in your uploads directory is also a good idea in general. If you use the official image, pull an updated base, rebuild your image without relying on a cached layer, and redeploy it.
How does the bug actually work? A color photo is stored as three separate pictures: one holds brightness, and the other two hold color, one for how blue each part of the picture is and one for how red. Human eyes notice detail in brightness far more than detail in color, so the two color pictures can be stored at lower resolution and nobody sees the difference. In the file's own vocabulary, each of these is called a plane. Each plane declares how much space its dots need, called bit depth.