Wordfence Argus Discovers Critical Vulnerability in libheif, the Library That Opens iPhone Photos on Your Server

On September 1, 2026, the libheif project released version 1.23.3, closing a critical heap buffer overflow that the Wordfence Threat Intelligence team, using Wordfence Argus, discovered and reported four days earlier. The libheif maintainer, Dirk Farin, gave it a score of 9.8 out of 10 on the CVSS scale, with the release notes singling it out: “One of the fixed issues is rated critical, so all users are strongly advised to upgrade.” The bug lets a crafted HEIC image write attacker-chosen data past the end of a memory buffer. On a vulnerable server, that can lead to reading files the image-processing worker can access or running code with its permissions.

If you run a WordPress site, there isn’t a WordPress plugin to update for the usual image-processing path. libheif is a system library, so most site owners will get the fix through their operating system or hosting provider. Containerized sites need to be rebuilt and redeployed from an updated base image. Whether you’re exposed depends on both the libheif version and how it was built. We tested nine real configurations on September 5, and the official WordPress Docker image we tested was one of the vulnerable ones.

Wait, what’s libheif, and what does it have to do with WordPress?

If you own an iPhone, you’ve been generating HEIC files since 2017. Apple made it the default photo format in iOS 11 because it stores a better-looking picture in about half the space of a JPEG. Most people have never heard of it, and have uploaded thousands of these files without thinking much about it.

HEIC is a container. Think of it as a box with a packing list that says what’s inside and how it was encoded. Opening that box is surprisingly involved, so almost nobody writes their own code to do it. Instead, most settle on one library, libheif, which is a popular piece of software that actually reads HEIC images for much of the Linux ecosystem.

WordPress does not decode images itself. When someone uploads a photo, WordPress needs to read it to build thumbnails and pull out metadata, so it hands the file to an image editor. On affected servers, the PHP Imagick extension calls ImageMagick, which recognizes HEIF and passes the file down to libheif. That places a C++ library in the PHP image-processing worker, parsing bytes that arrived from the Internet with that worker’s permissions.

The result is that a photo format built for phone cameras gets parsed by a library most site owners have never installed on purpose and couldn’t name. The same library also sits under desktop image viewers, photo galleries, self-hosted media servers and thumbnail generators, so if any of those open HEIC files from other people, this applies there too.

This is a critical CVSS 9.8 vulnerability. Should I be worried?

If your server processes HEIC or HEIF files from people you do not fully trust, this deserves prompt action.

A CVSS score of 9.8 is close to the maximum. In plain English, it 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. Our demonstration against a clean WordPress installation used an ordinary Author account. Dirk Farin, libheif’s maintainer, assigned the score.

The score also doesn’t tell you how much work sits between crashing a server and taking it over, or whether one malicious file will work everywhere, so we tested that too.

Modern systems are designed to make memory-corruption bugs miserable to exploit. ASLR (Address Space Layout Randomization) shuffles where code and data end up in memory. RELRO (Relocation Read-Only) makes useful internal tables read-only. These defenses are one reason a heap overflow usually produces a crash instead of a compromised server, but this bug can go further.

We proved that on one specific WordPress setup running Debian and glibc, where the flaw let us read a protected file and execute code. A narrower test that copied the 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 it is not a universal exploit. Our payload still depended on the exact libheif build, how the server managed memory, and requests reaching a worker that had the right state.

That makes exploitation more work, not impossible. An attacker may need a different file for a different build or environment. If hundreds or thousands of sites use the same hosting image, however, the work done for one may carry over to the others.

On a standard WordPress site, Author is the first role allowed to upload media. We did not test a lower-privileged route. A plugin or custom application that lets visitors or subscribers upload HEIC files could change the picture considerably if it sends those files through the same vulnerable path.

For now, the most believable attack is aimed at a known target or a group of servers built alike. One unchanged image is unlikely to compromise every WordPress server on the Internet, but a capable attacker can fingerprint a target and adapt the exploit. High-value targets and hosting fleets built from a shared image deserve particular attention.

How this relates to HEIF Heist

At first, needing to tailor an exploit to each environment may sound reassuring. HEIF Heist is a good reason not to lean too heavily on that comfort.

Hacktron’s researchers took several other libheif vulnerabilities and turned them into working attacks against real image-processing services. 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 it was fixed later. libheif 1.23.2 addressed two critical vulnerabilities featured in HEIF Heist, but ours remained until libheif 1.23.3. The bugs work differently under the hood, but to a site owner the stakes are familiar: a file upload reaches a vulnerable image library, and memory corruption can become file disclosure or code execution.

