WordPress HEIC Upload RCE Isn't in WordPress: Patch libheif to 1.23.3

The Situation

There is no WordPress plugin to click Update on.

On 5 October 2026, UK firm Fortbridge published a working end-to-end chain that turns an authenticated WordPress Media Library HEIC upload into code execution as the PHP worker.[4][5] The overflow they drive is GHSA-x8r2-mggj-j6wr in libheif, the C++ library most of Linux uses to open iPhone photos. Wordfence researcher Alex Thomas found it during a WordPress 7.1 assessment; maintainer Dirk Farin shipped libheif 1.23.3 on 1 September 2026 and rated the issue CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).[1][2][3]

WordPress Core is the delivery path, not the bug. A site owner who only patches plugins will miss it. A host who only watches wp core version will miss it. The floor is the system libheif the image stack actually dlopens, then a PHP/Apache/FPM restart so the old .so is gone from memory.[2]

What's Affected

GHSA-x8r2-mggj-j6wr is a heap buffer overflow in libheif's built-in ISO/IEC 23001-17 uncompressed-image (unci) decoder. In the mixed-interleave YCbCr path, the decoder lets paired Cb and Cr planes declare different bit depths, allocates each plane from its own depth, then writes both chroma destinations using the first chroma entry's byte width. A crafted Y8/Cb16/Cr8 file therefore overruns the Cr allocation with attacker-controlled bytes. The path lives in unc_decoder_mixed_interleave.cc; it does not need libde265, AOM, dav1d, ImageMagick, or WordPress. It does need libheif built with WITH_UNCOMPRESSED_CODEC=ON.[1]

Vendor range, from the advisory and the 1.23.3 notes:[1][3]

Affected: libheif 1.18.0 through 1.23.2 when the uncompressed codec is compiled in.
Fixed: 1.23.3. 1.23.4 is a later security maintenance release.[8] Debian's package tracker showed upstream 1.23.5 available as of 6 October 2026 - treat that as "current exists," not as proof your distro package has caught up.[6]
1.23.2 is not enough. That release closed a different critical (GHSA-2jg2-4ch7-h545 / HEIF Heist family). This overflow survived it.[1][2][3]

Wordfence's 5 September 2026 decode test of nine real builds is the practical map. Same upstream version can land on opposite sides of the line because of that compile flag:[2]

Vulnerable in that snapshot: official wordpress Docker image (libheif 1.19.8), Debian 13 trixie (1.19.8), Ubuntu 26.04 (1.21.2), Fedora 44 (1.21.2).
Not vulnerable in that snapshot: Ubuntu 24.04 LTS (1.17.6), Debian 12 bookworm (1.15.1), Alpine 3.22 (1.19.8, codec off), Alpine 3.23 (1.23.0, codec off), AlmaLinux 10 (1.17.6).

Debian 13 and Alpine 3.22 both shipped 1.19.8. One decoded uncompressed HEIF. The other did not.[2] Do not triage from the version string alone.

The usual WordPress path is only live if all of these are true:[2]

PHP Imagick is loaded (GD cannot read HEIC).
ImageMagick was packaged with HEIF support.
libheif is in 1.18.0-1.23.2 and built with the uncompressed codec.

On a clean WordPress install the upload capability is upload_files - Author and above. Wordfence did not claim a Subscriber/unauth route in Core.[1][2] A plugin that lets visitors upload HEIC through the same Imagick worker changes that picture; we did not independently test any plugin.

Fortbridge measured two exact amd64 lab profiles, not "WordPress in general": Ubuntu 26.04 (WordPress 7.1.1, PHP-FPM 8.5.4, ImageMagick 7.1.2.18, libheif 1.21.2) and Debian 13 (WordPress 7.0, PHP-FPM 8.4.24, ImageMagick 7.1.1.43, libheif 1.19.8). They reported 6/8 fresh FPM parents on Ubuntu and 22/24 on Debian, counting success only when a later GET of a previously absent path returned 200 with id output - a 503 is a crash, not RCE.[4] Wordfence separately reproduced file copy of /etc/passwd and PHP execution on one Debian/glibc WordPress 7.1 Author upload path (29/30 self-copy attempts on a warmed Apache prefork pool) and was explicit that this is not a universal exploit.[1][2]

Why This Matters for Hosts

Shared-hosting fleets on AlmaLinux / CloudLinux / Ubuntu 24.04 LTS may already sit below 1.18.0 or without the uncompressed codec - Wordfence's AlmaLinux 10 and Ubuntu 24.04 rows were "No" on 5 September.[2] That is not a pass for the fleet. EasyApache 4, custom ImageMagick RPMs, and "we installed Imagick from PECL against a newer libheif" are how a "safe distro" box still grows a decoder.

The boxes that should move today:

Anything running the official WordPress Docker image Wordfence tested, or any image derived from Debian 13 + Imagick + HEIC.[2]
Debian 13 / Ubuntu 26.04 app VMs that thumbnail user media.
Multi-author WP, open registration, or any site where a compromised Author is a realistic first foothold.
Hosts that bake one golden image for hundreds of WP containers - Fortbridge and Wordfence both note that a profile written for one build carries to the rest of that image.[2][4]

