CVE-2026-120208: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-120208 is a heap-based buffer overflow vulnerability in libheif's ISO/IEC 23001-17 uncompressed-image (unci) mixed-interleave decoder, specifically in the unc_decoder_mixed_interleave::processTile() function. It affects libheif versions 1.18.0 through 1.23.2 (inclusive), and was disclosed on October 31, 2026, with a patch released in version 1.23.3. The vulnerability allows an attacker to trigger file-controlled heap out-of-bounds writes by crafting a HEIF image with chroma components (Cb and Cr) declaring unequal bit depths. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 7.7 (High) (Feedly, GitHub Advisory).

The root cause (CWE-787: Out-of-bounds Write; CWE-122: Heap-based Buffer Overflow) lies in unc_decoder_mixed_interleave::processTile(), which processes both Cb and Cr chroma planes using only the byte width of whichever chroma component is declared first in the uncC component list. Each chroma plane is allocated according to its own component's bit depth, but the code reuses the first component's bytes_per_component_sample for both writes. A crafted HEIF file declaring, for example, 16-bit Cb and 8-bit Cr causes the Cr plane (allocated for 1 byte/sample) to receive 2-byte writes, overrunning the heap allocation once per chroma sample with attacker-controlled bytes (GitHub Advisory). The vulnerable code path is unc_decoder_mixed_interleave.cc:101 → unc_decoder_legacybase::memcpy_to_native_endian(), and exploitation requires libheif to be built with WITH_UNCOMPRESSED_CODEC=ON (libheif source). A proof-of-concept HEIF file (overflow.heif) and generator script (poc.py) were submitted with the advisory, and the overflow was confirmed with AddressSanitizer against the official libheif 1.23.2 release (GitHub Advisory).

Successful exploitation results in an attacker-controlled heap out-of-bounds write, which can corrupt adjacent heap data at a scale proportional to the chroma-plane dimensions. In a demonstrated WordPress 7.1 deployment using PHP Imagick, ImageMagick, and libheif 1.23.2, a researcher achieved arbitrary file read (e.g., /etc/passwd) and arbitrary PHP code execution on the server, with the self-copy exploit succeeding in 29 of 30 independent attempts (GitHub Advisory). The impact is deployment-specific and depends on exact architecture, ABI, library builds, and heap behavior; a complete portable RCE has not been demonstrated, but confidentiality, integrity, and availability are all rated High (Feedly).

A proof-of-concept HEIF file and Python generator script were included in the original advisory submission, but no public PoC has been released as of disclosure (Feedly). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is 0.0, reflecting the absence of observed exploitation (EUVD). Exploitation requires user interaction (a victim or server-side pipeline must process a malicious HEIF file) and specific build conditions (WITH_UNCOMPRESSED_CODEC=ON), which moderately limits the attack surface. The vulnerability was discovered by Alex Thomas (Wordfence) using the Wordfence Argus agentic adversarial testing framework during a WordPress 7.1 security assessment (GitHub Advisory).

1. Craft a malicious HEIF file: Using the disclosed poc.py generator or manually, construct a HEIF unci image with mixed-interleave YCbCr 4:2:0 encoding, declaring Y=8-bit, Cb=16-bit, and Cr=8-bit components. The Cr plane will be allocated for 1 byte/sample while the decoder will write 2 bytes/sample to it.
2. Identify a target: Locate a server or application that processes HEIF images using libheif 1.18.0–1.23.2 built with WITH_UNCOMPRESSED_CODEC=ON (e.g., a WordPress site using PHP Imagick/ImageMagick with libheif support).
3. Deliver the malicious file: Upload or submit the crafted overflow.heif to the target's image-processing pipeline (e.g., via a WordPress Media Library upload as an Author-level user or higher).
4. Trigger the overflow: When the server decodes the HEIF file, unc_decoder_mixed_interleave::processTile() processes both chroma planes using the Cb byte width (2 bytes), overrunning the Cr heap allocation once per chroma sample with attacker-controlled bytes.
5. Achieve post-corruption impact: Depending on the heap layout and deployment, the attacker may corrupt adjacent heap objects to redirect execution, disclose files (e.g., copy /etc/passwd to a web-accessible path), or achieve code execution (e.g., write a PHP webshell to a publicly accessible directory) (GitHub Advisory).

• File System: Unexpected files in web-accessible upload directories (e.g., .php files in WordPress wp-content/uploads/); copies of sensitive system files (e.g., /etc/passwd) appearing in public directories; HEIF files with unusual uncC component declarations (Y=8-bit, Cb=16-bit, Cr=8-bit, mixed interleave, 4:2:0 sampling).
• Logs: Web server access logs showing HEIF file uploads followed by unexpected HTTP 200 responses to newly created PHP files; image processing errors or crashes in application logs coinciding with HEIF file uploads; AddressSanitizer output referencing heap-buffer-overflow WRITE in unc_decoder_legacybase::memcpy_to_native_endian() or unc_decoder_mixed_interleave::processTile().
• Process: Unexpected child processes spawned by image-processing workers (e.g., PHP, ImageMagick, or libheif processes executing shell commands); abnormal process crashes or SIGABRT signals from image-processing daemons with double free or corruption messages.
• Network: Outbound connections from image-processing servers to unknown external hosts following HEIF file uploads (GitHub Advisory).

Upgrade libheif to version 1.23.3 or later, which is ABI- and API-compatible with 1.23.2 and serves as a drop-in replacement; the fix tracks each chroma plane's own byte width independently in ChannelListEntry (libheif v1.23.3 release, fix commit). As an interim workaround, restrict processing of HEIF images from untrusted sources, implement input validation to reject malformed HEIF files before they reach libheif, and consider disabling HEIF support entirely if not actively required (Feedly). Organizations using libheif in server-side image pipelines (e.g., WordPress with Imagick) should treat this as a priority upgrade given the demonstrated file-read and code-execution potential in specific deployments.

The vulnerability was discovered by Alex Thomas of Wordfence using the Wordfence Argus agentic adversarial testing framework during a WordPress 7.1 security assessment, and the advisory credits both the human researcher and the AI framework (GitHub Advisory). The libheif maintainer (farindk) rated the issue critical and released v1.23.3 as a security release, strongly advising all users to upgrade (libheif v1.23.3 release). The disclosure attracted automated tracking across vulnerability aggregators and social platforms including Mastodon (infosec.exchange) and Bluesky shortly after publication, reflecting standard community monitoring of high-severity image-parsing vulnerabilities.