A Critical libheif Bug Reachable Through WordPress Uploads Still Has No CVE

On a clean WordPress installation with no plugins, a researcher uploaded a crafted photo through the Media Library, copied /etc/passwd to a public folder and left a working PHP file on the server. The flaw is not in WordPress. It sits several layers down, in libheif, the library that much of the Linux ecosystem uses to open the HEIC photos an iPhone has produced by default since 2017. The maintainer rated it critical, 9.8 out of 10, and shipped the fix on September 1. Twenty days later it still has no CVE number.

For hosting providers this is the awkward class of vulnerability. There is no plugin for a customer to update and no button in a control panel. libheif is a system library, so the fix comes through an operating system package, a rebuilt base image or a build from source. On managed hosting none of those is normally in a site owner’s hands. The work belongs to whoever maintains the server or the base image.

Key facts

• The flaw: a heap buffer overflow in libheif’s uncompressed image decoder, versions 1.18.0 through 1.23.2, present only in builds compiled with the uncompressed codec enabled.
• The paperwork: of the 25 libheif advisories published between August 25 and September 21, 16 carry no CVE number, including two of the three rated critical.
• The multiplier: an exploit has to be tailored to its target, which is a speed bump rather than a barrier on a fleet where every server was built from one image.
• The trap: the version number alone does not settle exposure. Whether a build is vulnerable turns on a compile-time flag, and two distributions on the same release can differ.

From a Photo Upload to a C++ Library

WordPress does not decode images itself. When a file arrives it hands it to an image editor to build thumbnails and read metadata. On affected servers the PHP Imagick extension calls ImageMagick, ImageMagick recognizes HEIF, and the file goes down to libheif. That chain, as the Wordfence research team that found the bug describes it, “places a C++ library in the PHP image-processing worker, parsing bytes that arrived from the Internet with that worker’s permissions.”

The defect is narrow. In the mixed-interleave path of the uncompressed decoder, the two chroma components may declare different bit depths, but both are written using the first component’s byte width. A file that declares a 16-bit Cb and an 8-bit Cr therefore writes two bytes per sample into a plane allocated for one, and, as the advisory puts it, “The bytes being written come from the crafted image’s component data and are attacker-controlled.” Directly above that loop sits a comment about a different out-of-bounds write in the same function, fixed a few months earlier. This code had been patched once already for writing past the end of a color plane.

Sixteen Advisories Without a Number

libheif has had a heavy month. Three security releases went out in under two weeks: 1.23.2 on August 25, 1.23.3 on September 1 and 1.23.4 on September 6, the first two carrying criticals and the third three issues rated high. Every one of those release notes carries the same line: “CVE numbers will be added when assigned.”

They have not been. Of the 25 advisories the project published between August 25 and September 21, 16 carry no CVE identifier. The gap is not concentrated at the bottom of the severity scale. Two of the three criticals lack one, and the pattern inverts inside a single release: in the one that carries the critical fix, the only two entries with CVE numbers are rated medium. Nine libheif CVEs did appear in the National Vulnerability Database on September 18, scored between 3.7 and 9.8, and none of them describes this flaw.

The other critical without a number was published on August 25 and came from Meta’s product security team, which had received “an external report about a working exploit against the latest release of libheif” and confirmed the proof of concept. Its investigation “uncovered 11 separate vulnerabilities” in the library. Neither flaw was in CISA’s Known Exploited Vulnerabilities catalog as of September 21, and there is no public evidence that either is being used in attacks.

For a hosting provider the consequence is procedural rather than dramatic. A patch pipeline keyed to CVE identifiers, or a compliance report that counts open CVEs, has nothing to match against here. The advisory exists, the fixed version exists, and the paperwork that normally connects the two is missing.

How Far It Goes