Hacktron says adapting its exploits to a new target generally took about one or two days. That does not create one malicious image that works everywhere, but it does show that “needs to be tailored” is a speed bump rather than a safety control. If your application accepts HEIC or HEIF files from people you do not trust, patching should be the priority.

Is my WordPress site affected?

Install your operating system or hosting provider’s libheif security update as soon as it is available. If you install libheif directly, use at least 1.23.3. Version 1.23.4 is the current upstream security release and includes more security fixes. Restart PHP and the affected web services afterward so they stop using the old library. For containers, rebuild and redeploy from an updated base image rather than simply restarting the old container.

The usual WordPress image-processing path is exposed only if all of these are true at once:

1. Your server has the PHP Imagick extension, since WordPress’s other image editor cannot read HEIC at all
2. Your ImageMagick was packaged with HEIF support
3. Your libheif version falls between 1.18.0 and 1.23.2
4. That libheif was compiled with its uncompressed codec enabled

That last bit means you can’t rely on the version number alone to determine if you’re vulnerable. Package contents change, so this table records what we found on September 5. We tested nine real configurations by asking each one to decode a valid uncompressed HEIF file:

Look at Debian 13 and Alpine 3.22. Both ship libheif 1.19.8, the same upstream release. One is vulnerable, one is not, because one enables the uncompressed codec at build time and the other does not.

The official WordPress Docker image we tested was exposed out of the box. It was built on Debian 13, shipped the Imagick extension, reported HEIC support, and its libheif decoded the vulnerable format. Every condition was satisfied with no action by the operator. If you use the official image, pull an updated base, rebuild your image without relying on a cached layer, and redeploy it.

To check your own site, go to 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. Other software on the server may still use libheif.

If you can’t patch yet, stop accepting these files. Removing all four HEIF types WordPress accepts (heic, heif, heics, and heifs) from your allowed upload types means the file is rejected before it reaches the vulnerable library. Disabling PHP execution in your uploads directory is also a good idea (in general).

Is this likely to hit an average WordPress site? A single generic exploit is unlikely to work across every WordPress server. That is useful context, but it is not a reason to delay the update. HEIF Heist showed that tailoring an exploit to a target is practical. The risk is highest for sites that accept untrusted HEIC files, high-value targets, and hosting fleets that reuse the same image or build.

Managed hosting customers can’t check most of this themselves. It’s a reasonable thing to ask your host if the libheif version of your site host is within the vulnerable range and is built with the uncompressed codec enabled.

What this means for everyone else using libheif

Nothing about this vulnerability is specific to WordPress. WordPress is one delivery route among many, and the same question applies anywhere where libheif is used: does this software decode HEIC files that came from somebody else?

If you process files from untrusted sources, whether that is a photo-sharing service, document pipeline, chat application generating previews, or self-hosted media server, move this toward the top of your patch list. Check both the installed libheif version and whether it was built with the uncompressed codec enabled. Install your vendor’s fixed package, isolate or sandbox image processing where possible, and disable HEIF support if you do not need it.

Vulnerability Summary

libheif <= 1.23.2 – Heap Buffer Overflow to Arbitrary File Read and Remote Code Execution

9.8

CVSS Rating
9.8 (Critical)

CVE-ID
CVE-2026-XXXXX

Affected Version(s)
1.18.0 – 1.23.2

Patched Version
1.23.3

Affected Software

libheif [strukturag/libheif]

Researchers

Alex Thomas

Wordfence Argus

libheif is vulnerable to a heap buffer overflow in the decoder for uncompressed images in versions 1.18.0 through 1.23.2 when built with WITH_UNCOMPRESSED_CODEC=ON. A crafted HEIC file can write attacker-controlled bytes past the end of a memory buffer. In affected applications and server configurations, this can result in arbitrary file read or remote code execution. The vulnerability is fixed in libheif 1.23.3; 1.23.4 is the current upstream release.

More Details >

How we found it

We found this vulnerability with Wordfence Argus, our agentic adversarial testing framework, during a WordPress 7.1 security assessment.

The vulnerabilities that hurt WordPress sites don’t always live in WordPress itself. Some of them live several layers down, in shared libraries that site owners never chose on their own, reached by a feature as mundane as uploading a holiday photo. Defending the platform properly means following the data all the way down. You can read more about Argus in our earlier post.

