libheif EUVD-2026-114729

Requires libheif built with WITH_UNCOMPRESSED_CODEC=ON (the built-in ISO/IEC 23001-17 'unci' decoder); the bug is internal to libheif and does NOT require libde265, AOM, dav1d, ImageMagick or WordPress. The trigger is a HEIF file using the unci mixed-interleave YCbCr path with paired Cb and Cr components declared at different bit depths (the reproducer uses Y8/Cb16/Cr8, 4:2:0, mixed interleave), which causes the smaller chroma plane to receive wider writes. Limiting factors: a victim or pipeline must actually decode the attacker-supplied file (UI:P/UI:R); the uncompressed codec build option must be enabled; the OOB write and crash are reliable, but reliable code execution additionally depends on exact architecture, ABI, specific library builds and object layouts, glibc allocator placement/worker continuity, and a reachable application upload path (in the demonstrated WordPress case, Author-level upload_files capability). Per the advisory, universal RCE across libheif consumers is not demonstrated.

The input assigns a CVSS 4.0 base score of 7.7 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H. The network vector is real in the sense that the malicious input is a file, but exploitation is gated by UI:P (a victim/pipeline must process the crafted HEIF) and AT:P (a specific attack-requirement condition exists), which the vendor evidence confirms: the vulnerable code path only exists when libheif is compiled with WITH_UNCOMPRESSED_CODEC=ON, and reliable code execution further depends on exact architecture, ABI, library builds, heap/allocator layout and a reachable upload path. No EPSS score is provided in the input, and there is no CISA KEV listing, so there is no signal of active, widespread exploitation at time of analysis. A public PoC does exist and is strong: the GHSA advisory ships a validated crash reproducer (overflow.heif plus a poc.py generator) with an AddressSanitizer trace confirming the heap out-of-bounds write on the official 1.23.2 release, and a negative control. Beyond the crash, the researcher (VulnCheck/Wordfence) demonstrated actual arbitrary file read (/etc/passwd) and PHP code execution, but only in one exact WordPress 7.1 / Debian / PHP-Imagick / libheif 1.23.2 deployment; the advisory explicitly states this does not imply universal RCE and that a complete remote ASLR bypass was not demonstrated. Net: this is a genuine, patch-worthy memory-corruption bug with a confirmed write primitive and a working crash PoC, but it is not a drop-everything internet-worm scenario - the vendor-supplied decision label is this_week, not act_now/emergency, consistent with conditional exploitation. One data conflict to note: NVD/input list CWE-122 (heap-based buffer overflow) while the GHSA lists CWE-787 (out-of-bounds write); both describe the same heap OOB write and do not change the risk.

An attacker crafts a HEIF file whose unci mixed-interleave YCbCr components declare unequal chroma bit depths (e.g. 16-bit Cb, 8-bit Cr) and gets it decoded by a victim or server-side image pipeline running a vulnerable libheif built with the uncompressed codec enabled. Decoding issues two-byte writes into a one-byte-per-sample Cr plane, producing a repeated, attacker-controlled heap out-of-bounds write past the Cr allocation, which crashes the process and corrupts adjacent heap data. A validated public PoC (a reliable ASAN-confirmed crash reproducer) exists; the researcher additionally demonstrated file read and PHP code execution, but only in one specific WordPress/Debian/Imagick build, and universal code execution is not demonstrated.