The demonstrated impact is real and narrower than the score suggests. On a clean WordPress 7.1 Media Library running on x86-64 Debian, researcher Alex Thomas copied a protected file to an attacker-selected destination and created a PHP file that executed. A narrower variant of the technique worked in 29 of 30 attempts, on a warmed Apache worker pool. The upload required an account with upload rights, normally Author or above, and the advisory states plainly that the result “does not establish a portable, fully self-calibrating, or universal RCE exploit.” The 9.8 score describes the library in the abstract, exposed by some application to untrusted images over the network with no login required. It does not describe the WordPress route that proved it.

Two qualifiers push in the opposite direction, and both land on hosting providers. A plugin or custom application that lets subscribers or visitors upload HEIC files could remove the Author requirement, and that path was not tested. And an exploit tailored to one server is not spent after one use: where hundreds or thousands of sites run from the same hosting image, work done against one of them may carry to the rest. Researchers at Hacktron, who turned earlier libheif flaws into working attacks, put the cost of adapting an exploit to a new target at roughly one or two days.

One detail belongs on the record: the bug surfaced during an assessment run with an agentic testing framework, and the advisory states that the report itself “is AI-generated with some minor human edits”, reviewed and reproduced by a named researcher before submission.

The Version Number Does Not Answer the Question

The usual triage move, comparing an installed version against an affected range, is not enough here. The vulnerable code only ships in builds compiled with the uncompressed codec enabled, which is a packaging decision each distribution makes for itself. Nine configurations were tested on September 5, decoding a valid uncompressed HEIF file:

• Vulnerable: the official WordPress Docker image (1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2), Fedora 44 (1.21.2)
• Not vulnerable: 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), AlmaLinux 10 (1.17.6)

Debian 13 and Alpine 3.22 ship the same upstream release, 1.19.8, and land on opposite sides of the line because one enables the uncompressed codec at build time and the other does not. The reverse trap exists too, since a distribution may backport the fix while keeping a lower version number. Establishing exposure therefore takes two answers, not one. Asking a build to decode the format shows whether the affected codec is compiled in, and the package changelog or the vendor’s security metadata shows whether the fix itself has been backported, which is how a lower version number can be safe. Package contents change, so that table is a snapshot of one date. The official WordPress container image tested on September 5 is the uncomfortable entry on the list: it carried the Imagick extension, reported HEIC support and shipped a vulnerable build, with no configuration choice by the operator involved.

What Closes It

Installing the operating system or hosting provider’s libheif update is the first move, followed by restarting PHP and the web services so they stop using the copy already mapped into memory. Sites installed directly from source need at least 1.23.3, and 1.23.4 is the current upstream security release. Containers need a rebuild from an updated base image, not a restart, and without relying on a cached layer.

Two checks are available to site owners in the meantime. Tools, Site Health, Info, Media Handling lists the formats ImageMagick supports, and no HEIC there means this particular path is closed, though other software on the server may still use the library. For anyone who cannot patch yet, removing the four HEIF types WordPress accepts, heic, heif, heics and heifs, from the allowed upload types rejects the file before it reaches the decoder.

This is not a WordPress problem, whatever the route that proved it. Any service that decodes untrusted HEIC or HEIF files through an affected build is in scope, including thumbnail services, media servers and document pipelines that no one thinks of as image software. Earlier flaws in the same library were turned into confirmed code execution against Discourse through an image upload, and into unauthenticated code execution in Next.js applications processing a crafted AVIF file. Those were fixed in 1.23.2. This one survived that release.

On managed hosting almost none of that is visible to the customer. The researchers make the point themselves, and suggest asking the provider two things: whether the libheif on the server falls in the vulnerable range, and whether it was built with the uncompressed codec enabled. For a host, publishing that answer once is cheaper than giving it to one customer at a time.

About the Data

The description of the flaw, the demonstrated impact and the limits on it come from the libheif project’s own security advisory and from the Wordfence research team’s write-up of its finding. Affected ranges, severity ratings and CVE identifiers were read from the project’s published advisories and release notes, and counted against the National Vulnerability Database and CISA’s catalog on September 21. The table of tested configurations is the researchers’, recorded on September 5.