Our mission is to secure WordPress through defense in depth, which is why we are investing in proactive vulnerability research of this kind alongside our Bug Bounty Program. We are committed to making the WordPress ecosystem more secure through the detection and prevention of vulnerabilities, which is a critical element to our multi-layered approach to security.

How the bug actually works

You don’t need to know C++ to follow this.

A color photo is stored as three separate pictures. One holds brightness. 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. This is called bit depth. Eight bits per dot is ordinary and takes one byte of memory. Sixteen bits gives finer gradations and takes two bytes. The format lets each plane declare its own depth, which is a reasonable feature, because the same format carries scientific and sensor images where the parts really do differ in precision.

A program reading an image asks the system for a block of memory big enough to hold it. That block is a buffer. If the program writes more data than the buffer can hold, the extra spills into memory beyond the buffer, which may contain other data or bookkeeping used by the program. That is dangerous because corrupting nearby memory can change how the program behaves. If an attacker can control what gets written, they may sometimes be able to steer the program into running code of their choosing. This is a buffer overflow.

In 1.23.2, libheif sizes each plane’s buffer from that plane’s own declared depth, which is correct. A file declaring sixteen-bit blue and eight-bit red gets a two-byte-per-dot buffer for blue and a one-byte-per-dot buffer for red.

The issue lies in the way the picture is written in. The two color planes are stored woven together in the file, one dot of each, alternating across the row, so a single loop fills both buffers at once. That loop looks up how wide a dot is only once, from whichever color plane the file lists first.

So with sixteen-bit blue listed first, the loop takes two bytes as the width and writes two-byte dots into both buffers. Blue’s buffer can take them. Red’s is sized for one-byte dots, so every dot written into it is twice the size it should be and lands twice as far along. Each row overruns into the row beneath it, and the last row runs past the end of the buffer into memory belonging to something else.

The bytes that spill out come from the image file, so whoever made the file chooses what gets written there. The amount that spills grows with the image’s declared dimensions. In the maintainer’s own words, “both the written bytes and the overflow length are controlled by the file.”

The mistake is visible in the record libheif keeps for each plane:

uint8_t* dst_plane;                      // this plane's memory
uint8_t* other_chroma_dst_plane;         // the paired plane's memory
size_t   dst_plane_stride;               // this plane's row length
size_t   other_chroma_dst_plane_stride;  // the paired plane's row length
uint32_t bytes_per_component_sample;     // one of these, for both planes

The record carries two pointers and two row lengths, but only one width. The code assumes both color planes use the same depth, and the file is allowed to declare that they don’t.

NOTE: Directly above this loop is a comment describing a different out-of-bounds write in the same function that was fixed a few months earlier. The same code had already been patched once for writing past the end of a color plane.

Timeline

Conclusion

Wordfence Argus found a critical heap buffer overflow in libheif 1.18.0 through 1.23.2, several layers beneath an ordinary WordPress image upload. We did not stop after making the vulnerable library crash. On one exact WordPress deployment, we demonstrated that a crafted HEIC file could be turned into reading protected files and executing code on the server.

This finding is separate from the vulnerabilities featured in HEIF Heist, but it reinforces the same real-world lesson. An exploit may need to be tailored to its target, yet that work can be done quickly and may carry across other servers built the same way. Our finding is also newer: it remained present in libheif 1.23.2, the release that fixed two critical HEIF Heist vulnerabilities, and was not fixed until 1.23.3.

This is exactly why we built Wordfence Argus. Securing WordPress means looking beyond WordPress Core and plugins, then following untrusted data through every layer that handles it. In this case, Argus followed a photo upload into a system library most site owners did not know they were running, found a critical vulnerability, and gave our researchers a path to prove what it could mean on a real server, WordPress or otherwise.

Whether you’re vulnerable depends on your libheif version and how it was built. Check Site Health for HEIC support, install your operating system or hosting provider’s fixed package, restart affected services, and rebuild container images from an updated base. If you can’t update yet, block HEIC and HEIF file types.

Our thanks go to Dirk Farin, who released the fix in four days.

If you know someone running a site that accepts image uploads, please share this advisory with them.

The post Wordfence Argus Discovers Critical Vulnerability in libheif, the Library That Opens iPhone Photos on Your Server appeared first on Wordfence.