Wordfence’s AI Testing Framework Found a Critical Flaw in the Library Behind Every iPhone Photo

An AI-assisted research tool built by Wordfence has found a critical, unauthenticated heap buffer overflow in libheif, the open source library that decodes HEIC photos, the format iPhones have used by default since iOS 11 in 2017. The bug carries a CVSS score of 9.8 out of 10, was fixed in libheif 1.23.3 on September 1, and reaches far beyond WordPress: any server, image viewer, media library, or document pipeline that decodes untrusted HEIC or HEIF files with an affected libheif build is exposed. There is no plugin to update. libheif is a system library, so the fix has to come from an operating system package, a hosting provider, or a rebuilt container image.

An AI tool that writes its own vulnerability reports

Wordfence found the bug on August 28 during an assessment of WordPress 7.1, using what the company calls Wordfence Argus, described in its own submission to libheif’s maintainer as “our agentic adversarial testing framework (AI).” The human researcher of record, Alex Thomas, reviewed and takes responsibility for the finding, but the disclosure itself says so plainly: “Due to the complex nature of this finding, the following report is AI-generated with some minor human edits.” libheif maintainer Dirk Farin committed a fix on August 31 and shipped it the next day in version 1.23.3, alongside a public GitHub Security Advisory, GHSA-x8r2-mggj-j6wr, that credits both Thomas and a second independent reporter, poppo25-Toss.

As of this writing, that advisory still lists “No known CVE.” Neither GitHub nor the National Vulnerability Database has assigned a CVE number to the flaw more than two weeks after it was patched, even though other libheif bugs fixed in the same 1.23.3 release already carry CVE numbers. Readers tracking this one will need to search by the GHSA identifier for now.

Two color planes, one write size

The flaw lives in libheif’s built-in decoder for the ISO/IEC 23001-17 uncompressed image format, known internally as unci. A HEIC file can declare its two chroma color planes, called Cb and Cr, at different bit depths in the same image. libheif’s decoder is supposed to allocate each destination plane according to that plane’s own declared depth. Instead, according to the GitHub advisory, the code that walks both planes together records only one entry’s byte width and column offset, then reuses that single value to write into both destinations. When a crafted file declares an 8-bit Cr plane paired with a 16-bit Cb plane, the Cr plane gets allocated for one byte per sample but written with two bytes per sample, over and over, for every pixel in the row. The bytes being written come directly from the attacker’s file.

Wordfence reproduced the crash with AddressSanitizer against the official 1.23.2 release, and confirmed a matched control file with equal-depth planes decodes normally, isolating the bug to the depth mismatch rather than a broader parsing failure. A different, older libheif build on a different Linux distribution, Fedora’s 1.21.2 package, also crashed with a native glibc memory corruption error when fed the same file. The advisory notes the bug requires libheif to be compiled with the WITH_UNCOMPRESSED_CODEC=ON option; it does not require any external codec library, ImageMagick, or WordPress itself to trigger, since the fault sits entirely inside libheif’s own decoder.

What Wordfence actually proved

A heap overflow does not automatically mean an attacker can run code. Modern defenses like ASLR and RELRO usually turn a bug like this into a crash rather than a takeover. Wordfence says it went further: against one specific configuration, a stock WordPress installation running on Debian with glibc, its proof of concept read a protected file (/etc/passwd) and executed arbitrary PHP code. Triggering that chain through WordPress itself required an ordinary Author-level account, since that is the WordPress role needed to upload media by default; the underlying libheif flaw itself needs no authentication or privilege at all, since any application that hands an untrusted HEIC file to an affected libheif build is exposed the same way. Wordfence is explicit that this result is deployment-specific rather than universal: a narrower test that copied the uploaded image to another server location succeeded in 29 of 30 attempts against an Apache server that was already running and reusing worker processes, and Thomas writes in the disclosure that full remote code execution elsewhere is “plausible but difficult” based on his testing, rather than guaranteed.

The chain that gets an ordinary photo upload to libheif runs through the PHP Imagick extension, which calls the ImageMagick library, which recognizes the HEIF container format and hands the file down to libheif to actually decode it. On September 5, Wordfence tested nine real-world configurations for exposure; the official WordPress Docker image was one of the vulnerable ones.

Why this is bigger than a WordPress patch

Nothing about the vulnerable code path is specific to WordPress. libheif is the library much of the Linux ecosystem settles on to read HEIC and HEIF files, the format Apple made the iPhone default because it stores a better-looking picture in roughly half the space of a JPEG. Anything that decodes HEIC images it did not create itself, image viewers, self-hosted photo galleries, media servers, thumbnail generators, and document processing pipelines, can be exposed if it links an affected libheif build. That also means the usual WordPress remediation path, updating a plugin, does not apply here at all. Site owners need to check with their hosting provider or Linux distribution for an updated system package, and anyone running WordPress in a container needs to rebuild from an updated base image rather than waiting on an in-place update.

This is also not the only serious libheif disclosure this month. On August 25, Meta’s own Product Security team separately reported eleven distinct vulnerabilities in a different part of libheif’s code, the handling of derived and auxiliary image items, after receiving an external report of a working exploit against version 1.23.1. That batch was fixed in 1.23.2, one version before the release this Wordfence bug affects. The GitHub advisory for the Wordfence-found flaw addresses the overlap directly, stating the two are separate: Meta’s issues involved images that violate libheif’s assumptions about plane geometry, while this bug is a direct decode fault in the mixed-interleave chroma write path that Meta’s fixes never touched. libheif has kept shipping fixes since: version 1.23.4 followed on September 6 with several more, unrelated security and bug fixes, three of them rated high severity, and is the current release as of this writing.

What to check

Wordfence’s guidance is straightforward for anyone running a server that might decode HEIC or HEIF files from outside users. Check the installed libheif version and whether it was compiled with uncompressed-codec support enabled; a lower version number from an operating system’s own package manager does not necessarily mean the fix is missing, since Linux distributions often backport security patches without changing the upstream version string. Install the vendor’s fixed package rather than waiting for a plugin update that will not come. Where possible, isolate or sandbox the process that handles image decoding. And if a site or application has no real need to accept HEIF or HEIC uploads, disabling that support removes the exposure entirely.