Code execution in the lab is the PHP-FPM / Apache worker user (www-data in Fortbridge's Debian proof), not root and not every tenant on the box.[4] On a shared host that still matters: the worker can read neighboring vhosts that are mode 644, drop PHP in an uploads directory that executes scripts, and pivot from there. Treat it as site compromise, then hunt for the usual next hop.

What to Do Now

1. See what the image stack actually loads

# Debian/Ubuntu
dpkg -l 'libheif*' 2>/dev/null

# RHEL/Alma/CloudLinux
rpm -q libheif libheif1 2>/dev/null; rpm -q --changelog libheif 2>/dev/null | head

# ImageMagick HEIF support (empty = this path is closed)
identify -list format 2>/dev/null | grep -Ei 'HEIC|HEIF'

# PHP Imagick present?
php -m | grep -i imagick
php -r 'if (class_exists("Imagick")) { echo implode("\n", (new Imagick())->queryFormats("HEI*")), "\n"; }'

In wp-admin: Tools → Site Health → Info → Media Handling. If HEIC is not listed, this particular Imagick path is not exposed. Other binaries on the same box can still call libheif.[2]

A version in 1.18.0-1.23.2 is not a finding by itself. Confirm the uncompressed codec if you can:

# Debian-style: does the package even ship unci?
# If heif-dec exists, a valid uncompressed HEIF will decode only when the codec is on.
# Do not throw untrusted files at production. Use vendor changelog / build flags.
strings /usr/lib/*/libheif.so.1 2>/dev/null | grep -E 'unci|UNCOMPRESSED' | head

2. Patch the library, then restart the worker

Upstream floor: 1.23.3 or later. Prefer the distro security package over compiling it yourself.[2][3][8]

# Debian 13 / Ubuntu - use whatever security update your tracker currently lists
apt-get update
apt-cache policy libheif1
apt-get install --only-upgrade libheif1 libheif-plugin-* 2>/dev/null || apt-get install --only-upgrade libheif1

# Then unload the old mapping. A package install without this leaves FPM holding 1.19.x.
systemctl restart php*-fpm 2>/dev/null || true
systemctl restart php-fpm 2>/dev/null || true
systemctl restart apache2 httpd nginx lsws 2>/dev/null || true

Confirm the running worker, not just the package:

# After restart, every php-fpm/apache child should show the new .so
lsof -n -p $(pgrep -n php-fpm || pgrep -n apache2) 2>/dev/null | grep libheif

3. Containers: rebuild, do not restart

Wordfence: restarting an old WordPress container does not replace the library baked into the image. Pull an updated base, rebuild without a cached layer, redeploy.[2]

docker pull wordpress:latest
docker build --no-cache -t wordpress-local:patched .
# then roll the service onto the new image; confirm libheif inside the new container
docker run --rm wordpress-local:patched dpkg -l 'libheif*'

4. If you cannot patch yet

Wordfence's stopgap is to reject the four HEIF types WordPress accepts (heic, heif, heics, heifs) before they reach Imagick, and to disable PHP execution in uploads - the latter is good hygiene even after you patch.[2] That is a mitigation, not a fix. Do not leave HEIC blocked as a substitute for 1.23.3 on a fleet that still decodes it in cron thumbnailers, Nextcloud, or Mailcow.

5. Hunt, briefly, after you patch

You are looking for Author-level HEIC uploads clustered around worker crashes, not a signature we can invent:

PHP-FPM/Apache children dying with 503 around media uploads (Fortbridge treats 503 as crash telemetry, never as proof of RCE).[4]
New .php files under wp-content/uploads/ after a HEIC upload.
Unexpected world-readable copies of /etc/passwd or other system files in upload dirs (Wordfence's lab file-copy primitive).[1]

Absence of those is not a clean bill of health. Presence is a site-compromise ticket.

What We Don't Know Yet

No CVE ID for GHSA-x8r2-mggj-j6wr in the GitHub advisory payload we pulled (field cve_id was null). The 1.23.3 notes still say "CVE numbers will be added when assigned."[1][3]
Not on CISA KEV as of catalog version 2026.10.04 (released 2026-10-04). Newest hosting-stack KEV remains CVE-2026-87902 in WordPress Core - a different bug.[7]
No in-the-wild campaign named in the Wordfence write-up, the GHSA, or the 5 October Fortbridge coverage we used.[1][2][4]
CVSS 9.8 is the maintainer/GitHub vector, including PR:N. WordPress Core's default path still needs upload_files. Do not flatten those two facts into "unauthenticated WordPress RCE."[1][2]
Wordfence's distro table is a 5 September 2026 snapshot. Packages move. Re-check yours.[2]
Fortbridge's hit rates are two lab profiles. They are not success rates for WordPress as a whole.[4]
We did not independently run the public PoC. Mechanism quotes above are from the GHSA and Wordfence.[1][2] The 5 October public-chain claim is from Fortbridge's coverage and their public repository.[4][5]

If a CVE is assigned, or CISA lists this, the priority does not change - patching already should have happened. What changes is how you file the ticket.

Sources

[1] https://github.com/strukturag/libheif/security/advisories/GHSA-x8r2-mggj-j6wr - GHSA-x8r2-mggj-j6wr [2] https://www.wordfence.com/blog/2026/09/wordfence-argus-discovers-critical-vulnerability-in-libheif - Wordfence Argus libheif [3] https://github.com/strukturag/libheif/releases/tag/v1.23.3 - libheif v1.23.3 [4] https://www.cyberkendra.com/2026/10/wordpress-libheif-rce-exploit-chain-goes-public.html - Cyber Kendra Fortbridge chain [5] https://github.com/FORTBRIDGE-UK/libheif-unci-wordpress-rce - Fortbridge public PoC repo [6] https://tracker.debian.org/pkg/libheif - Debian libheif tracker [7] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA KEV JSON 2026.10.04 [8] https://github.com/strukturag/libheif/releases/tag/v1.23.4 - libheif v1.23.4